3
REQUIREMENTS
ANALYSIS I
Software Engineering Roadmap: Chapter 3 Focus
Obtain customer’s wants
and needs (C-requirements)
Identify
corporate
practices
Refine
requirements
(next chapter)
Express C-requirements
prose
use cases
state diagrams
data-flow diagrams
Plan
project
Analyze
requirements
Maintain
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Chapter Learning Goals
• Distinguish C- (Customer) requirements
from D- (Detailed) requirements
• Be equipped with ways
to express C-requirements
–
–
–
–
exploit use cases
exploit state diagrams
exploit data flow diagrams
sketch user interfaces
• Be able to write first parts of a
Software Requirements Specification
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Introduction to requirements analysis
C- vs D-Requirements
SRS (IEEE)
1. Introduction
2. Overall
description
Crequirements
Drequirements
3. Specific
requirements
4. Supporting
information
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
To Be Performed With Each Requirement
Each requirement must be …
 expressed properly,
 made easily accessible,
 numbered,
 accompanied by tests that verify it,
 provided for in the design,
 accounted for by code,
 tested in isolation,
 tested in concert with other requirements, and
 validated by testing after the application has been
built.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Typical RoadMap for Customer (“C-”) Requirements
1. Identify “the customer” -- see section 2.2
2. Interview customer representatives
• identify wants and needs
• exploit tools for expression (section 3.1 - 3.4)
• sketch GUI’s (section 3.5)
• identify hardware
Review with customer
3. Write C-requirements
in standard document form (see case study)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Identify “the customer” -- see section 2.2
Typical RoadMap for
Customer (“C-”)
Requirements
2. Interview customer representatives
• identify wants and needs
• exploit tools for expression (section 3.1 - 3.4)
• sketch GUI’s (section 3.5)
• identify hardware
Review with customer
3. Write C-requirements
in standard document form (see case study)
For all stages,track metrics, e.g.,
4. Inspect
• time spent
C-requirements
• quantity accomplished
pages of C-requirements
mins. of customer interaction per pg. On customer approval ...
• self-assessed quality (1-10 scale)
5. Build D-requirements
• defect rates from inspections
(next chapter)
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
IEEE 830-1993 SRS Table of Contents
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications
interfaces
IEEE 830-1993 SRS Table of Contents
tbd: get copyright permission from IEEE
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications
interfaces
2.1.6. Memory constraints
2.1.7. Operations
2.1.8. Site adaptation
requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and
dependencies
2.6. Apportioning of
requirements
3. Specific requirements
-- see chapter four -4. Supporting information
-- see chapter four --
2. Customer interaction
Sources of Requirements: People vs. Other
decision
support system
for military
tactics
unconstrained
Type of
application
highly
constrained
missile guidance system
Relatively
low
Relatively
high
Approximate % of requirements gathered from people
Sources of Requirements: People vs. Other (adapted from Brackett [Br]
decision support system for military tactics
unconstrained
Encounter video game
corporate accounting system
manufacturing control system
Type of
application
enhancement to corporate accounting system
flight control system for airliner
highly
constrained
Relatively
low
missile guidance system
Approximate % of requirements
gathered from people
Relatively
high
Example Application: Encounter (1/2)
• Role-playing game which simulates all or part
of the lifetime of the player's character.
• Game characters not under the player’s
control called "foreign" characters.
• Game characters have a number of qualities
such as strength, speed, patience etc.
• Each quality has a value
• Characters "encounter" each other when in
the same area, and may then "engage" each
other.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Example Application: Encounter (2/2)
• The result of the engagement depends on the
values of their qualities and on the area in
which the engagement takes place.
• Player characters may reallocate their
qualities, except while a foreign character is
present.
• Reallocation taking effect after a delay, during
which the player may be forced to engage.
• Success is measured …
• by the "life points" maximum attained by
the player - or • by living as long as possible.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Before interview:
1. List and prioritize “customer” interviewees
– most likely to determine project’s success
2. Schedule interview with fixed start and end times
– at least two from development team should attend
– prepare to tape?
At interview:
3. Concentrate on listening Handle Interviews
Don’t be passive: probe and encourage
– persist in understanding wants and exploring needs
– walk through use cases, also data flow? state diagrams?
Take thorough notes
4. Schedule follow-up meeting
After interview:
5. Draft SRS C-requirements using a standard
6. E-mail customer for comments
4. Describing customer (C-) requirements
Initialize Use Case for Encounter
actors
Encounter
Use case
Initialize
player
Travel to
adjacent
area
Initialize
1. System displays player’s
main character in the
dressing room.
2. System displays a window
for setting his character's
qualities.
3. . . . .
Encounter
foreign
character
designer
Use case details
Set rules
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Initialize Use Case for Encounter
actors
Encounter
Use case
Initialize
player
Travel to
adjacent
area
Encounter
foreign
character
designer
Set rules
Use case details
Initialize
1. System displays player’s
main character in the
dressing room.
2. System displays a window
for setting his character's
qualities.
3. Player allocates the
qualities of his main
character.
4. Player chooses an exit
from the dressing room.
5. System moves player’s
main character into the area
on the other side of the exit.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Engage Foreign Character Use Case
Encounter
Use case
Initialize
player
Travel to
adjacent
area
Engage
foreign
character
designer
Set rules
Use case details
Engage Foreign Character
1. System displays the
foreign character in the
same area as the player’s.
2. System exchanges
quality values between the
two characters.
3. System displays the
results of the engagement.
4. System displays player’s
character in a random
area.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Data Flow Diagram: Explanation of Symbols
Processing
element
Get
deposit
Direction
of data flow
Check
deposit
Account #
& deposit
Data type
Data Flow Diagram: Explanation of Symbols
Processing
element
Input
Get
deposit
Direction
of data flow
Check
deposit
User
Account #
& deposit
Output
Data type
Printer
…...
balance
query
account
Data store
database
account
data
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Create
account
summary
member
banks
bank
name
Partial Data Flow
Diagram for ATM
Application
Get
deposit
Get
inquiry
User
error
account #
account #
& deposit
account
display
Validate
inquiry
Validate
deposit
account #
& deposit
Display
account
Make
inquiry
account #
Printer
account
data
Do
deposit
transaction
error
deposit
transaction
balance
query
account
database
account
data
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Create
account
summary
Partial Encounter State-Transition Diagram
Preparing
Setting up
Complete
setup
Waiting
Player
clicks
qualities
menu
Foreign
character
enters
area
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Engaging
Using Conditions in State-Transition Diagrams
state
event
Waiting
condition
Player
moves to
adjacent
area
[foreign
character
present]
[foreign
character
absent]
Engaging
condition
state
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Sketch of Encounter State-Transition Diagram
Setting up
Player
completes
setup
Player
dismisses
report
window
Player
dismisses
set
qualities
widow
Setting
qualities
Reporting
Player
requests
status
Player
requests to
set
qualities
Foreign
character
enters area
Waiting
Player moves
to adjacent area
Player
quits
Foreign
character
enters area
Encounter
completed
Engaging
[foreign
character
absent]
[foreign character
present]
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Steps for ConstructingUser Interfaces*
Step 1: Know your user
(C)‡
Step 2: Understand the business function in question
(C)
Step 3: Apply principles of good screen design
(C, D)
Step 4: Select the appropriate kind of windows
(C, D)
Step 5: . . . . .
* adapted from Galitz [Ga2] ‡ a C-requirement process
Step 1: Know your user
Steps for Constructing
User Interfaces*
(C)‡
Step 2: Understand the business function in question
(C)
Step 3: Apply principles of good screen design
(C, D)
Step 4: Select the appropriate kind of windows
(C, D)
Step 5: Develop system menus
(C, D)
Step 6: Select the appropriate device-based controls
(C)
Step 7: Choose the appropriate screen-based controls (C)
Step 8: Organize and lay out windows
(C, D)
Step 9: Choose appropriate colors
(D)
Step 10: Create meaningful icons
(C, D)
Step 11: Provide effective message, feedback, & guidance (D)
* adapted from Galitz [Ga2] ‡ a C-requirement process
Know Your Users 1*
•
Level of knowledge and experience
– computer literacy
high / moderate / [ low  explain every term ** ]
– system experience
high / moderate / [ low  provide examples & animations ]
– experience with similar applications
high / moderate / [ low  provide examples & animations ]
– education
advanced degree / [ college / high school  use 12th-grade terms ]
– reading level
>12 year’s schooling / 5-12 / [ < 5  use very simple language ]
– typing skill
135 wpm / 55 wpm / [ 10 wpm  provide smaller text boxes;
provide samples; emphasize fill-in-the-blank forms ]
•
Physical characteristics of the user
–
–
–
–
Age
young / middle aged / [ elderly  use age-appropriate examples ]
Gender
male / female
Handedness left / right / ambidextrous
Physical handicaps
blind / defective vision / deaf / motor handicap
* adapted from Galitz [Ga2]
** suggested actions for the latter, added by the author
•
Level of knowledge and experience
–
–
–
–
–
–
•
Know
Your
Users*
Characteristics of the user’s tasks and jobs
–
–
–
–
–
–
–
•
computer literacy
(high; moderate; low)
system experience
(high; moderate; low)
experience with similar applications (high; moderate; low)
education
(high school; college; advanced degree)
reading level
(>12 year’s schooling; 5-12; < 5)
typing skill
(135 wpm; 55 wpm; 10 wpm)
Type of use of this application (mandatory; discretionary)
Frequency of use
(continual; frequent; occasional; once-in-a-lifetime)
Turnover rate for employees (high; moderate; low)
Importance of task
(high; moderate; low)
Repetitiveness of task (high; moderate; low)
Training anticipated (extensive; self-training through manuals; none)
Job category
(executive; manager; professional; secretary; clerk etc.)
Psychological characteristics of the user
– Probable attitude towards job (positive; neutral; negative)
– Probable motivation (high; moderate; low)
– Cognitive style
(verbal vs. spatial; analytic vs. intuitive; concrete vs. abstract)
•
Physical characteristics of the user
–
–
–
–
Age
Gender
Handedness
Physical handicaps
(young; middle aged; elderly)
(male; female)
* adapted from Galitz [Ga2]
(left; right; ambidextrous)
(blind; defective vision; deaf; motor handicap)
• Ensure consistency among the screens of designated
applications, and among screens within each
– conventions; procedures; look-and-feel; locations
• Anticipate where the user will usually start
– frequently upper left -- place “first” element there
• Make navigation as simple as possible
Principles of Good
– align like elements
– group like elements
Screen Design*
– consider borders around like elements
• Apply a hierarchy to emphasize order of importance
• Apply principles of pleasing visuals -- usually:
– balance; symmetry; regularity; predictability
– simplicity; unity; proportion; economy
• Provide captions
* see Galitz [Ga2]
Applying Principles of Good Screen Design: “Before”
Type
checking
Branch
Main St.
Privileges
saving
Elm St.
newsletter
mmf
CD
High St.
discounts
quick loans
First name
Middle name
Last name
Street
City
State/county
OK
Apply
Cancel
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Help
* see Galitz [Ga2]
Applying Principles of Good Screen Design: “After”
New Customers
Name
Address
First
Street
Middle
City
Last
State/county
Branch
Account type
Privileges
checking
saving
mmf
CD
Main St.
Elm St.
High St.
OK
Apply
Cancel
newsletter
discounts
quick loans
Help
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
How Principles of Good Screen
Design Were Applied
Anticipate start
New Customers
Name
Address
First
Street
Middle
Align like elements
City
Last
State/county
Branch
Ensure consistency
Border around like elements
Use Captions Account type
Privileges
checking
saving
Symmetry
mmf
CD
Main St.
Elm St.
High St.
Group
like elements
newsletter
discounts
Balance
quick loans
Proportion
OK
Apply
Cancel
Help
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Purpose: display properties of an entity
-- property window
Properties of automobile 189
Property Value
Brand
Toyota
Window Usage
1of 2
Model
ID
Camry
893-8913-789014
2. Purpose: obtain additional information so as to carry
out a particular task or command
-- dialog window
Help
Word ___________________
This screen
All screens
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Purpose:
provide information
-- message window
ABC alert message
Caution: “age” must be < 120
OK
Window Usage 2of 2
4. Purpose:
present a set of controls
-- palette window
ABC controls
File Edit View Format Tools Help
monitor
5. Purpose:
amplify information
-- pop-up window
disk
keyboard
modem
This is a popup
window, designed to
provide on-the-fly
amplification
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Develop System Menus
• Provide a main menu
• Display all relevant alternatives (only)
• Match the menu structure to the
structure of the application’s task
• Minimize the number of menu levels
– Four maximum?
Common GUI Terms
Cascading windows
Tiled
windows
Icon
New Customer
Text box
Name
Screen
First
forward
Last
Radio
button
Button
back
Account type
checking
saving
mmf
Cancel
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Privileges
newsletter
discounts
Apply
Check box
Graphics reproduced with permission from Corel.
Preliminary Sketch of User Interface for Setting
Game Character Qualities
16
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Preliminary Encounter Screen Shot
Name of
adjacent area
Name of
adjacent area
Name of
adjacent area
Name of
adjacent area
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission.
Graphics reproduced with permission from Corel.
Express Customer Requirements 1/2
• If the requirement is simple, and stands alone,
express it in clear sentences within an appropriate
section of the SRS
• If the requirement is an interaction between the user
and the application, express via a use case.
1. Name the use case
2. Identify the “actor”
• the external user role-- usually a person
3. Write the sequence of user - application actions
• Minimize branching
• Use general form.
Avoid specific names and values as in “Ed enters $300”.
Instead, say “customer enters deposit amount”.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
• If the requirement involves process elements, each
taking inputs, and producing outputs, use data flow.
1. Identify the processing elements (usually high level);
as circles or rectangles
2. Identify the data sources & destinations;
as names between two horizontal lines
3. Show the data paths among processing elements.
Indicate types of data flowing on each
show
show
• If the requirement involves states that the application
can be in (or parts can be in)
1. Identify the states (each a passive
verb,
e.g., “waiting”);
Express Customer
show as rounded rectangles
Requirements 2/2
2. Show initial state with special arrow
3. Identify the events (happenings external to the unit) that
cause transitions among the states; show as labeled arrows
4. Identify sub-states; show as rectangles within rectangles
5. Rapid prototyping, feasibility studies, and
proofs of concept
Prototype Payoff: First Cut
Calculate payoff
in detail
Perceived value
of prototype
low
high
Low prototype cost maybe yes
High prototype cost no maybe
Calculate payoff
in detail
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Prototype Payoff
Payoff from building
prototype ($’s saved
per $1 spent)
0%
% expenditure
on prototype
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
100%
Prototype Payoff
Payoff from building
prototype ($’s saved
per $1 spent)
full
project
expenditure
optimal
expenditure
on
prototype
% expenditure
on prototype
0%
GUI
only
waste of resources
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
100%
Estimates for E-commerce Clothing Application
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Prototype Payoff Calculations for E-commerce Clothing Application
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
6. Updating the project to reflect C-requirements
analysis
Updating Project Plan After Obtaining C-requirements
Status after initial
draft
Milestones
Result of updating SPMP after
obtaining C-requirements
Initial
More milestones; more specific
Identify initial risks
Retire risks identified previously;
identify more risks now that more is
known about the project
Schedule
Very rough
Preliminary project schedule
Personnel
Designate Crequirements
engineers
Designated engineers for Drequirements analysis
Very rough
First estimates based on job content
Risks
Cost
Estimation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Typical Schedule After D-requirements Analysis
Milestones
17-May
31-May
13-Jun
Complete release 0.1
27-Jun
11-Jul
25-Jul
11-Aug
25-Aug
8-Sep
X
Complete release 0.2 X
Develop release 0.1
C-requirements
D-requirements
Architecture
Detailed design
Implementation
Test
Develop release 0.1
C-requirements
D-requirements
Architecture
Detailed design
Implementation
Unit test
Integration
System test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Schedule After D-requirements Analysis
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
SRS rev. 2.1
1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, acronyms
& abbreviations
1.4. References
1.5. Overview
2. Overall description
2.1. Product perspective
2.1.1. System interfaces
2.1.2. User interfaces
2.1.3. Hardware interfaces
2.1.4. Software interfaces
2.1.5. Communications
interfaces
rev 3
rev 2
rev 3
rev 2
rev 1
rev 3
rev 4
rev 4
rev 2
rev 1
rev 1
rev 4
rev 1
5/27/98
2.1.6. Memory constraints
2.1.7. Operations
2.1.8. Site adaptation
requirements
2.2. Product functions
2.3. User characteristics
2.4. Constraints
2.5. Assumptions and
dependencies
2.6. Apportioning of
requirements
3. Specific requirements
-- see next chapter -4. Supporting information
rev 4
rev 1
rev 4
rev 3
rev 3
rev 3
rev 4
rev 1
rev 6
rev 3
7. Future directions and summary of CRequirements
Chapter Summary
• C-requirements for customer
– include user interfaces
• D-requirements for developers
• Use standard SRS (e.g. IEEE)
• Use cases shown very effective
– reuse as test cases
• State- and data flow- diagrams can be
effective specifications as well
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Student Guide and Case Study
This project
//
organization
norm
Time spent
(minutes)
% Time spent
Preparation
Interview
Write-up
(results of
inspection)
Review
Total
200 mins
170 mins
270 mins
250 mins
14.8
hours
250/890 = 28%
// 20%
170/890 = 19%
// 23%
270/890 = 30%
// 27%
200/890 = 22%
// 29%
Quantity produced
15 pages
Productivity
(= Time/quantity)
Self-assessed
quality (1-10)
15/14.8 = 1.01
pages per hour //
0.95
9
5
Defect rate
Process
improvement
Table 3.2
Postmortem
Results
9
2
1.3 per page
// 1.01 per page
Spend ~20%
less time
preparing
Spread
interview time
more evenly
among
different
people
Material well
written initially,
but should be
checked more
thoroughly prior
to inspection.
Spend ±30% more time
reviewing
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.