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

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 Create sequence diagrams from use cases -- section 4 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

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.

The IEEE SRS Organization: Specific Requirements with OO organization 3. Specific requirements 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 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 Element Tracing and Testing of Functional D-Requirements Functional Requirement 278Unit Test Design validated by Design Element ABCD trace Implementation Design Element Code Element EFGH implemented by Requirements Analysis Testing applies to... trace Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Design Element System Test Design Element tested by Implemented by whole application try to isolate relevant components Non-functional Requirement tests... Tracing and Testing Functional vs Non-Functional Requirements Functional RequirementUnit Test + Design Element Requirements phase Test phase 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 at the time of the display....www. Testability Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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

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

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

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

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.

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

Exercise: D-Req for MacDonald ’ s Restauruant 1.Must accommodate 50 customers 1.Need to ensure sufficent facilities for 50 people (seats, tables, bathrooms, parking, etc) 2.Need sufficient staff to server number of cust. 3.Confirm they are referring to sit-down customers 2.Must have a drive-thru 1.Expected capacity  number of lanes, windows 2.Require electronic menu / intercom systems 3.Safety issues? 3.Must provide green waste disposal facilities 1.Are the facailities in or outdoors? 2.Numbers will be driven by expected max capacity 3.Education of employees / directions for customers 4.Must meet all local building codes 1.Assume NS/Wofville – found it 2.Number of stories is needed 3.Need to understand special drive thru requirements

Exercise: D-Req for MacDonald ’ s Restauruant 1.Must accommodate 50 customers 1.In which portions of building 2.How much free space in queue area 3.How many teller locations 4.Need to clarify number – eating, ordering 2.Must have a drive-thru 1.What is the expected through-put (demand, peek) 2.1 customer / 3 minutes 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 interfaces 3.2 Functions 3.3 Performance requirements 3.4 Logical database requirements 3.5 Design constraints Standards compliance 3.6 Software system attributes Reliability Availability Security Maintainability Portability 3.7 Organizing the specific requ System mode -- or User class -- or Objects (see right) -- or Feature -- or Stimulus -- or Response -- or Functional hierarchy -- or Additional comments -- or 3.1 External interface requirements User interfaces Hardware interfaces Software interfaces Communications interfaces 3.2 Classes/Objects Class/Object Attributes (direct or inherited) Attribute Functions (services, methods, direct or inherited) Functional requirement Performance requirements 3.4 Design constraints 3.5 Software system attributes 3.6 Other requirements 3. Specific requirements (OO) 3. Specific requirements (non-OO) IEEE Specific ( “ D- ” ) Requirements

Organizing Requirements by Use-case USDP 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 data Check in Check out Activate 1. User hits any key 2. System displays main menu buyer Add video 1. User gets “ stock ” screen 2. User enters name of video Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

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

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

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.

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 player character: Player Character dressing room: Area 1. create note 1 note 4 :Encounter- Game note 3 note 2 time Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

User :Encounter- Game main player character: Player Character 1*.1 create 5. move Sequence Diagram for Initialize Use Case * Numbering keyed to use case 1. create 2. create 3b. set quality values :Player quality window dressing room: Area 4. select exit for character 3a. set quality values Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

User :Connection Hyperlink Sequence Diagram for Travel to Adjacent Area Use Case 1.1 hit 1.2 display other area :AreaConnection :Area 2.1 display 2.2 display :PlayerCharacter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Sequence Diagram for Engage Foreign Character Use Case 2. execute anEngagement : Engagement Encounter game freddie: Foreign Character 1.1 create; display 1.2 create Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1.1 create; display Sequence Diagram for Engage Foreign Character Use Case 2.1 execute 3.1 Display result 3.2 create :Engagement Display :Engagement 2.2 change quality values 1.2 create :Player Character :Encounter Game freddie: Foreign Character Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

Candidate Classes for Encounter Game Area Encounter PlayerForeignCharacter EncounterCharacter PlayerWindow Game GameCharacter Quality Room Door Exit Rule Engagement Result Combat Score ExitChoiceWindow Map (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 ConnectionHyperlink Adapted 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 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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.

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

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

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

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.

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

Status after initial draft Result of updating after C-requirements Result of updating after D-requirements Milestones InitialMore detailed Risks Identify Retire risks identified previously; seek more risks Retire risks identified; identify more risks Schedule Very high level Preliminary project schedule More detailed: shows class & method development tasking Personnel Designate C- requirements engineers Engineers designated for D-requirements analysis Designate software architects Cost Estimation Crude estimates First estimates based on job content Improved estimate based on more specific function points and/or past experience with similar individual requirements 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.

Summary of This Chapter D-requirements for developers Goals: clarity, traceability Good organization helps –e.g., OO style Update SPMP as a result Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.