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

3. Chapter Learning Goals
The process of D-reqts analysis
Types of D-req’ts (functional, other)
Properties of good requirements
Sequence Diagrams
Organizing D-req’ts
by Use-Case by Class
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Introduction to D-requirements

5. 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 8
3c. Inspect -- section 6.3
4. Validate with customer
when unit approved by customer ...
5. Release
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

6. Types of Requirements 1/2
1. Functional requirements
the application's functionality – services the application provides
2. Non-functional requirements
2.1 Performance
Speed (200 transcations / hour)
capacity (traffic rates)
memory usage (RAM, disk)
2.2 Reliability and availability
no more than 5 errors / 1000 transactions
2.3 Error handling
avoidance, recovery, and reporting
Types of Requirements 1/2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

7. Types of Requirements 2/2
2.4 Interface requirements
how the application interacts with the user, and with other applications
2.5 Constraints
accuracy (calc. to 3 decimal points.)
tool and language constraints
(SUN’s Java V1.0 must be used)
design constraints (a relational DB must be used)
standards to be used (shall conform to ISO 9211)
hardware platforms to be used
3. Inverse requirements
what the application does not do
(the system will not animate the Encounter characters)
Types of Requirements 2/2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

8. The IEEE 830-1994 SRS Organization: Specific Requirements with OO organization
3.1. External interface
requirements
User interfaces
Hardware interfaces
Software interfaces
Communications
interfaces
3.2. Classes/Objects
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

9. Difference Between C and D Requirements
C-Requirements
Use words understandable to client
There may be ambiguity, missing info
Often a clarification of the RFP
Should be numbered
Descriptions of use (use-cases)
D-Requirements
More formal technological terminology for designers
Details, consistent, testable … etc
Refinement of C req for the designers
Traceable through the project
More technical diagrams may be used

10. Characteristics of D-Requirements
Traceable
Testable – measurable, quantified
Unambiguous - formal
Atomic – concise
Complete
Consistent
Priority

11. Tracing and Testing of Functional D-Requirements
Analysis
Functional Requirement 278
validated by
Unit Test
trace
implemented by
applies to ...
Design
Implementation
Design Element
Design Element
Design Element
Design Element ABCD
trace
Code Element EFGH
Design Element
Design Element
Design Element
Design Element
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

12. Tracing and Testing Functional vs Non-Functional Requirements
phase
Requirements
phase
tested by
Functional Requirement
Unit Test +
Inspect
assignment
Implementation
Design Element
Design Element
Design Element
Design Element
Design Element
Implemented by
whole application
Design Element
try to isolate
relevant components
tests ...
Non-functional Requirement
tested by
System Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.

13. The system shall display the difference in salary between the client and the current world wide average for the same trade
 -- can't be tested because the average mentioned cannot be determined (even though it exists)
Testability

14. The system shall display the difference in salary between the client and the current world wide average for the same trade
 -- can't be tested because the average mentioned cannot be determined (even 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 at the time of the display....
Testability
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. Ambiguity
The player can decide the qualities of the Encounter role playing game characters.
 At any time?  Probably not. Would have to test under all circumstances, many not intended, incurring unnecessary expense, and producing a wrong result.

16. The player can decide the qualities of the Encounter role playing game characters.
 At any time?  Probably not. Would have to test under all circumstances, many not intended, incurring unnecessary expense, and producing a wrong result.
Ambiguity
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.

17. Prioritizing D-requirements
If schedule, budget and quality level are fixed then only capability can vary.
One approach is to prioritize numerically all requirements .. Usually overkill
Better approach is to categorize all requirements as either: essential (musts), desirable (wants), and optional (only if extra time/money) – TRIAGE METHOD
Priorities can change with each iteration as the system matures

18. Prioritizing D-requirements
TRIAGE APPROACH:
[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.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. What is wrong here? Means no omissions which compromise Completeness:
the stated requirements.
EXAMPLES OF BAD 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 store’s 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 store’s videos by any actor whose last name is entered at the prompt.
3.1 Sequencing shall be controlled by the forward arrow key.
What is wrong here?
Completeness:

20. Sometimes requirements can be in conflict Functional requirement:
Consistency
Sometimes requirements can be in conflict
Functional requirement:
The system must display the selected videos image, the full text description and the standard credit list of producer, director, actors, and play a portion of the musical score
Non-functional requirement:
The system must display each selected video within 2 seconds

21. No contradictions among requirements. Consistency
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.
WHAT IS WRONG HERE?
Consistency
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Requirements With Error Conditions (Myers)
The function must determine 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).
WHAT IS MISSING?

23. Requirements With Error Conditions
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.

24. Write a Detailed Requirement 1 of 2
One way to ...
Write a Detailed Requirement 1 of 2
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 traceable 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.

25. Write a Detailed Requirement 2 of 2
One way to ...
Write a Detailed Requirement 2 of 2
5. Make sure complete and 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 is complete
for each requirement, ensure all other necessary accompanying requirements are also present
8. Include error conditions
state what’s 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.

26. Exercise: D-Req for MacDonald’s Restauruant
Must accommodate 50 customers
Must have a drive-thru
Must provide green waste disposal facilities
Must meet all local building codes

27. Exercise: D-Req for MacDonald’s Restauruant
Must accommodate 50 customers
In which portions of building
How much free space in queue area
How many teller locations
Need to clarify number – eating, ordering
Must have a drive-thru
What is the expected through-put (demand, peek)
1 customer / 3 minutes
Must provide green waste disposal facilities
Must meet all local building codes

28. Organizing D-requirements
Unorganized requirements are difficult to manage:
Size makes it hard to comprehend
Functional and non-functional are mixed
Some requirements naturally should be grouped
Difficult to locate specific requirement or related set

29. Ways of Organizing Detailed Requirements
… Feature or mode
… Use case (preferred)
… Class
… Function hierarchy
… State
By:
Think - traceability
Graphics reproduced with permission from Corel.

30. 3. Specific requirements (non-OO) 3. Specific requirements (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
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
Attributes
(direct or inherited)
Attribute
Functions (services,
methods, direct or inherited)
Functional requirement
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements
IEEE
Specific (“D-”)
Requirements

31. Organizing Requirements by Use-case
UPEDU prefers the use case “scenario” approach
Catagories (classes) are indentified
Requirements are placed in classes
Advantages:
Ease of communication/identification through use cases
Promotes traceability
Disadvantages:
Classes must be selected early
Requirements analysis and design confused
Requirement correspondence can be later lost

32. 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 2.
Check out
1. User gets “stock” screen
2. User enters name of video
Add video
buyer
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

33. 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
RoadMap for Detailed (“D-”) Requirements using the OO style
When complete:
6. Release
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

34. Sequence diagrams

35. Build a Sequence Diagram 1
One way to ...
Build a Sequence Diagram 1
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 object:Class 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
don’t 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. 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.

38. Beginning of Sequence Diagram for Initialize Use Case
dressing
room:
Area
:Encounter-
Game
1. create
time

39. Beginning of Sequence Diagram for Initialize Use Case
note 1
main player
character:
Player Character
dressing
room:
Area
:Encounter-
Game
note 2
note 3
note 4
1. create
time
create
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

40. Sequence Diagram for Initialize Use Case
:Encounter-
Game
main player
character:
Player Character
:Player
quality
window
dressing
room:
Area
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.

41. Sequence Diagram Showing Concurrency
Player
:Encounter-game
mainPlayer-
Character:
PlayerCharacter
freddie:
ForeignCharacter
create & display
move
(Concurrent player movement)
create & display
move
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

42. Sequence Diagram for Travel 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.

43. Sequence Diagram for Engage Foreign Character Use Case
freddie:
Foreign
Character
Encounter
game
anEngagement
: Engagement
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.

44. Sequence Diagram for Engage Foreign Character Use Case
:Encounter
Game
freddie:
Foreign
Character
:Engagement
:Engagement
Display
: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.

45. 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.

46. 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.
Player
Area
ForeignCharacter
GameCharacter
Exit
Combat
PlayerWindow
Encounter
ExitChoiceWindow
Map
Result
Quality
Game
Room
Rule
Score
ConnectionHyperlink
Shaded: retain from
sequence diagrams
Door
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

47. 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.

48. 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 we’ll 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 we’ll need it
Area: OK
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

49. Filtering Candidate Domain Classes 3
Engagement: OK
Passageway: Use EncounterAreaConnection
Result: OMIT -- vague
Combat: OMIT -- not sure we’ll 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.

50. 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.
Key:
A class
:Class with 1 object
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. EncounterAreaConnection
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
Key:
A class
:Class with 1 object
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52. Select Domain Classes for Classifying Requirements
One way to ...
Select Domain Classes for Classifying Requirements
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.

53. Selecting the Right Class for a Requirement
Req: Every Encounter character shall have a name
Req: Whenever the player’s main character enters an area, that area and all the characters in it shall be displayed on the monitor
>>> EncounterCharacter
>>> Area

54. Requirements for Instances
Where should requirements for specific instances of a class be placed?
Where would be the best place to list of requirements for the “court yard” and “dressing room” objects?
Linking to Test Documentation
Start thinking about tests to verify requirements – be specific, this will force requirements to be measurable
Extreme programmiing demands the development of tests before develop of modules

55. Quality and Requirements

56. Quiz G4.2 What is wrong with the following D-requirements?
a.     HomeBudget shall display a convenient interface for entering personal data.
b.     SatControl shall compute the predicted time taken to circle the Earth on the current orbit, and the actual time taken to circle the Earth on the previous orbit
c.      InvestKing shall determine the best investment strategy. 

57. Quiz
a. Requirement a. is vague and not testable because the word “convenient” is not defined.
b. Requirement b is vague and not testable because “predicted time” is not defined. Any time would be a “predicted time,” however far off the mark.
c. Requirement c is not testable, because “best” is not defined. In theory, it signifies an absolute optimal strategy, which is unrealistic in practice.

58. Quiz IMPROVED VERSIONS:
a.     HomeBudget shall display an interface for entering personal data which satisfies the following criteria. 90% of the time, a random sample of users from the ABC Corporation rank the user interface at least 8 on a “convenience” scale of 1 to 10 after using it for one hour. A score of 1 is “the least convenient I have ever used”, and 10 is “the most convenient I have ever used.”
b.     SatControl shall predict time taken to circle the Earth on the current orbit in a manner that is within 10% of the actual time at least 90 times out of the first100 orbits measured.
c.      InvestKing shall determine an investment strategy that is superior to an XYZ mutual fund in at least 8 weeks out of 10 for every 10-week period in the past 5 years.