Requirement Analysis
Prof. Dr. Daning Hu
Department of Informatics
University of Zurich
Some of the contents are adapted from “System Analysis and Design” by Dennis,
Wixom, &Tegarden.
Project Requirements Analysis and
System Specification
Why is it one of first activities in (software) project life cycle?
Need to understand what customer wants first!
Goal is to understand the customer’s problem.
Though customer may not fully understand it!
Requirements analysis says: “Make a list of the guidelines we
will use to know when the job is done and the customer is
satisfied.”
Also called requirements gathering or requirements engineering
System specification says: “Here’s a description of what the
program/system will do (not how) to satisfy the requirements.”
Distinguish requirements gathering & system analysis?
A top-level exploration into the problem and discovery
of whether it can be done and how long it will take.
Objectives of Requirement Analysis
Understand how to create a requirements definition.
Become familiar with requirements analysis
techniques.
Understand when to use each requirements analysis
technique.
Understand how to gather requirements using
interviews, JAD sessions, questionnaires, document
analysis, and observation.
4
Determining Requirements
A statement of what the system must do or what
characteristic it must have.
During analysis, requirements are written from the
perspective of the business people (users).
Two kinds of requirements:
Functional
Nonfunctional
5
Nonfunctional Requirements
6
A Good Requirement
Correct
Unambiguous
Consistent
Verifiable
Modifiable
Traceable
Ranked for importance 7
A Bad Requirement
Initial Specification: Software will not be loaded from
unknown sources onto the system without first having
the software tested and approved.
Critique:
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.
Re-specification: 3.4.5.2 Software shall be loaded onto
the operational system only after it has been tested and
approved. 8
Requirements Analysis Strategies
The basic process of analysis is divided into:
Understanding the as-is system
Identifying improvements
Developing requirements for the to-be system
There are 3 major requirements analysis strategies
Business process automation
Business process improvement
Business process reengineering
9
Business Process Automation
BPA leaves the basic way in which the organization
operates unchanged and uses computer technology to
automate some of the work.
Low risk, but low payoff.
Planners in BPA projects invest significant time in
understanding the as-is system using:
Problem analysis
Root cause analysis
10
Problem Analysis
Users and managers identify problems with the as-is
system and describe how to solve them in the to-be
system.
Tends to solve problems rather than capitalize on
opportunities.
Improvements tend to be small and incremental.
11
Root Cause Analysis
Users are not asked for solutions, but for:
A list of (prioritized) problems.
All possible root causes for those problems.
Analysts investigate each root cause to find:
Solutions for the highest priority problems.
Root causes that are common to multiple problems.
12
Root Cause Analysis Example
13
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.
Common activities:
Duration analysis
Activity-based costing
Informal benchmarking
14
Business Process Reengineering
BPR changes the fundamental way in which the
organization operates.
Spends little time understanding the as-is, because
their goal is to focus on new ideas and new ways of
doing business.
Popular activities:
Outcome analysis
Technology analysis
Activity elimination
15
Selecting the Appropriate Strategies
16
Determining Requirements
Requirements are best determined by systems analysts
and business people (users) together.
Techniques available to systems analysts:
Interviews
Questionnaires
Observation
Document analysis
Joint application development (JAD)
17
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
18
Interviewing Strategies
Top-down
How
can order
High-level: processing be
Very general improved?
Medium-level: How can we reduce the
Moderately specific number of times that customers
return ordered items?
Low-level: How can we reduce the number of
Very specific errors in order processing (e.g., shipping
the wrong products)?
Bottom-up
19
Types of Questions
Types of Questions Examples
* How many telephone orders
are received per day?
Closed-Ended Questions * How do customers place orders?
* What additional information
would you like?
* What do you think about the
current system?
Open-Ended Questions * What are some of the problems
you face on a daily basis?
* How do you decide what types of
marketing campaign to run?
* Why?
Probing Questions * Can you give me an example?
* Can you explain that more?
20
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
21
Good Questionnaire Designs
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
22
3. Observation
Observation helps check validity of information gathered
other ways.
Users/managers, when asked, often don’t remember everything
they do.
Most importantly, provide longitudinal information
But behaviors change when people are watched.
Be careful not to ignore periodic activities
Weekly … Monthly … Annual.
23
4. Document (Data) 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.
24
5. Joint Application Development (JAD)
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.
25
JAD Meeting Room
JPEG Figure 5-5 Goes Here
26
The JAD Sessions
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 Key Roles
Help resolve issues Facilitator
Scribe
Post-session follow-up
27
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
28
Selecting Appropriate Techniques
Interview JAD Question- Document Observation
naires Analysis
Type of As-is, As-is, As-is, As-is As-is
information improves, improves, improves
to-be to-be
Depth of info High High Medium Low Low
Breadth of info Low Medium High High Low
Info integration Low High Low Low Low
User Medium High Low Low Low
involvement
Cost Medium Low- Low Low Low-medium
medium
As-is : understanding current system
Improves: identifies improvements
To-be: developing the new system 29
