4 REQUIREMENTS ANALYSIS II

1
4REQUIREMENTSANALYSIS II
2
Software Engineering Roadmap Chapter 4 Focus
Obtain C-Requirements (previous chapter)
Obtain D-requirements - unambiguous -
traceable - atomic - testable - consistent -
complete
Select manner of organizing D-requirements
Identify corporate practices
Distinguish types of D-requirements
Plan project
Analyze requirements
Maintain
Integrate test system
Design
Test units
Implement
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
3
Chapter Learning Goals

• Be equipped with options
  for organizing D-requirements
• by class
• by use case
• by feature
• by event ...
• Be able to complete requirements
• be detailed enough to enable all design and
  complete implementation
• be able to express the non-functional
  requirements e.g., performance

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
4
1. Introduction to "specific" (or "D-")
requirements
5
RoadMap for Detailed (D-) Requirements
1. Select organization of D-requirements -- see
section tbd
2a. Obtain D-requirements from C-requirements
customer
In parallel ...
2b. Outline test plans -- see section tbd
2c. Inspect -- see section tbd
. . . .
6
RoadMap for Detailed (D-) Requirements
1. Select organization for D-requirements --
section 5
2. Create sequence diagrams from use cases --
section 4
3a. Obtain D-requirements from C-requirements
customer
In parallel ...
Apply customer feedback
3b. Outline test plans -- chapter eight
3c. Inspect -- section 6.3
4. Validate with customer
when unit approved by customer ...
5. Release-- see section tbd
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
7
Types of Requirements 1/2

• 1. Functional requirements
• the application's functionality
• 2. Non-functional requirements
• 2.1 Performance
• speed
• capacity (traffic rates)
• memory usage
• RAM
• disk
• 2.2 Reliability and availability
• 2.3 Error handling

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
8
Types of Requirements 2/2

• 2.4 Interface requirements
• how the application interacts with the user, and
  with other applications
• 2.5 Constraints
• accuracy
• tool and language constraints
• e.g. FORTRAN 88 must be used
• design constraints
• standards to be used
• hardware platforms to be used
• 3. Inverse requirements
• what the application does not do

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
9
The IEEE 830-1994 SRS Organization Specific
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 --
Interface requirements
Functional requirements
10
The IEEE 830-1994 SRS Organization Specific
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
Inverse requirements can be stated here
Other non-functional requirements
11
3. Desired properties of D-requirements
12
Tracing a D-Requirement
My-D-Requirement
Requirement inspection report incorporating
My-D-Requirement
Design segment incorporating My-D-Requirement
Design inspection report incorporating
My-D-Requirement
. . . .
13
Tracing a D-Requirement
My-D-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
key traces
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
14
Table 4.1 Requirements Traceability Matrix 
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
15
Tracing and Testing of Functional D-Requirements
Testing
Requirements Analysis
Functional Requirement 278
Unit Test 2694
validated by
trace
implemented by
applies to ...
Design
Implementation
Design Element
Design Element
Design Element
Design Element ABCD
Code Element EFGH
trace
Design Element
Design Element
Design Element
Design Element
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
16
Tracing and TestingFunctional vs Non-Functional
Requirements
Test phase
Requirements phase
tested by
Functional Requirement
Unit Test
Inspect
assignment
Implementation
Design Element
Design Element
Design Element
Design Element
Design Element
Design Element
Implemented by whole application
try to isolate relevant components
tests ...
System Test
Non-functional Requirement
tested by
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
17
Testability
The system shall display the difference in salary
between the client and the world wide average for
the same trade ? -- can't be tested because the
average mentioned cannot be determined (event
though it exists).
. . . .
18
Testability
The system shall display the difference in salary
between the client and the world wide average for
the same trade ? -- can't be tested because the
average mentioned cannot be determined (event
though it exists). ?Better The system shall
display the difference in salary between the
client and the estimated world-wide average for
the same trade as published by the United Nations
on its website www.tbd at the time of the
display....
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
19
Ambiguity

The player can decide the qualities of Encounter
characters. ? At any time?  Probably not. Would
have to test under all circumstances, many not
intended, incurring unnecessary expense, and
producing a wrong result.
. . . .
20
Ambiguity
The player can decide the qualities of Encounter
characters. ? At any time?  Probably not. Would
have to test under all circumstances, many not
intended, incurring unnecessary expense, and
producing a wrong result.
?Better version Whenever all foreign players are
absent from the area containing the player's main
character, the player may change the quality
values of this character, keeping the sum total
of the quality values unchanged. The
PlayerQualityWindow, (see section tbd) is used
for this purpose. Changes take effect four
seconds after the OK button is pressed.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
21
Prioritizing D-requirements
essential Every game character has the same set
of qualities. desirable optional
1. Essential?
3. Otherwise
2. Optional?
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
22
Prioritizing D-requirements
essential Every game character has the same set
of qualities. desirable Each area has a set of
preferred qualities.  optional The players
character shall age with every encounter. The age
rate can be set at setup time. Its default is one
year per encounter.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
23
Completeness
No omissions which compromise the stated
requirements. 1. The application shall display a
video in stock when a title is entered at the
prompt, or OUT when not in stock 2. The
application shall display all of the stores
videos by any director whose last name is entered
at the prompt. 2.1 Sequencing shall controlled
by the forward arrow key.
24
Completeness
No omissions which compromise the stated
requirements. BEGIN REQUIREMENTS 1. The
application shall display a video in stock when a
title is entered at the prompt, or OUT when not
in stock 2. The application shall display all of
the stores videos by any director whose last
name is entered at the prompt. 2.1 Sequencing
shall be controlled by the forward arrow key. 3.
The application shall display all of the stores
videos by any actor whose last name is entered at
the prompt. 3.1 Sequencing shall be controlled
by the forward arrow key.
END REQUIREMENTS Incomplete
specify how to display a video!
25
Requirement Without Necessary Errors (Myers)
A function that tells whether three numbers
produce an equilateral triangle (whose sides are
all equal), an isosceles triangle (containing
exactly two equal sides) or a scalene triangle (a
triangle which is neither equilateral nor
isosceles).
26
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.

27
Consistency
No contradictions among requirements.
Requirement 14. Only basic food staples shall be
carried by game characters . . . . .
. Requirement 223. Every game character shall
carry water. . . . . . . Requirement 497. Flour,
butter, milk and salt shall be considered the
only basic food staples.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
28
Write a Detailed Requirement 1
One way to ...

• 1. Classify requirement as functional or
  non-functional
• IEEE SRS prompts for most non-functional
• select method for organizing functional
  requirements
• 2. Size carefully
• a functional requirement corresponds to a
  method
• too large hard to manage
• too small not worth tracking separately
• 3. Make trace-able if possible
• ensure suitable for tracking through design and
  implementation
• 4. Make testable
• sketch a specific test that establishes
  satisfaction

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
29
Write a Detailed Requirement 2
One way to ...

• 5. Make sure not ambiguous
• ensure hard to misunderstand intention
• 6. Give the requirement a priority
• e.g., highest (essential) lowest (optional)
  neither (desirable)
• 7. Check that requirement set complete
• for each requirement, ensure all other necessary
  accompanying requirements are also present
• 8. Include error conditions
• state whats specifically required for
  non-nominal situations
• include programmer errors for critical places
• 9. Check for consistency
• ensure that each requirement does not contradict
  any aspect of any other requirement

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
30
4. Sequence diagrams
31
Beginning of Sequence Diagram for Initialize Use
Case
dressing room Area
Encounter- Game
1. create
time
32
Beginning of Sequence Diagram for Initialize Use
Case
note 1
main player character Player Character
dressing room Area
Encounter- Game
note 2
note 4
note 3
1. create
time
create
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
33
Sequence Diagram Showing Concurrency
Encounter- game
freddie ForeignCharacter
mainPlayer- Character PlayerCharacter
Player
create display
move
create display
move
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
34
Sequence Diagram for Initialize Use Case
main player character Player Character
Player quality window
dressing room Area
Encounter- Game
1.1 create
1. create
User
2. create
3a. set quality values
3b. set quality values
4. select exit for character
5. move
Numbering keyed to use case
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
35
Build a Sequence Diagram 1
One way to ...

• 1. Identify the use case whose sequence diagram
  you will build
• 2. Identify which entity initiates the use case
• the user, or
• an object of a class
• name the class
• name the object
• 3. Draw a rectangle to represent
  this object at left top
• use UML objectClass notation
• 4. Draw an elongated rectangle beneath this
  to represent the execution of an
  operation
• 5. Draw an arrow pointing right from its top

myObject MyClass
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
36
Build a Sequence Diagram 2
One way to ...

• 6. Identify which entity handles the operation
  initiated
• an object of a class
• name the class
• name the object
• 7. Label the arrow with the name of the operation
• dont show return
• 8. Show a process beginning, using an elongated
  rectangle
• 9 Continue with each new statement of the use
  case.

MyObject MyClass
MyObject1 MyClass1
My operation
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
37
5. Organizing D-requirements
38
Ways of Organizing Detailed Requirements

• Feature
• Use case
• Class
• Function hierarchy
• State

by ...
Graphics reproduced with permission from Corel.
39
3. Specific requirements (non-OO)
3.1 External interfaces 3.2 Functions 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.7.8
Additional comments -- or
IEEE 830-1994 Specific (D-) Requirements
40
3. Specific requirements (non-OO)
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
(direct or inherited)
3.2.1.1.1 Attribute 1 . . . . . .
. 3.2.1.2 Functions (services,
methods, direct or inherited)
3.2.1.2.1 Functional requirement .
. . . . . . . . . . . . . 3.3 Performance
requirements 3.4 Design constraints 3.5 Software
system attributes 3.6 Other requirements
3.1 External interfaces 3.2 Functions 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.7.8
Additional comments -- or
IEEE 830-1994 Specific (D-) Requirements
41
Organizing Requirements by Use-case Video Store
Example
1. User hits any key 2. System displays main menu
Activate
1. User swipes bar code 2. System displays due
data 3. ...
Check in
clerk
1. . . . . 2.
Check out
1. User gets stock screen 2. User enters name
of video 3. . . .
Add video
. . . . . . . . .
buyer
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
42
Use Case Generalizations Extensions
A. System displays main options B. User selects
icon
Warehouse
Perform warehouse transaction
Warehouse worker
extends
Plan route
Modify Stock
A. System displays main options 1. User moves
cursor to stock icon B. User selects
icon 2. System displays stock window
Dispatcher
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
43
RoadMap for Detailed (D-) Requirements using
the OO style
1. Obtain domain classes objects from sequence
diagrams
2. Add additional essential domain classes -- see
section tbd Inspect the resulting
collection of classes
. . .
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
44
RoadMap for Detailed (D-) Requirements using
the OO style
1. Obtain domain classes objects from sequence
diagrams
2. Add additional essential domain classes -- see
section tbd Inspect the resulting
collection of classes
3 For each class,
specify the required attributes specify the
required functionality specify the specific
required objects specify how its objects react
to events draft test plans for each inspect the
results
4. Inspect against C-requirements
5. Verify with customer where possible
When complete
6. Release
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
45
Classes in Initialize Sequence Diagram

• EncounterGame
• - a class with a single object
• PlayerCharacter
• - with object mainPlayerCharacter
• Area
• - with object dressingRoom, and
• PlayerQualityWindow
• - a GUI class included to complete the use case.

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
46
Sequence Diagram for Initialize Use Case
main player character Player Character
dressing room Area
Encounter- Game
1. create
1. create
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
47
Sequence Diagram forTravel to Adjacent Area Use
Case
ConnectionHyperlink
AreaConnection
PlayerCharacter
User
Area
1.1 hit
1.2 display other area
2.1 display
2.2 display
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
48
Sequence Diagram for Engage Foreign Character Use
Case
freddie Foreign Character
anEngagement Engagement
Encounter game
1.1 create display
1.2 create
2. execute
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
49
Sequence Diagram for Engage Foreign Character Use
Case
Engagement Display
Engagement
Encounter Game
freddie Foreign Character
Player Character
1.1 create display
1.2 create
2.1 execute
2.2 change quality values
3.1 Display result
3.2 create
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
50
Candidate Classes for Encounter Game
(1) list every reasonable candidate class you can
think of (this list), then (2) drastically cut
down to a few essential classes.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
51
Candidate Classes for Encounter Game
EncounterCharacter
EncounterAreaConnection
Engagement
Passageway
EngagementDisplay
(1) list every reasonable candidate class you can
think of (this list), then (2) drastically cut
down to a few essential classes.
Area
Player
ForeignCharacter
GameCharacter
Exit
Combat
PlayerWindow
Encounter
ExitChoiceWindow
Result
Map
Game
Quality
Room
Rule
Door
Score
ConnectionHyperlink
Shaded retain from sequence diagrams
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
52
Filtering Candidate Domain Classes 1

• Encounter  Change to EncounterGame to make its
  purpose clearer
• Game Not a domain class -- too general
• GameCharacter too general to be within the
  domain
• Player PlayerCharacter is more specific to the
  domain, and should replace it
• ForeignCharacter OK
• act differently from the player character

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
53
Filtering Candidate Domain Classes 2

• Quality OMIT -- try to handle as simple
  attribute of GameCharacter
• Room OMIT -- not sure if we need this already
  have Area
• Door OMIT -- not sure well need it -- see Exit
• Exit Not sure if we need this leads to
  neighboring area -- try as simple attribute of
  Area -- OMIT for now
• Rule OMIT -- not sure well need it
• Area OK

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
54
Filtering Candidate Domain Classes 3

• Engagement OK
• Passageway Use EncounterAreaConnection
• Result OMIT -- vague
• Combat OMIT -- not sure well need it -- already
  have Engagement
• Score OMIT -- try as attribute of other classes
• PlayerQualityWindow needed for Initialize u. c.
• ExitChoiceWindow OMIT -- not needed
• Map OMIT -- not required yet
• EngagementDisplay OK -- needed by use case

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
55
Classes for Encounter Video Game
(1) list every reasonable candidate class you can
think of then (2) drastically cut down to a few
essential classes (this list) But retain classes
used in sequence diagrams.
A class
Class with 1 object
Key
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
56
Classes for Encounter Video Game, Showing Only
Inheritance Relationships
EncounterCharacter
EncounterAreaConnection
ConnectionHyperlink
PlayerCharacter singleton
ForeignCharacter
(1) list every reasonable candidate class you can
think of then (2) drasti-cally cut down to a few
essential classes (this list).
PlayerQualityWindow singleton
EncounterGame singleton
Engagement
EngagementDisplay
Area
A class
Class with 1 object
Key
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
57
Select Domain Classes for Classifying Requirements
One way to ...

• 1. Develop a comprehensive, non-overlapping
  collection of use cases.
• 2. Create a sequence diagram for every use case.
• take care in identifying the classes and objects
• 3. Gather the classes used in the sequence
  diagrams.
• 4. Determine essential additional domain classes.
• 5. Classify the detailed functional requirements
  by these classes.
• 5.1 list each attribute as a requirement
• 5.2 list each specific object of this class that
  must exist
• 5.3 list each function required of objects in
  this classification
• 5.4 list the events that all objects of the class
  must react to

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
58
 Table 4.2 Test Input and Expected Output
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
59
Table 4.3 Example of Inspection Results on
D-Requirements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
60
Example Spreadsheet for Tracking Requirements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
61
Example Spreadsheet for Tracking Requirements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
62
5. Organizing D-requirements
63
Hyperlink from Java Source to Corresponding
D-Requirement Using javadoc
/ lta href"RequAnal\ EngagingForeignCharacter
"gt Engagement Requirement 1 ("Engaging a
foreign character") lt/agt
The purpose of this method is stated in SRS. It
is not repeated in the source code.
. . .
64
Hyperlink from Java Source to Corresponding
D-Requirement Using javadoc
/ lta href"RequAnal\ EngagingForeignCharacter
"gt Engagement Requirement 1 ("Engaging a
foreign character") lt/agt . . . . Implementation
comments . . . . / public engageForeignCharacte
r( ) . . . . .
The purpose of this method is stated in SRS. The
purpose is not repeated with the source code.
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
65
For example, if t is the table
Example of Z-specifications
If t is the table .
-- then augmenting t with input (2, 4) yields
the table
-- and augmenting t with input (3, 6) yields the
following table.
Hayes et al
66
Z-specification for Augmenting a Table 1
Procedure name
function between integers
value of t after application
Augment
t, t N -gt N l?, r? N
The set of natural numbers (see Math
appendix)
Declaration of variables and types
? denotes input
Hayes et al
67
Z-specification for Augmenting a Table 2
Augment
t, t N -gt N l?, r? N
t t ? l? a r?
Effect of application
t augmented by mapping l? to r?
Hayes et al
68
Z-specification for Lookup ( see Hayes)
Name of an output
Lookup
t, t N -gt N l?, r! N
Hayes et al
69
Z-specification for Lookup
Domain of the function (i.e., the elements
upon which it operates)
Name of an output
is not an element of ...
Lookup
t, t N ? N l?, r! N
l? ? dom( t ) ? r! 0 ? t t
? l? ? dom( t ) ? r! t( l? ) ? t
t
and ...
The table t is unchanged
or ...
Hayes et al
70
Table 4.4 The Array A
71
Z-specification for Sorting Example
Partial function (see above)
Sort
t, t N N
Range of t
dom(t) dom(t) ? rng(t) rng(t) ? ?x, y ?
dom(t), x ? y ? t(x) ? t(y) ? ?x ? rng(t),
card t-1(x) card t-1(x)
72
Z-specification for Sorting Example
Partial function (see above)
Sort
t, t N N
Range of t
dom(t) dom(t) ? rng(t) rng(t) ? ?x, y ?
dom(t), x ? y ? t(x) ? t(y) ? ?x ? rng(t),
card t-1(x) card t-1(x)
implies
Set of elements mapped onto x by t
Number of elements in the set ...
73
Z-specification for Maximum
Maximum
t N -a N m!, n! N
74
Z-specification for Maximum
Maximum
t N -a N m!, n! N
n! ? dom(t) ? m! t(n!) ? ?i ? dom(t), t(n!) ?
t(i), and if t(n!) t(i) then n! ? i
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
75
Pre- and Post-condition Form for Maximum
Z-specification
Maximum
t N -a N m!, n! N
Precondition t is an array of length lg gt 0
n! ? dom(t) ? m! t(n!) ? ?i ? dom(t), t(i) ?
t(n!) ? i ? n!
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
76
Pre- and Post-condition Form for Maximum
Z-specification
Maximum
t N -a N m!, n! N
Precondition t is an array of length lg gt
0 Postcondition 0 lt n lt lg // n index of
max m tn // m is max value ti lt m
for i 0, , lg-1 if tj m then j gt n //
first
n! ? dom(t) ? m! t(n!) ? ?i ? dom(t), t(i) ?
t(n!) ? i ? n!
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
77
Table 4.5 Updating the Project on Completing
D-Requirements
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
78
Summary of This Chapter

• D-requirements for developers
• Goals clarity, traceability
• Good organization helps
• e.g., OO style
• Use formal methods sometimes
• Update SPMP as a result

Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
79
Foreign Character Freddies Image
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
80
Player Character Image Options
Elena
Sean
Boris
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 20001), with permission.
Graphics reproduced with permission from Corel.
81
User Interface for Setting Quality Values
Sean
Current life points 100.0
Choose the quality you wish to set
Choose the value of the quality selected
16.3
image
. . . . . .
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
82
User Interface for Setting Quality Values
Current life points 100.0
Sean
Image
Choose the quality you wish to set
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 0.5 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.0
100.0) change strength from 10.0 to 20.0 after
strength 20.0, endurance 53.3,
intelligence 26.7
OK
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
83
Case Study
84
Encounter CourtyardImage (including game
characters)
Note Each part of this figure is specified
separately in section 3.
kitchen
COURTYARD
living room
dressing room
Graphics reproduced with permission from Corel.
OK
Get status
Set qualities
End game
85
Encounter CourtyardImage
kitchen
kitchen
COURTYARD
living room
dressing room
Get status
Set qualities
End game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
86
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.
87
Encounter DungeonImage
DUNGEON
dressing room
study
Get status
Set qualities
End game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
88
Encounter KitchenImage
KITCHEN
Courtyard
Get status
Set qualities
End game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
89
Encounter Living RoomImage
LIVING ROOM
courtyard
Get status
study
Set qualities
End game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
90
Encounter StudyImage
Living room
STUDY
dungeon
Get status
Set qualities
End game
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
91
Encounter Area Configuration (Desirable
Requirement)
Kitchen
Dressing room
Courtyard
Living room
Dungeon
Study
Key
connection
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
92
User Interface for Status
Elena
Current life points 56.68
Strength Endurance Intelligence Patience
Value
16.18
Endurance
Adapted from Software Engineering An
Object-Oriented Perspective by Eric J. Braude
(Wiley 2001), with permission.
Graphics reproduced with permission from Corel.