Software Engineering
Modern Approaches
Eric Braude and Michael Bernstein
1
Chapter 12
© 2010 John Wiley & Sons Ltd.
2
Learning Goals of This Chapter
Planning
Maintenance
•
What ways are there to organize detailed
requirements?
•
How do you express user interfaces in
detail?
•
How do you express security requirements
in detail?
•
What kinds of error conditions can be
specified?
•
What is traceability and why is it important?
•
What ways are there to prioritize
requirements?
•
Why associate requirements with tests?
•
How do agile methods relate to detailed
requirements?
•
How do you use tools for requirements
3
analysis?
Testing
The Software
Development
Requirements
Lifecycle
analysis
Implementation
Design
Phase most
relevant to this
chapter is shown in
bold
3. Specific requirements (non-OO)
3.1 External interfaces
3.2 Functional requirements
3.3 Performance requirements
3.4 Logical database requirements
3.5 Design constraints
3.5.1 Standards compliance
3.6 Software system attributes
3.6.1 Reliability
3.6.2 Availability
3.6.3 Security
3.6.4 Maintainability
3.6.5 Portability
3.7 Organizing the specific requ.
3.7.1 System mode -- or
3.7.2 User class -- or
3.7.3 Objects (see right) -- or
3.7.4 Feature -- or
3.7.5 Stimulus -- or
3.7.6 Response -- or
3.7.7 Functional hierarchy -- or
3.8 Additional comments
IEEE 830-1998
Detailed Requirements
3. Specific requirements (OO)
3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Classes/Objects
3.2.1 Class/Object 1
3.2.1.1 Attributes
3.2.1.2 Functional requirements
3.2.1.3 Events . . . .
.......
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
4
© 2010 John Wiley & Sons Ltd.
The IEEE 830-1998 SRS Organization:
Detailed Requirements with OO organization
3. Specific requirements
3.1. External interface
requirements
3.1.1. User interfaces
3.1.2. Hardware interfaces
3.1.3. Software interfaces
3.1.4. Communications
interfaces
3.2. Classes/Objects
-- see section tbd -3.3.
Performance requirements
3.4.
Design constraints
3.5.
Software system attributes
3.6.
Other requirements
Interface requirements
Functional requirements
Other non-functional
requirements
5
© 2010 John Wiley & Sons Ltd.
Organizing Requirements by Use Case: Video Store Example
1. User hits any key
Activate
Check in DVD
2. System displays main menu
1. User swipes bar code
2. System displays due data
3. ...
clerk
1. . . . .
Check out DVD
Stock DVD
2.
1. User obtains “stock” screen
2. User enters name of DVD
3. . . .
buyer
© 2010 John Wiley & Sons Ltd.
.........
6
Organizing Video Store Requirements by GUI
Stock DVD
Title
Figure 2
Number of copies
3.1 Selecting Procedures
commit
The GUI for selecting procedures shall be as shown in
Figure 1. It shall be possible to select from the
following procedures by clicking on a radio button,
followed by the “go” button. ……..
Sketch of Select Procedure GUI
3.3 Checking out DVD’s
The GUI for checking out DVD’s shall be as
shown in Figure 3. It shall be possible to …
Check In DVD GUI Sketch
Select Procedure
Check Out DVD
Stock DVD
DVD name
Register customer
Figure 1
Check out DVD
Figure 3
Check in DVD
commit
go
3.4 Registering Customers
3.2 Stocking DVD’s
The GUI for stocking DVD’s shall be as shown in
Figure 2. It shall be possible to enter a DVD into the
system using the GUI in figure … The application
shall save the title – expressed in up to 30
alphanumeric characters – and the number of copies.
The latter shall range between 1 and 100, inclusive.
..…
…..
Sketch of Register Customer GUI
Register Customer
First name
Commit and check out DVD
© 2010 John Wiley & Sons Ltd.
Figure 4
Last name
commit
7
1. Obtain domain classes & objects from use cases and high-level requirements diagrams
2. Add additional essential domain classes
Inspect the resulting collection of classes
3 For each class,
specify the required attributes
specify the required functionality
specify how its objects react to events
draft test plans for each
inspect the results
Roadmap for
Detailed
Requirements
Using the Class
Style
© 2010 John Wiley & Sons Ltd.
4. Inspect against high-level requirements
5. Verify with customer where possible
When complete:
6. Release
8
Candidate Classes for Encounter
Game
Encounter Character
Engagement
Player
Exit
Area
Combat
Encounter
Map
Result
Passageway
(1) list every
reasonable
candidate class
you can think of
(this list), then
(2) drastically cut
down to a few
essential classes.
Room
Rule
Score
Connection Hyperlink
© 2010 John Wiley & Sons Ltd.
Encounter Area Connection
Engagement Display
Foreign Character
Game Character
Player Window
Exit Choice Window
Quality
Game
Door
9
Classes for Encounter Video Game,
Showing Only Inheritance Relationships
EncounterCharacter
EncounterAreaConnection
ConnectionHyperlink
PlayerCharacter
ForeignCharacter
PlayerQualityWindow
Engagement
EngagementDisplay
Key:
EncounterGame
Area
(1) list every
reasonable
candidate class
you can think of
then (2) drastically cut down to
a few essential
classes (this list).
A class in design and code, blanks eliminated
10
© 2010 John Wiley & Sons Ltd.
Methods of Organizing Requirements
Organizing
principle
By Feature
Advantages
 Maps well to why we are building the
application
 Easy to understand
 Does not map well to OO code
 Hard to locate random requirement
 Easy to understand
 Use cases may overlap
 Hard to trace to design and code
 Coverage is limited
 Easy to understand
 Not every function appears in a GUI
 Functionality of GUI’s overlap
 Hard to trace to design and code
 Easy to understand
 Design thinking begins early
 Classification can be unclear to the
customer
 Hard to allocate requirements to state
 Easy to trace to code
 Easy to locate random requirement
 Design thinking begins early
 Classification can be unclear to the
customer
By Use Case
By GUI
By State
By Class
© 2010 John Wiley & Sons Ltd.
Disadvantages
11
• 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
– group like elements
– consider borders around like elements
Principles of
Good Screen
Design*
• Apply a hierarchy to emphasize order of importance
• Apply principles of pleasing visuals -- usually:
– balance; symmetry; regularity; predictability
– simplicity; unity; proportion; economy
• Provide captions
© 2010 John Wiley & Sons Ltd.
* see Galitz [Ga2]
12
Applying Principles of Good Screen Design: “Before”
Type
checking
Branch
Main St.
saving
Elm St.
Privileges newsletter
mmf
CD
High St.
discounts
quick loans
First name
Middle name
Last name
Street
City
State/county
OK
Apply
Cancel
Help
* see Galitz [Ga2]
© 2010 John Wiley & Sons Ltd.
13
New Customers
Applying Principles of Good
Screen Design: “After”
Name
Address
First
Street
Middle
City
Last
State/county
Branch
Account type
Elm St.
High St.
OK
© 2010 John Wiley & Sons Ltd.
Privileges
checking
saving
mmf
CD
Main St.
Apply
Help
newsletter
discounts
quick loans
Cancel
14
New Customers
Anticipate start
Expected position
Help
Name
Address
First
Street
Align like elements
Middle
City
Last
State/county
Border around like elements
Branch Use Captions
Account type
Privileges
checking
saving
mmf
CD
Symmetry
Main St.
Elm St.
High St.
Group
like elements
newsletter
discounts
quick loans
Balance
Proportion
OK
© 2010 John Wiley & Sons Ltd.
Ensure consistency
Apply
Cancel
How Principles of Good
Screen Design Were Applied
15
1. Purpose: display properties of an entity
-- property window
Properties of automobile 189
Window Usage
1of 2
Property
Value
Brand
Toyota
Model
Camry
ID
893-8913-789014
2. Purpose: obtain additional information so as to carry
out a particular task or command
Help
-- dialog window
Word
___________________
This screen
© 2010 John Wiley & Sons Ltd.
All screens
16
3. Purpose:
provide information
-- message window
Window Usage 2of
2
4. Purpose:
present a set of controls
-- palette window
ABC alert message
Caution: “age” must be < 120
OK
ABC controls
File Edit View Format Tools Help
monitor
5. Purpose:
amplify information
-- pop-up window
© 2010 John Wiley & Sons Ltd.
disk
keyboard
modem
This is a popup window,
designed to provide onthe-fly amplification
17
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
© 2010 John Wiley & Sons Ltd.
18
Common GUI Terms
Cascading windows
Tiled
windows
Icon
New Customer
Text box
Name
Screen
First
forward
Last
Radio
button
Button
© 2010 John Wiley & Sons Ltd.
back
Account type
checking
saving
mmf
Cancel
Privileges
newsletter
discounts
Apply
Check box
19
Graphics reproduced with permission from Corel.
Detailed Security Requirements 1
1. User identification capabilities

Rules on ID’s, name clashes, restrictions, etc.
2. Person or entity authentication capabilities

Exact requirements permitting access to resources
3. Security logoff

Measures to prevent unattended or unusual usage
4. Audit trails of security-related events

Type, outcome, state at the time, date & time,
source
© 2010 John Wiley & Sons Ltd.
20
Detailed Security Requirements 2
5. Password specifications

Length, composition, allows characters, etc.
6. Controls to ensure data integrity
7. Retrievable record of encryption methods
8. Information on security attributes of the
system
© 2010 John Wiley & Sons Ltd.
21
Requirement Without Necessary Errors (Myers)
A function that tells whether three numbers
produce an equilateral triangle (all sides
equal), an isosceles triangle (exactly two
sides equal), or a scalene triangle (all sides
different).
22
© 2010 John Wiley & Sons Ltd.
… More Complete
A function that tells whether a triplet of numbers produces:
(1) an equilateral triangle (whose sides are all greater than zero
and equal), in which case it outputs ‘E’ at the prompt, or
(2) an isosceles triangle (whose sides are greater than zero,
exactly two of which are equal, and which form a triangle), in
which case it outputs ‘I’ at the system, or
(3) a scalene triangle (whose sides are all greater than zero,
which form a triangle, and which is neither equilateral nor
isosceles), in which case it outputs ‘S’ at the prompt, or
(4) no triangle, in which case it outputs ‘N’ at the prompt.
23
© 2010 John Wiley & Sons Ltd.
My-D-Requirement**
Tracing a Detailed Requirement
Requirement inspection report incorporating My-D-Requirement
Design segment incorporating My-D-Requirement
Design inspection report incorporating My-D-Requirement
*
Code Implementing My-D-Requirement
Code inspection report incorporating My-D-Requirement
Test plan incorporating My-D-Requirement
Test plan inspection report incorporating My-D-Requirement
Test report incorporating My-D-Requirement
© 2010 John Wiley & Sons Ltd.
* key traces
** D- = detailed
24
Requirements Traceability Matrix
Module 1
Module 2
Module 3
Requirement
1783
1784
© 2010 John Wiley & Sons Ltd.
getInterest()
showAccount()
computeBal()
showAddress()
showName()
showName()
25
Tracing and Testing Functional
vs. Non-Functional Requirements
Inspect
Design Element
Design Element
Design component
Design Element
Design Element
Design Element
Relevant
components
Non-functional Requirement
Implementation
Implemented by
whole application
tested by
tests ...
System Test
26
© 2010 John Wiley & Sons Ltd.
Prioritizing Detailed Requirements
[essential] Every game character has
the same set of qualities.
[desirable] Each area has a set of
preferred qualities.
[optional] The player’s character shall
age with every encounter. The age rate
can be set at setup time. Its default is
one year per encounter.
27
© 2010 John Wiley & Sons Ltd.
Associating a
Requirement and its
tests: Input and
Expected Output
© 2010 John Wiley & Sons Ltd.
Test input for
Requirement NNN
Expected output
Harry
Harry
X
X
" " (blank)
"" (blank)
123456789012345
123456789012345
1234567890123456
123456789012345
.....
.....
28
Agile
Non-Agile
Unit Tests and In-Code Comments as Detailed
Requirements
Customers shall be able to enter the name of a DVD in the text box, up to 20
alphanumeric characters. The application shall check this, with punctuation
marks replaced by blanks, with the DVD inventory, and display accordingly
“Sorry, we don’t stock this DVD” or “Added to your list.”
public void testLookup() {
// “Gone With The Wind” should be present
dVDSearch.doSearch( “Gone With The Wind” );
…..
// “War and Peace” should be absent
dVDSearch.doSearch( “War and Peace” );
…..
29
© 2010 John Wiley & Sons Ltd.
Combining Agile and non-Agile Methods
/* Requirement 3.4.2: Customers shall be able to enter the name of a DVD in the text box, up to
20 alphanumeric characters. The application shall check this, with punctuation marks replaced
by blanks, with the DVD inventory, and display accordingly “Sorry, we don’t stock this DVD” or
“Added to your list.” */
public void testLookup() {
// “Gone With The Wind” should be present
dVDSearch.doSearch( “Gone With The Wind” );
…..
// “War and Peace” should be absent
dVDSearch.doSearch( “War and Peace” );
…..
30
© 2010 John Wiley & Sons Ltd.
The Agile
Programming
Cycle
0. Understand
high-level
requirements
1. Understand next
requirement
5. Refactor code –
to clean up etc.
As a pair*
4. Modify code base
to pass the test.
* (for many agile processes)
© 2010 John Wiley & Sons Ltd.
2. Refactor code
base to prepare for
the requirement – if
necessary
3. Write tests
validating the
requirement*
31
Example Spreadsheet for Tracking Requirements
Requirement
Priority
Not
Frac
number
Essential
Optional started
1
Desirable
Responsible
engineer
© 2010 John Wiley & Sons Ltd.
32
Example Spreadsheet for Tracking Requirements
Status
Requirement
Priority
Not
Fraction com pleteReady for
number
Essential
Optional started
1/3
2/3
Inspection
Desirable
Designed
Inspected
for
Integration
Unit
tested
tested
Responsible
engineer
© 2010 John Wiley & Sons Ltd.
33
Hyperlink from Java Source
to Corresponding D-Requirement Using javadoc
/**
<a href="RequAnal\#
EngagingForeignCharacter ">
Engagement Requirement 1
("Engaging a foreign character")
</a>
The purpose of this method is stated in SRS.
– not repeated with the source code.
© 2010 John Wiley & Sons Ltd.
34
Hyperlink from Java Source
to Corresponding D-Requirement Using javadoc
/**
<a href="RequAnal\# EngagingForeignCharacter ">
Engagement Requirement 1
("Engaging a foreign character")
</a>
. . . . Implementation comments . . . .
*/
public engageForeignCharacter( … )
{
.....
}
© 2010 John Wiley & Sons Ltd.
35
Status after
initial draft
Result of updating after
high-level requirements
Result of updating after
detailed requirements
Updating the Project on Completing Detailed Requirements
Milestones
Risks
Schedule
Personnel
Cost
Estimation
© 2010 John Wiley & Sons Ltd.
Initial
More detailed
More detailed
Identify
Retire risks identified
previously; seek more
risks
Retire risks identified;
identify more risks
Very high level
Preliminary project
schedule
More detailed: shows
class & method
development tasking
Designate Crequirements
engineers
Engineers designated
for D-requirements
analysis
Designate software
architects
First estimates based
on job content
Improved estimate
using more specific
function points and/or
past experience with
similar requirements36
Crude estimates
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
Postmortem Results
Productivity
(= Time/quantity)
15/14.8 = 1.01
pgs/hr // 0.95
Self-assessed
quality (1-10)
9
5
Defect rate
Process
improvement
9
2
1.3 per page
// 1.01 per page
Spend ~20%
less time
preparing
© 2010 John Wiley & Sons Ltd.
Spread
interview time
more evenly
among people
Material should
be checked more
thoroughly prior
to inspection.
Spend ±30% more time
reviewing
37
Encounter Courtyard
Image (including game
characters)
kitchen
Note: Each part of
this figure is
specified separately
in section 3.
COURTYARD
living
room
dressing
room
User Interface for Status
Elena
Current life
OK
points: 56.38
Get status
Graphics
reproduced
with
permission
from Corel.
Set qualities
End game
© 2010 John Wiley & Sons Ltd.
Strength
Endurance
Endurance
Intelligence
Patience
Value
16.18
38
Encounter
kitchen
Courtyard
Image
COURTYARD
dressing
room
living
room
Get status
Set qualities
End game
© 2010 John Wiley & Sons Ltd.
39
Encounter Dressing Room Image
DRESSING
ROOM
courtyard
dungeon
Get status
Set qualities
End game
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
© 2010 John Wiley & Sons Ltd.
40
Encounter Dungeon Image
DUNGEON
dressing
room
study
Get status
Set qualities
End game
© 2010 John Wiley & Sons Ltd.
41
Encounter
Kitchen
Image
KITCHEN
Get status
Courtyard
Set qualities
End game
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
© 2010 John Wiley & Sons Ltd.
42
LIVING ROOM
Encounter
Living Room
Image
courtyard
Get status
Set qualities
End game
© 2010 John Wiley & Sons Ltd.
study
43
Living
room
STUDY
dungeon
Encounter
Study
Image
Get status
Set qualities
End game
© 2010 John Wiley & Sons Ltd.
44
Encounter Area Configuration
(Desirable Requirement)
Kitchen
Courtyard
Living
room
Dungeon
Study
Dressing
room
Key:
© 2010 John Wiley & Sons Ltd.
=
connection
45
User Interface for Status
Elena
Current life
points: 56.68
Strength
Endurance
Endurance
Intelligence
Patience
© 2010 John Wiley & Sons Ltd.
Value
16.18
46
Graphics reproduced with permission from Corel.
Foreign Character Freddie’s
Image
47
© 2010 John Wiley & Sons Ltd.
Graphics reproduced with permission from Corel.
Player Character Image Options
Elena
Sean
Boris
48
Graphics reproduced with permission from Corel.
User Interface for Setting Quality Values
Shawn
Current life points: 100.0
Choose the quality you
wish to set
Choose the value of the
quality selected
16.3
image
49
© 2010 John Wiley & Sons Ltd.
Shawn
Choose the quality you
wish to set
Current life points: 100.0
Image
User Interface for
Setting Quality
Values
Choose the value of the
quality selected
16.3
Explanation
The values of the qualities not specifically chosen remain in the
same proportion to each other. Values less than 1.0 are counted as
zero. E.g.,
before: strength = 10.0, endurance = 60.0, intelligence = 30.0,
patience = 0.0
(current life points 10.0 + 60.0 + 30.0 + 0 = 100.0)
change: strength from 10.0 to 20.0
after:
strength = 20, endurance = 53.33, intelligence = 26.66
OK