1. Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle

2. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 2 Objectives: Requirements Across the Lifecycle  Describe the state of a use-case model at the end of each phase of the lifecycle  Explain an iteration assessment  Identify the types of requirements reviews  Describe how requirements drive analysis and design  Describe how requirements drive test

3. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 3 Requirements Across the Product Lifecycle

4. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 4 Inception Iterations: Typical Requirements Results Collect information to develop the business case:  A draft of a survey of the use-case model  An initial vocabulary  A few use-case flows of events (requirements capture)  Sketches of user interfaces  A prototype (optional)  Approximately 10% of schedule time  Approximately <5% of person hours

5. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 5 L P ID U Elaboration Iterations: Typical Requirement Results Refine requirements to build/validate architecture  Update terminology  Capture most software requirements Use cases and supplementary specifications  Refine use cases developed in previous iterations  Decide on use-case view of the architecture  Approximately 30% of schedule time  Approximately 20% of person hours

6. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 6 Construction Iterations: Typical Requirement Results Build the complete system  Change requests on use-case’s flow of events  Updated use-case flow of events  Emphasis on analysis, design, implementation and test  Approximately 50% of schedule time  Approximately 65% of person hours

7. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 7 Transition Iterations: Typical Requirements Results  Requirements should not change  Similar to typical construction-phase iteration if new features are added  Approximately 10% of schedule time  Approximately 10% of person hours

8. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 8 Iteration Assessment  Apply evaluation criteria  Functionality  Performance  Capacity  Quality measures  Consider external changes  Examples: changes to requirements, user needs, competitor’s plans  Determine what rework, if any, is required  Assign rework to remaining iterations

9. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 9 Reviewing Requirements  Informal reviews  To find errors  Whenever needed  Small team, possibly including QA  Formal reviews  To decide whether to proceed to next phase  At milestones and tollgates  Large reviewing team, including customers

10. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 10 Types of Reviews  Walkthrough  Inspection  Formal review Less Formal More Formal IEEE, 1994

11. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 11 Review Requirements: Walkthrough  Purpose  Find errors in an early stage  Find deviations from approved style, technique, standards  Informing  Participants  A few project members, need not be prepared  Procedure  Analyst gives an overview of the results  Analyst walks through reviewed chapters, other participants comment  Analyst makes notes on errors found

12. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 12 Review Requirements: Inspection  Purpose  To share views from different parts of the organization  To find errors and problems early  To make approval, revision, or rejection decisions  Participants  Moderator, recorder, author, and inspectors  Procedure  Organize before the meeting  Keep meeting focused (moderator)  Record all issues (recorder)  Look for and discuss errors (Inspectors)

13. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 13 Review Requirements: Formal Review  Purpose  To ensure that results are complete and consistent  To decide on continuation of project  Participants  Top management, project leaders, process owners, analysts  Procedure  Check status of documents (evaluation results)  Review outcome of the project  Authorize start of next phase

14. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 14 How Do Requirements Drive Development? Verified by Realized byImplemented by Implementation ModelTest ModelDesign Model Use-Case Model

15. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 15 Requirements Drive Design and Implementation Analysis and Design Add detail and design decisions Developer Perspective Use Cases Develop model of requirements User Perspective

16. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 16 Use-Case Realization Use Case Sequence Diagrams Collaboration Diagrams Analysis/Design Defines Classes and Interactions  For each use-case flow of events, show interactions in interaction diagrams

17. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 17 Requirements Drive Test Test Add detail and test case decisions Tester Perspective Use Cases Develop model of requirements User Perspective

18. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 18 Scenario 1: Happy Day Flow  Customer logs on  Customer selects ‘Trade’  Customer selects account  Customer performs trade  Select ‘Market Buy Order’  Enter Asset Purchase Information  System sends Market Buy Order to Marketing Trading System and receives confirmation  Display Confirmation of Trade  Customer logs off Execute Trade Trading Customer

19. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 19 Scenario 2: Alternative Flow, Insufficient Cash  Customer logs on  Customer selects ‘Trade’  Customer selects account  Customer performs trade  Select ‘Market Buy Order’  Enter Asset Purchase Information  System determines not enough cash in account  Notify customer that account has insufficient funds  Customer logs off TP8:Test Plan Template Execute Trade Trading Customer

20. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 20 Review: Requirements Across the Product Lifecycle 1.What is the typical state of a use-case model at the end of each phase of the lifecycle? 2.Under what circumstances would you change anything in the use-case model during the transition phase? 3.What is the purpose and contents of an iteration assessment? 4.What are the different types of reviews? When might each be used? 5.How do requirements drive design? 6.How do requirements drive test?

21. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 21 Summary (1 of 2)  Build the right system right by using a process to define and manage requirements to meet the customer’s needs  Effective problem analysis helps avoid the “Yes, but…”  Elicitation helps you understand your stakeholders’ needs  Use features and a use-case model to gain agreement with the customer on the definition of the system

22. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 22 Summary (2 of 2)  Increase your chances to deliver on time and on budget by managing scope throughout the lifecycle of the project  A use-case model of requirements helps refine the system definition to drive design, test, and user documentation  Requirement attributes and traceability help you manage change and avoid “scope creep”

23. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 23 Applying RMUC Concepts: Handouts  Summary: Key Skills for Requirements Management  White Paper: Applying Requirements Management with Use Cases WP4 WP5