Software Engineering: Requirements Analysis for CS 3300 Students, Exams of Software Engineering

Download Software Engineering: Requirements Analysis for CS 3300 Students and more Exams Software Engineering in PDF only on Docsity! 1 REQUIREMENTS ANALYSIS (Developer Perspective) GA Tech CS 3300 AY 2002 Fall 2001 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. 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.... Testability Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
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 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. Ambiguity Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 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 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. END REQUIREMENTS Incomplete: specify how to “display” a video! Completeness: 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). 2 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. … More Complete 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. Write a Detailed Requirement 1 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. Write a Detailed Requirement 2 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 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. 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 Functional requirements Other non-functional requirements Inverse requirements can be stated here Interface 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 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. Specific requirements (OO)3. Specific requirements (non-OO) IEEE 830-1994 Specific (“D-”) Requirements 5 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. 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. 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. 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. :Encounter- Game 1*. «create» Sequence Diagram for Initialize Use Case 1. «create» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. main player character: Player Character dressing room: Area 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. 6 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. * Test report incorporating My-D-Requirement My-D-Requirement Test plan incorporating My-D-Requirement Design segment incorporating My-D-Requirement Requirement inspection report incorporating My-D-Requirement Test plan inspection report incorporating My-D-Requirement Design inspection report incorporating My-D-Requirement Code inspection report incorporating My-D-Requirement *key traces Code Implementing My-D-Requirement Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Tracing a D-Requirement Design ElementDesign Element Design ElementDesign Element Tracing and Testing of Functional D-Requirements Functional Requirement 278 Unit Test 2694 + Design validated by Design Element ABCD trace Implementation Design Element Design ElementDesign 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. Module 1 Module 2 Module 3 Require- ment 1783 showName() computeBal() getInterest() 1784 showAccount() showAddress() showName() Table 4.1 Requirements Traceability Matrix Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Test input for Requirement NNN Expected output Harry Harry X X " " (blank) "" (blank) 123456789012345 123456789012345 1234567890123456 123456789012345 . . . . . . . . . . Table 4.2 Test Input and Expected Output Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Design Element System Test Design Element Design ElementDesign ElementDesign 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 Requirement Unit 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. 7 Prioritizing D-requirements [essential] Every game character has the same set of qualities. [desirable] Each area has a set of preferred qualities. [optional] The player’s character shall age with every encounter. The age rate can be set at setup time. Its default is one year per encounter. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Example Spreadsheet for Tracking Requirements Status Requirement Priority Not Fraction complet Ready for Designed Integration number Essential Optional started 1/3 2/3 Inspection for Unit tested Desirable Inspected tested Responsible engineer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Require- ment Trace- able back- ward Compl ete Con- sisten t Feasi ble Non- am- biguou s Clear Precis e Modifi- able Test- able Tracea ble forward Note 14 Area Require- ment 1 Note 2 Note 1 Yes Yes No 1 Yes No 1 No 2 No 1, 2 Yes Area Require- ment 2 Yes Yes Yes Yes No 3 Yes No 3 Note 3 Yes Yes Area Requir e-ment 6 Yes Note 5 Not e 5 Yes No 3 No 3 No 5 Yes Yes Yes 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. 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.