requirements analysis ii. plan project integrate & test system analyze requirements design...

REQUIREMENTSANALYSIS II

Plan project

Integrate & test system

Analyze requirements

Design

Maintain

Test unitsImplement

Software Engineering Roadmap:

Chapter 4 Focus

Identify corporate practices

Obtain C-Requirements(previous chapter)

Obtain D-requirements

- unambiguous- traceable- atomic- testable- consistent- complete

Select manner of organizing

D-requirements

Distinguish types ofD-requirements

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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


Introduction to D-requirements

RoadMap for Detailed (“D-”) Requirements

1. Select organization for D-requirements -- section 5

3a. Obtain D-requirements from C-requirements & customer

3b. Outline test plans -- chapter 8

4. Validate with customer

5. Release

when unit approved by customer ...

Apply customer feedback

In parallel

...

3c. Inspect -- section 6.3

2. Create sequence diagrams from use cases -- section 4


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


2.4 Interface requirementshow 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 requirementswhat the application does not do (the system will not animate the Encounter characters)

Types of Requirements

2/2


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

3.3. Performance requirements 3.4. Design constraints 3.5. Software system attributes 3.6. Other requirements

Functional requirements

Other non-functional requirements

Inverse requirements can be stated here

Interface requirements

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

Characteristics of D-Requirements

• Traceable

• Testable – measurable, quantified

• Unambiguous - formal

• Atomic – concise

• Complete

• Consistent

• Priority

Design ElementDesign ElementDesign ElementDesign Element

Tracing and Testing of Functional D-Requirements

Functional Requirement 278 Unit Test 2694 +

Design

validated by

Design Element ABCD

trace

Implementation

Design ElementDesign ElementDesign Element

Code Element EFGH

implemented by

RequirementsAnalysis

Testing

applies to ...

trace


Design Element

System Test

Design ElementDesign ElementDesign ElementDesign Element

tested by

Implemented bywhole application

try to isolaterelevant components

Non-functional Requirement

tests ...

Tracing and TestingFunctional vs Non-Functional Requirements

Functional Requirement Unit Test +

Design Element

Requirementsphase

Testphase

tested by

Inspect

Implementation

assignment

Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

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

. . . .

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 www.tbd at the time of the display....

Testability


http://www.nnnn/

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.

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


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

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.


Means no omissions which compromise

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:

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

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

WHAT IS WRONG HERE?


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?

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.

Requirements With Error Conditions

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


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


Exercise: D-Req for MacDonald’s Restauruant

1. Must accommodate 50 customers

2. Must have a drive-thru

3. Must provide green waste disposal facilities

4. Must meet all local building codes

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

Ways of Organizing Detailed Requirements

… Feature or mode

… Use case (preferred)

… Class

… Function hierarchy

… State

By:

Graphics reproduced with permission from Corel.

Think - traceability

3.1 External interfaces3.2 Functions3.3 Performance requirements3.4 Logical database requirements3.5 Design constraints 3.5.1 Standards compliance3.6 Software system attributes 3.6.1 Reliability 3.6.2 Availability 3.6.3 Security 3.6.4 Maintainability 3.6.5 Portability3.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 interfaces3.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 requirements3.4 Design constraints3.5 Software system attributes3.6 Other requirements

3. Specific requirements (OO)3. Specific requirements (non-OO)

IEEE 830-1994

Specific (“D-”) Requirements

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

Organizing Requirements by Use-case: Video Store Example

clerk

1. User swipes bar code

2. System displays due data3. ...

Check in

Check out1. . . . .

2.

Activate1. User hits any key

2. System displays main menu

buyer

Add video1. User gets “stock” screen

2. User enters name of video

3. . . . . . . . . . . . .


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 possibleWhen complete:

6. ReleaseAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Sequence diagrams

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


Build a Sequence Diagram 2

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


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.


Beginning of Sequence Diagram for Initialize Use Case

dressing room:

Area

1. create

:Encounter-Game

time

Beginning of Sequence Diagram for Initialize Use Case

create

main playercharacter:

Player Character

dressing room:

Area

1. create

note 1

note 4

:Encounter-Game

note 3note 2

time


User

:Encounter-Game

main playercharacter:

Player Character1*.1 create

5. move

Sequence Diagram for Initialize Use Case

* Numbering keyed to use case

1. create

2. create

3b. set quality values

:Player qualitywindow

dressing room:

Area

4. select exit for character

3a. set quality values


:Encounter-game

Sequence Diagram Showing Concurrency

freddie:ForeignCharacter

move

mainPlayer-Character:

PlayerCharacter

create & display

move

create & display

Player


(Concurrent player movement)

User:ConnectionHyperlink

Sequence Diagram forTravel to Adjacent Area Use Case

1.1 hit

1.2 display other area

:AreaConnection

:Area

2.1 display

2.2 display

:PlayerCharacter


Sequence Diagram for Engage Foreign Character Use Case

2. execute

anEngagement: Engagement

Encountergame

freddie: Foreign

Character

1.1 create; display

1.2 create


1.1 create; display

Sequence Diagram for Engage Foreign Character Use Case

2.1 execute

3.1 Display result

3.2 create

:EngagementDisplay

:Engagement

2.2 change quality values

1.2 create

:Player Character

:EncounterGame

freddie: Foreign

Character


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.


Candidate Classes for Encounter Game

Area

Encounter

Player ForeignCharacter

EncounterCharacter

PlayerWindow

Game

GameCharacter

QualityRoom

Door

Exit

Rule

Engagement

Result

Combat

Score

ExitChoiceWindowMap

(1) list every reasonable candidate class you can think of (this list), then

(2) drastically cut down to a few essential classes.

Passageway

EncounterAreaConnection

EngagementDisplay

ConnectionHyperlinkAdapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Shaded: retain from sequence diagrams

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



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


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



Classes for Encounter Video Game

Key: A class :Class with 1 object

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


Classes for Encounter Video Game, Showing Only Inheritance Relationships

Area

EncounterGame«singleton»Engagement

PlayerCharacter«singleton»

ForeignCharacter

EncounterCharacter

PlayerQualityWindow«singleton»

Key: A class :Class with 1 object

EngagementDisplay

(1) list every reasonable candidate class you can think of then (2) drasti-cally cut down to a few essential classes (this list).

EncounterAreaConnection

ConnectionHyperlink


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

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

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

Quality and Requirements

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.

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.

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.

requirements analysis ii. plan project integrate & test system analyze requirements design...

Documents

d requirements crequirements

requirements design

performance requirements

requirements analysis

nonfunctional requirements

specific requirements

inverse requirements

detailed d requirements