REQUIREMENTS

ANALYSIS
 Software Engineering Roadmap
Obtain customer’s wants Refine
and needs (C-requirements) requirements
Identify
corporate
practices Express C-requirements
prose
use cases
Plan state diagrams
project data-flow diagrams

Analyze Maintain
requirements
Integrate
Design & test system
Implement Test units
 C- vs D-Requirements

SRS (IEEE)
1. Introduction
D-
2. Overall
requirements
C- description
requirements 3. Specific
requirements
4. Supporting
information
 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.
 Typical RoadMap for
1. Identify “the customer” Customer (“C-”)
Requirements

2. Interview customer representatives

• identify wants and needs Review with customer
• exploit tools for expression
• sketch GUI’s
• identify hardware

3. Write C-requirements
in standard document form

4. Inspect
C-requirements
On customer approval ...
5. Build D-requirements
(next chapter)
 IEEE 830-1993 SRS Table of Contents
tbd: get copyright permission from IEEE

1. Introduction 2.1.6. Memory constraints

1.1. Purpose 2.1.7. Operations
1.2. Scope 2.1.8. Site adaptation
1.3. Definitions, acronyms requirements
& abbreviations 2.2. Product functions
1.4. References 2.3. User characteristics
1.5. Overview 2.4. Constraints
2. Overall description 2.5. Assumptions and
2.1. Product perspective dependencies
2.1.1. System interfaces 2.6. Apportioning of
2.1.2. User interfaces requirements
2.1.3. Hardware interfaces 3. Specific requirements
2.1.4. Software interfaces -- see chapter four --
2.1.5. Communications 4. Supporting information
-- see chapter four --
 Requirements: Necessity not Luxury

• A defective requirement is 20-50 times

more expensive to repair at end of a project
than at beginning ($100 -> $2000-5000)
• Requirements analysis is something we
must afford to due
• So why do we not do it?
• So why do we not do it well?
Instead … code and test, code and test
 Project Stakeholders

Stakeholder Perspective
• Owner Scope
• Users Requirements (what)
• Designers Arch./Design (how)
• Builders Implementation/Testing
What the Users wanted What the Owners What the Designers and
are willing to pay Builders developed
What needs to be done with these requirements?

• Enhance / refine / remove ambiguities via

communications with customer
• Determine the musts, wants and nice to
haves
• Organizing and numbering the requirements
for tracability
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: Handle Interviews
3. Concentrate on listening
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
 Modeling Tools for Capturing Requirements

• List of requirements
• Use case diagrams
• Entity relationship diagrams (ERD)
• Data flow diagrams
• State (transition) diagrams
• Screen prototyping (story-boards)
Initialize Use Case for Encounter
actors Encounter Use case details
Initialize
Use case
Initialize 1. System displays player’s
main character in the
dressing room.
Travel to
2. System displays a window
adjacent for setting his character's
player
area qualities.
3. Player allocates the
Encounter qualities of his main
character.
foreign 4. Player chooses an exit
character from the dressing room.
5. System moves player’s
designer Set rules 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 details
Use case Engage Foreign Character
Initialize 1. System displays the
foreign character in the
Travel to same area as the player’s.
player adjacent 2. System exchanges
area quality values between the
two characters.
Engage 3. System displays the
foreign results of the engagement.
character 4. System displays player’s
character in a random
designer
area.
Set rules

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
 Sketch of Encounter State-Transition Diagram
Player Reporting Setting
Setting up dismisses
report qualities
Player window
completes
setup
Player Player
dismisses Player requests to
set requests set
qualities status qualities Foreign
widow character
enters area
Waiting
Foreign Encounter
character completed
Player moves
to adjacent enters area
Player area Engaging
quits
[foreign [foreign character
character present]
absent]
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Conceptualizing a System in terms of the User Interface

• Customers/Users often conceive a system in

terms of its user interface
• Screen prototyping and story boarding
(screen facade but no code) works well in
connection with Use Case
 Steps for Constructing
Step 1: Know your user 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
• Level of knowledge and experience
–
–
computer literacy
system experience
(high; moderate; low)
(high; moderate; low)
Know
– experience with similar applications (high; moderate; low) Your
– education (high school; college; advanced degree)
– reading level (>12 year’s schooling; 5-12; < 5) Users*
– typing skill (135 wpm; 55 wpm; 10 wpm)
• Characteristics of the user’s tasks and jobs
– 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 (young; middle aged; elderly)
– Gender (male; female)
– Handedness (left; right; ambidextrous)
* adapted from Galitz [Ga2]
– Physical handicaps (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
– align like elements Principles of Good
– 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 saving mmf CD

Branch Main St. Elm St. High St.

Privileges newsletter discounts quick loans

First name
Middle name

Last name

Street
City

State/county

OK Apply Cancel Help

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. * 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

Main St. checking newsletter

saving
Elm St. discounts
mmf
High St. quick loans
CD

OK Apply Cancel Help

 How Principles of Good Screen
New Customers Anticipate start Design Were Applied

Name Address

First Street Ensure consistency

Align like elements
Middle City

Last State/county
Border around like elements

Branch Use Captions Account type Privileges

Main St. checking newsletter

saving
Elm St. Symmetry Balance
discounts
mmf
High St. quick loans
CD
Group
like elements Proportion
OK Apply Cancel Help
 Develop System Menus

• Provide a main menu

• Display all relevant alternatives (only)

• Menu structure should match application

tasks

• Minimize the number of menu levels

 Common GUI Terms

Cascading windows
Icon
Tiled New Customer
windows Name Screen
Text box
First
forward
Last
back

Account type Privileges

Radio checking newsletter
button saving
discounts
mmf

Button Cancel Apply

Check box
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.
 Preliminary Encounter Screen Shot
Name of Name of
adjacent area 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); show
as circles or rectangles
2. Identify the data sources & destinations; show
as names between two horizontal lines
3. Show the data paths among processing elements.
Indicate types of data flowing on each
• 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”);
show as rounded rectangles
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
 Updating Project Plan After Obtaining C-requirements

  Status after initial Result of updating SPMP after

draft obtaining C-requirements

Milestones Initial More milestones; more specific

Retire risks identified previously;

Risks Identify initial risks identify more risks now that more is known
about the project

Schedule  Very rough Preliminary project schedule

Designate C-
Designated engineers for D-
Personnel requirements
engineers requirements analysis

Cost
Very rough  First estimates based on job content
Estimation

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
 Typical Schedule After C-requirements Analysis
17-May 31-May 13-Jun 27-Jun 11-Jul 25-Jul 11-Aug 25-Aug 8-Sep
Milestones Complete release 0.1 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.
 SRS rev. 2.1 5/27/2008

1. Introduction rev 3 2.1.6. Memory constraints rev 4

1.1. Purpose rev 2 2.1.7. Operations rev 1
1.2. Scope rev 3 2.1.8. Site adaptation
1.3. Definitions, acronyms requirements rev 4
& abbreviations rev 2 2.2. Product functions rev 3
1.4. References rev 1 2.3. User characteristics rev 3
1.5. Overview rev 3 2.4. Constraints rev 3
2. Overall description rev 4 2.5. Assumptions and
2.1. Product perspective rev 4 dependencies rev 4
2.1.1. System interfaces rev 2 2.6. Apportioning of
2.1.2. User interfaces rev 1 requirements rev 1
2.1.3. Hardware interfaces rev 1 3. Specific requirements rev 6
-- see next chapter --
2.1.4. Software interfaces rev 4 4. Supporting information rev 3
2.1.5. Communications
interfaces rev 1