1. ZEIT2301 Design of Information Systems Requirements Gathering
Week 03:Requirements Determination
ZEIT2301 Design of Information Systems Requirements Gathering
School of Engineering and Information Technology
Dr Kathryn Merrick
Session 2, 2010

2. Week 03: Requirements Determination
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Week 03: Requirements Determination
Become familiar with requirements analysis techniques.
To identify criteria for a “good” requirement
To review requirements gathering techniques
Ref: text Ch 4
Session 2, 2010

4. Analysis phase of the SDLC
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Analysis phase of the SDLC
The System Request outlined the business need for a new system.
In the Analysis phase, the analyst needs to gain a more thorough understanding of the business problem domain and user requirements.
What exactly is the problem this system will address?
Output from this phase is a Requirements Definition Report and models which illustrate this required system functionality
Session 2, 2010

5. Analysis: What is the problem?
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Analysis: What is the problem?
In researching this question, the first challenge is finding the right people to question, interview or observe.
A stakeholder is a “person, group or organization that can affect (or be affected by) a new system.” (Dennis et al)
Identify particular user groups and how they will use the system.
The second challenge is collecting and integrating the information that has been obtained when researching the problem.
Mistakes made at this stage can negatively impact later phases.
Studies show that more than half of all system failures are due to problems with requirements.
Session 2, 2010

6. Requirements Determination
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Requirements Determination
Determining the precise requirements of the system - all capabilities and constraints
“A requirement is simply a statement of what the system must do or what characteristic it must have”. Dennis et al.
May change over time as the project moves from analysis to design to implementation
In the early stage of analysis, the emphasis is on business requirements – the “what” of the system
Later, in design, requirements become more technical – describe “how” the system will be implemented
Session 2, 2010

7. Functional and Non-Functional Requirements
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Functional and Non-Functional Requirements
Functional requirements
Activities the system must perform
Based on procedures and business functions
Documented in analysis models
Eg: the library system must produce a report of overdue books
Non-functional (technical) requirements
Describes operating environment, performance objectives, security considerations, cultural factors
Documented in narrative descriptions of technical requirements
Eg: the system must have a web interface; must interface with existing inventory system, etc
Session 2, 2010

8. Non-Functional Requirements
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Non-Functional Requirements
Requirement type
Example
Operational
The system should be able to fit in a pocket or purse
The system should be able to integrate with the existing inventory system.
Performance
Any interaction between the user and the system should not exceed 2 seconds.
The system should receive updated inventory information every 15 minutes.
Security
Only direct managers can see personnel records of staff
Customers can see their order history only during business hours.
Cultural & Political
The system should be able to distinguish between United States and European currency
The system shall comply with insurance industry standards.
Session 2, 2010

9. Criteria for quality requirements
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Criteria for quality requirements
Correct
Unambiguous
Complete
Consistent
Verifiable
Modifiable
Traceable
Ranked for importance
Source: IEEE Standard : IEEE Recommended Practice For Software Requirements Specifications
Session 2, 2010 9

10. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
A Bad Requirement
Software will not be loaded from unknown sources onto the system without first having the software tested and approved.
Ambiguous – if the software is tested and approved, can it be loaded from unknown sources?
(not) Testable – it is stated as a negative requirement making it difficult to verify.
(not) Traceable – a unique identifier is missing.
Software shall be loaded onto the operational system only after it has been tested and approved.
Session 2, 2010

11. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
A bad requirement
“Provide a means to transport a single individual from home to place of work”.
Management
Interpretation
I T
User
Ambiguous
Session 2, 2010

12. Prioritising Requirements
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Prioritising Requirements
MoSCoW Prioritisation
M - MUST have this.
S - SHOULD have this if at all possible.
C - COULD have this if it does not effect anything else.
W - WON'T have this time but would like in the future.
Managing change to avoid being overwhelmed by “requirements creep”
Session 2, 2010

13. Requirements Analysis Strategies
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Requirements Analysis Strategies
The basic process of requirements analysis is divided into:
Understanding the existing (as-is) system
Identifying improvements
Developing requirements for the new (to-be) system
There are three strategies for requirements analysis
Business process automation
Business process improvement
Business process reengineering
Session 2, 2010

14. 1. Business Process Automation
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
1. Business Process Automation
BPA leaves the basic way in which the organization operates unchanged and uses computer technology to do some of the work
Low risk, but low payoff
Planners in BPA projects invest significant time in understanding the current (as-is) system
Tends to solve problems rather than capitalize on opportunities
Improvements tend to be small and incremental Problem analysis
Session 2, 2010

15. 2. Business Process Improvement
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
2. Business Process Improvement
BPI makes moderate changes to the way in which the organization operates to take advantage of new opportunities offered by technology or to copy what competitors are doing
Typical approaches:
Duration analysis – examine how long it takes to complete each process
Activity-based costing – examine the cost of each minor process or step
Informal benchmarking – study how other organizations perform the process
Session 2, 2010

16. 3. Business Process Reengineering
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
3. Business Process Reengineering
BPR changes the fundamental way in which the organization operates
Limited study of the current (as-is) system
goal is to focus on new ideas and new ways of doing business
Popular activities:
Outcome analysis: eg outcomes from the customer’s point of view
Technology analysis: technological opportunities
Activity elimination: eg get customer to enter the info via the web
Session 2, 2010

17. Selecting the Appropriate Strategies
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Selecting the Appropriate Strategies
Business Process Automation
Business Process Improvement
Business Process Reengineering
Potential benefit
Low–moderate
Moderate
High
Project cost
Low
Breadth of analysis
Narrow
Narrow-moderate
Very broad
Risk
Very high
Session 2, 2010

18. Determining Requirements
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Determining Requirements
Requirements are best determined by systems analysts and business people together
Techniques available to the systems analyst:
Interviews
Questionnaires
Observation
Document analysis
Joint application development (JAD)
Throw-away prototyping
Session 2, 2010

19. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
1. Interviews
Selecting interviewees
Different perspectives: managers, users
Designing interview questions
unstructured (broad), structured (narrow)
Preparing for the interview
List questions, set priorities, schedule interview
Conducting the interview
Be professional, record info, give interviewee time to ask questions
Post-interview follow-up
Review notes, look for gaps
Session 2, 2010

20. Interviewing Strategies
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Interviewing Strategies
Top-down
How
can order
processing be
improved?
High-level:
Very general
Medium-level:
Moderately specific
How can we reduce the
number of times that customers
return ordered items?
Low-level:
Very specific
How can we reduce the number of
errors in order processing (e.g., shipping
the wrong products)?
Bottom-up
Session 2, 2010

21. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Types of Questions
Types of Questions
Examples
Closed-Ended Questions
* How many telephone
orders are received per day?
* How do customers place orders?
* What additional information
would you like the new system
to provide?
Open-Ended Questions
* What do you think about the
current system?
* What are some of the problems
you face on a daily basis?
* How do you decide what types of
marketing campaign to run?
Probing Questions
* Why?
* Can you give me an example?
* Can you explain that in a bit
more detail?
Session 2, 2010

22. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
2. Questionnaires
Selecting participants
Using samples of the population
Designing the questionnaire
Careful question selection
Administering the questionnaire
Working to get good response rate
Questionnaire follow-up
Send results to participants
Session 2, 2010

23. Good Questionnaire Design
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Good Questionnaire Design
Begin with non-threatening and interesting questions
Group items into logically coherent sections
Do not put important items at the very end of the questionnaire
Do not crowd a page with too many items
Avoid abbreviations
Avoid biased or suggestive items or terms
Number questions to avoid confusion
Pretest the questionnaire to identify confusing questions
Provide anonymity to respondents
Session 2, 2010

24. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
3. Observation
Observation helps check validity of information gathered other ways
Users/managers, when asked, often don’t remember everything they do
But behaviours change when people are watched
Be careful not to ignore periodic activities
Weekly … Monthly … Annual
Session 2, 2010

25. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
4. Document Analysis
Review existing reports, forms, and procedure descriptions
Provides clues about existing “as-is” current system
Typical documents
Forms
Reports
Policy manuals
Look for user additions to forms
Look for unused form elements
Session 2, 2010

26. 5. Joint Application Development
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
5. Joint Application Development
Allows project managers, users, and developers to work together
May reduce scope creep by 50%
Avoids requirements being too specific or too vague
Often the most useful method for collecting information from users
Session 2, 2010

27. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
JAD Meeting Room
JPEG Figure 5-5 Goes Here
Session 2, 2010

28. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
The JAD Session
May involve several days over a period of a few weeks
Prepare questions as with interviews
Formal agenda and ground rules
Facilitator activities
Keep session on track
Help with technical terms and jargon
Record group input
Help resolve issues
Post-session follow-up
Key Roles
Facilitator
Scribe
Session 2, 2010

29. Managing Problems in JAD Sessions
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Managing Problems in JAD Sessions
Reducing domination
Encouraging non-contributors
Avoid side discussions
Agenda merry-go-round
the same issue raised continually
Violent agreement
Inconsistent terminology masks potential agreement
Unresolved conflict
Help group select a better alternative
True conflict
Document as an open issue
Use humor
Session 2, 2010

30. Selecting Appropriate Techniques
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
Selecting Appropriate Techniques
Interview
JAD
Question-naires
Document Analysis
Observation
Type of information
As-is, improves, to-be
As-is, improves
As-is
Depth of info
High
Medium
Low
Breadth of info
Info integration
User involvement
Cost
Low-medium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the new system
Session 2, 2010

31. 6. Prototyping in the Requirements phase
ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
6. Prototyping in the Requirements phase
In RAD (Rapid Application Development), an ultimate technique of the requirements phase is rapid prototyping of the solution
This assists in clarifying difficult requirements and helps avoid misunderstandings
Agile, XP (eXtreme programming) and phased development methodologies emphasise involving users and using prototyping to elicit requirements in an incremental fashion.
Session 2, 2010

32. ZEIT2301 Design of Information Systems
Week 03:Requirements Determination
The System Proposal
The System Proposal is the result of the planning and analysis phases
The System Proposal typically includes:
Executive summary
System request
Work plan
Feasibility analysis
Requirements definition
Evolving system models
Session 2, 2010

33. Summary After today’s lecture you should be aware of:
Functional and non-functional requirements
Quality requirements
Techniques for gathering system requirements