1. Chapter 6 Determining System Requirements
Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich
Chapter 6
Determining System Requirements

2. Performing Requirements Determination
FIGURE 6-1
Systems development life cycle with analysis phase highlighted
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

3. Requirements Engineering
The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.
The requirements themselves are the descriptions of the system services and constraints that are generated during the requirements engineering process.

4. Types of requirement: A-User requirements Example User requirements:
Statements in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers.
Example User requirements:
generating monthly report showing name of item sold, quantity sold, total amount of money, what is left in store and so on.
A report showing the total amount of spending by each department in the university.

5. B- System requirements:
A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented. it may be part of a contract between client and contractor.
Examples:
At the last day of a month the system generates an absence report for each student. A copy of the report is generated for the student's course instructor, another copy for the student's major department head and another copy for the student's parents.
At the end of each phone call, a message is sent back to caller showing call duration, call cost and the remaining balance in minutes or money.

6. Business requirements
Business requirements for a project are a series of needs that must be fulfilled to achieve a high-level objective. For example, if a company's objective is to upgrade its manual payroll process by switching to an automated payroll process, the business requirements for the project might be described as,
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

7. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
"implement a computerized system that reduces errors and increases efficiency by calculating employees' wages, withholding required deductions and paying the employee the amount she is owed." Clear business requirements help ensure that the end result of a project fulfills the stakeholders' needs.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

8. Functional Requirements
Functional requirements break down the steps needed to meet the business requirement or requirements. Whereas a business requirement states the 'why' for a project, a functional requirement outlines the 'what'. For example, if the business requirement is to create a member directory for a trade association, the
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

9. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
functional requirements will outline who has access to the directory, how member register with the directory, who will have ownership of the data, what vehicle or vehicle will be used such as a website or paper-based directory, and so on.
When developing functional requirements, a comprehensive list of steps that will be taken during the project is developed.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

10. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
Functional requirements are very detailed and provide information on how business needs and goals will be delivered through a specific project. While senior managers will be more interested in business requirements, functional requirements are generally what staff and lower-level
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

11. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
managers need to focus on when developing a project. The end objective is for each step to contribute towards achieving the business requirement or requirements. It should also be clear who will be responsible for each step.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

12. Types of System requirements :
A-Functional requirements
are the main things that the user expects from the software for example if the application is a banking application that application should be able to create a new account, update the account, delete an account, etc. functional requirements are detailed and are specified in the system design.

13. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
Statements of services the system (SW) should provide, how the system should react to particular inputs and how the system should behave in particular situations.
These are the functions that the users will be looking for in the software.
defines a function of a system or its component. A function is described as a set of inputs, the behaviour, and outputs.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

14. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
May state what the system should not do.
The functional requirement of an office productivity software should have the ability to calculate information from different sources and print them.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

15. B-Non-functional requirements
type of requirement that does not require actions.
One example is the type of interface you should be expecting in a software.
Other examples are security, accuracy, availability, capacity, reliability, and response time.
These are basically the properties and performance expected from the software.

16. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
Domain requirements
The system's operational domain imposes requirements on the system.
Domain requirements may be new functional requirements, constraints on existing requirements or define specific computations. If domain requirements are not satisfied, the system may be unworkable.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

17. Requirements sources Form-based specifications
Definition of the function or entity using the form.
Description of inputs and where they come from.
Description of outputs and where they go to.
Problems of requirements elicitation
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
The requirements change during the analysis process. New stakeholders may emerge and the business environment change.

18. Traditional Methods for Determining Requirements
Interviewing individuals
Interviewing groups
Observing workers
Studying business documents
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

19. 1- Interviewing individuals (domain expert)
Dialogue with user or manager to obtain their requirements
Formal or informal interviews with stakeholders are part of most requirement elicitation processes.
Types of interview
Closed interviews based on pre-determined list of questions
Open interviews where various issues are explored with stakeholders.
Effective interviewing
Be open-minded, avoid pre-conceived ideas about the requirements be willing to listen to stakeholders.
Prompt the interviewee to get discussions going using a springboard question, a requirements proposal, or by working together on a prototype system.

20. Normally a mix of closed and open-ended interviewing.
Interviews are good for getting an overall understanding of what stakeholders do and how they might interact with the system.
Disadvantages
Contradictions and inconsistencies between interviewees
Follow-up discussions are time consuming

21. Guidelines for Effective Interviewing
Plan the interview.
Prepare interviewee: appointment, priming questions.
Prepare agenda, checklist, questions.
Listen carefully and take notes (tape record if permitted).
Review notes within 48 hours.
Be neutral.
Seek diverse views.
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

22. Choosing Interview Questions
Each question in an interview guide can include both verbal and non-verbal information.
Open-ended questions: questions that have no prespecified answers
Closed-ended questions: questions that ask those responding to choose from among a set of specified responses
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

23. Interviewing Guidelines
Don’t phrase a question in a way that implies a right or wrong answer.
Listen very carefully.
Type interview notes within 48 hours after the interview.
Don’t set expectations about the new system unless you know these will be deliverables.
Seek a variety of perspectives from the interviews.
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

24. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
2-Interviewing Groups
Drawbacks to individual interviews:
Contradictions and inconsistencies between interviewees
Follow-up discussions are time consuming
New interviews may reveal new questions that require additional interviews with those interviewed earlier
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

25. Interviewing groups (cont)
A facilitated process that supports idea generation by groups of customers. (brain storming) [Interview several key people together]
Process
Members come together as a group, but initially work separately.
Each person writes ideas.
Facilitator reads ideas out loud, and they are written on blackboard.
Group discusses the ideas.
Ideas are prioritized, combined, selected, reduced.
Advantages
More effective use of time
Can hear agreements and disagreements at once
Opportunity for synergies(تعاون)
Disadvantages
More difficult to schedule than individual interviews

26. Nominal Group Technique (NGT)
A facilitated process that supports idea generation by groups
Process
Members come together as a group, but initially work separately.
Each person writes ideas.
Facilitator reads ideas out loud, and they are written on a blackboard or flipchart.
Group openly discusses the ideas for clarification.
Ideas are prioritized, combined, selected, reduced.
Used to complement group meetings or as part of JAD effort
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

27. Directly Observing Users
Direct Observation
Watching users do their jobs
Used to obtain more firsthand and objective measures of employee interaction with information systems
Can cause people to change their normal operating behavior
Time-consuming and limited time to observe
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

28. Analyzing Procedures and Other Documents
Document Analysis
Review of existing business documents
Can give a historical and “formal” view of system requirements.
Types of documents: (get a copy of each)
1- Forms (for data gathering and reports)
2- Organization policy and regulations
3- Organizational Chart
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

29. Analyzing Procedures and Other Documents (Cont.)
Types of information to be discovered:
Problems with existing system
Opportunity to meet new need
Organizational direction
Names of key individuals
Values of organization
Special information processing circumstances
Reasons for current system design
Rules for processing data
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

30. Analyzing Procedures and Other Documents (Cont.)
Useful document: Written work procedure
For an individual or work group
Describes how a particular job or task is performed
Includes data and information used and created in the process
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

31. Analyzing Procedures and Other Documents (Cont.)
Potential Problems with Procedure Documents:
May involve duplication of effort
May have missing procedures
May be out of date
May contradict information obtained through interviews
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

32. Analyzing Procedures and Other Documents (Cont.)
Formal Systems: the official way a system works as described in organizational documentation (i.e. work procedure)
Informal Systems: the way a system actually works (i.e. interviews, observations)
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

33. Analyzing Procedures and Other Documents (Cont.)
Useful document: Business form
Used for all types of business functions
Explicitly indicates what data flow in and out of a system and data necessary for the system to function
Gives crucial information about the nature of the organization
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

34. Analyzing Procedures and Other Documents (Cont.)
Useful document: Report
Primary output of current system
Enables you to work backwards from the report to the data needed to generate it
Useful document: Description of current information system
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

35. II - Modern Methods for Determining Requirements
1- Joint Application Design (JAD)
Brings together key users, managers, and systems analysts and Information System Staff.
collect system requirements simultaneously from key people
Objective s are to:
1- analyze the existing system
2- obtain user input and expectations
3- document user requirements for the new system

36. Joint Application Development
JAD Participants and Roles
Conducted off-site
Team members meet in isolation for an extended period of time to collect system requirements simultaneously from key people.
JAD participants should be insulated from the distraction of day-to-day operations

37. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

38. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
End Result
Documentation detailing existing system
Features of proposed system[system requirements and specifications]
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

39. Joint Application Development
JAD Advantages and Disadvantages
Advantages
1-Allows key users to participate effectively increase productivity
2-more accurate statement of system requirements thus decreasing errors.
3-a better understanding of common goals
4-a stronger commitment to the success of the new system
Disadvantages
More expensive and can be cumbersome if the group is too large relative to the size of the project

40. Contemporary Methods for Determining System Requirements
Supporting JAD with GSS
Facilitate sharing of ideas and voicing of opinions about system requirements
Group support systems (GSS) can be used to enable more participation by group members in JAD
Members type their answers into the computer
All members of the group see what other members have been typing
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

41. Contemporary Methods for Determining System Requirements (Cont.)
System prototypes
Iterative development process
Rudimentary working version of system is built
Refine understanding of system requirements in concrete terms
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

42. Using Prototyping During Requirements Determination
Quickly converts requirements to working version of system
Once the user sees requirements converted to system, will ask for modifications or will generate additional requests
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

43. Using Prototyping During Requirements Determination (Cont.)
Figure 6-7
The prototyping methodology
(Source: Based on “Prototyping: The New
Paradigm for Systems Development,” by
J. D. Naumann and A. M. Jenkins, MIS
Quarterly 6(3): 29–44.)
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

44. Using Prototyping During Requirements Determination (Cont.)
Most useful when:
User requests are not clear.
Few users are involved in the system.
Designs are complex and require concrete form.
There is a history of communication problems between analysts and users.
Tools are readily available to build prototype.
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

45. Using Prototyping During Requirements Determination (Cont.)
Drawbacks
Tendency to avoid formal documentation
Difficult to adapt to more general user audience
Sharing data with other systems is often not considered
Systems Development Life Cycle (SDLC) checks are often bypassed
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

46. 3- Business Process Reengineering (BPR)
The fundamental rethinking and radical redesign of core business processes to achieve dramatic improvements in critical performance measures such as quality, cost, and service and speed. To achieve breakthrough improvements in products and services.
BPR involves innovation: Creating new products and
services,
BPR is the process of changing the way we do our work so we do it better to accomplish the goals of our business..

47. BPR(cont) Goals Identification of processes to reengineer
Reorganize complete flow of data in major sections of an organization
Eliminate unnecessary steps by combining them.
Become more responsive to future change
Identification of processes to reengineer
Key business processes
Set of activities designed to produce specific output for a particular customer or market
Focused on customers and outcome

48. Definition of Process
A process is simply a structured, measured set of activities designed to produce a specific output for a particular customers or market.
-- Thomas Davenport
Characteristics:
A specific sequencing of work activities across time and place
A beginning and an end
Clearly defined inputs and outputs
Customer-focus
How the work is done
Measurable and meaningful performance

49. BPR Examples Bill payments method (phone, water, electricity…etc)
Tuition payments
براءة الذمة
Selling, buying (e_business)
Internal correspondence (المراسلات الداخلية) using .

50. 4-Disruptive Technologies
Disruptive technologies are technologies that enable the breaking of long-held business rules that prevent organizations from making radical business changes.
A disruptive technology is one that displaces an established technology and shakes up the industry or a ground-breaking product that creates a completely new industry.  
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

51. Here are a few examples of disruptive technologies:
The personal computer (PC) displaced the typewriter and forever changed the way we work and communicate.
transformed the way we communicating, largely displacing letter-writing and disrupting the postal and greeting card industries. 
Cell phones: made it possible for people to call each other anywhere and disrupted the land telephone industry.
The laptop computer and Mobile computing made a mobile workforce possible and made it possible for people to connect to corporate networks and collaborate from anywhere. In many organizations, laptops replaced desktops.
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

52. Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
Cloud computing has been a hugely disruptive technology in the business world, displacing many resources that would have been located in-house or provided as a traditionally hosted service.
Social networking has had a major impact on the way we communicate and -- especially for personal use -- has disrupted telephone, , instant messaging and event planning.  
4/15/2018Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

53. Requirements Determination using Agile Methodologies
Continual user involvement
Replace traditional SDLC waterfall with iterative analyze–design–code–test cycle
Agile usage-centered design
Focuses on user goals, roles, and tasks
The Planning Game
Based on eXtreme programming
, Exploration(استكشاف) steering(توجيه), commitment
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

54. Continual User Involvement
FIGURE 6-9
The iterative analysis–design–code–test cycle
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

55. Agile Usage-Centered Design Steps
Gather group of programmers, analysts, users, testers, facilitator.
Document complaints of current system from customers
Determine important user roles.
Determine, prioritize, and describe tasks for each user role.
Group similar tasks into interaction contexts.
Associate each interaction context with a user interface for the system, and prototype the interaction context.
Step through and modify the prototype.
Chapter 6
Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

56. Requirements validation
Concerned with demonstrating that the requirements define the system that the customer really wants. Reduce requirements error costs.
Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.
Requirements checking
Validity. Does the system provide the functions which best support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer included?
Realism. Can the requirements be implemented given available budget and technology
Verifiability. Can the requirements be checked?

57. Requirements validation techniques Requirements reviews
Systematic manual analysis of the requirements. [system analyst and customers discuss the requirements]
Prototyping
Using an executable model of the system to check requirements.
Test-case generation
Developing tests for requirements to check testability.

58. Requirements management
is the process of managing changing requirements during the requirements engineering process and system development.
New requirements emerge as a system is being developed and after it has gone into use.
You need to keep track of individual requirements and maintain links between dependent requirements so that you can assess the impact of requirements changes. You need to establish a formal process for making change proposals and linking these to system requirements.

59. Changing requirements
The business and technical environment of the system always changes after installation.
What causes requirements to change?
New hardware may be introduced.
it may be necessary to interface the system with other systems, business priorities may change.
new legislation and regulations may be introduced that the system must necessarily abide by.
Large systems usually have a diverse user community, with many users having different requirements and priorities that may be conflicting or contradictory.