1 / 60

REQUIREMENTS ANALYSIS II

REQUIREMENTS ANALYSIS II. 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

lorrainee
Télécharger la présentation

REQUIREMENTS ANALYSIS II

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. REQUIREMENTSANALYSIS 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 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) 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. 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 Interface requirements Functional requirements Inverse requirements can be stated here Other non-functional requirements

  9. 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 Difference Between C and D Requirements

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

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

  12. Test phase Requirements phase Tracing and TestingFunctional vs Non-Functional Requirements 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 ... Non-functional Requirement System Test tested by Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

  13. 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) . . . .

  14. 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.... 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. 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. 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. 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:

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

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

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

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

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

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

  41. Sequence Diagram Showing Concurrency mainPlayer- Character: PlayerCharacter Player :Encounter-game 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 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.

  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 Passageway EngagementDisplay Engagement (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 Game Quality Room Rule Score ConnectionHyperlink Door Shaded: retain from sequence diagrams 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 ofthen (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.

More Related