ZEIT2301
Design of Information Systems
Requirements Gathering
School of Engineering and Information Technology
UNSW@ADFA
Dr Kathryn Merrick
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
2
3
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
4
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.
5
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
6
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
7
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.
8
Criteria for quality requirements








Correct
Unambiguous
Complete
Consistent
Verifiable
Modifiable
Traceable
Ranked for importance
9
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.
3.4.5.2 Software shall be loaded onto the operational system
only after it has been tested and approved.
10
A bad requirement

“Provide a means to transport a single individual from
home to place of work”.
Management
Interpretation
IT
Interpretation
User
Interpretation
Ambiguous
11
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”
12
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
1.
2.
3.
Business process automation
Business process improvement
Business process reengineering
13
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
14
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
15
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
16
Selecting the Appropriate Strategies
Business
Process
Automation
Business
Process
Improvement
Business
Process
Reengineering
Potential benefit
Low–moderate
Moderate
High
Project cost
Low
Low–moderate
High
Breadth of
analysis
Narrow
Narrow-moderate
Very broad
Risk
Low–moderate
Low–moderate
Very high
17
Determining Requirements

Requirements are best determined by systems analysts
and business people together

Techniques available to the systems analyst:
1.
2.
3.
4.
5.
6.
Interviews
Questionnaires
Observation
Document analysis
Joint application development (JAD)
Throw-away prototyping
18
1. Interviews

Selecting interviewees


Designing interview questions


List questions, set priorities, schedule interview
Conducting the interview


unstructured (broad), structured (narrow)
Preparing for the interview


Different perspectives: managers, users
Be professional, record info, give interviewee time to ask
questions
Post-interview follow-up

Review notes, look for gaps
19
Interviewing Strategies
Top-down
High-level:
Very general
How
can order
processing be
improved?
How can we reduce the
Medium-level:
number of times that customers
Moderately specific
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
20
Types of Questions
Types of Questions
Closed-Ended Questions
Examples
*
*
*
Open-Ended Questions
*
*
*
Probing 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?
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?
Why?
Can you give me an example?
Can you explain that in a bit
more detail?
21
2. Questionnaires

Selecting participants


Designing the questionnaire


Careful question selection
Administering the questionnaire


Using samples of the population
Working to get good response rate
Questionnaire follow-up

Send results to participants
22
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
23
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
24
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
25
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
26
JAD Meeting Room
JPEG Figure 5-5 Goes Here
27
The JAD Session

May involve several days over a period of a few weeks

Prepare questions as with interviews

Formal agenda and ground rules
Key Roles

Facilitator activities





Keep session on track
Help with technical terms and jargon
Record group input
Help resolve issues
Post-session follow-up
Facilitator
Scribe
28
Managing Problems in JAD Sessions




Reducing domination
Encouraging non-contributors
Avoid side discussions
Agenda merry-go-round


Violent agreement


Help group select a better alternative
True conflict


Inconsistent terminology masks potential agreement
Unresolved conflict


the same issue raised continually
Document as an open issue
Use humor
29
Selecting Appropriate Techniques
Interview
JAD
Question Documen
-naires
t Analysis
Observati
on
Type of
information
As-is,
improves,
to-be
As-is,
improves,
to-be
As-is,
improves
As-is
As-is
Depth of info
High
High
Medium
Low
Low
Breadth of info
Low
Medium
High
High
Low
Info integration
Low
High
Low
Low
Low
User
involvement
Medium
High
Low
Low
Low
Cost
Medium
Lowmedium
Low
Low
Lowmedium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the new system
30
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.
31
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
32
Summary

After today’s lecture you should be aware of:

Functional and non-functional requirements

Quality requirements

Techniques for gathering system requirements
33