Requirements Management with Use Cases Module 9: Requirements Across The Product Lifecycle Requirements Management with Use Cases Module 9: Requirements Across The Product Lifecycle

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved About This Course 1 - Best Practices of Software Engineering 2 - Introduction to RMUC 3 - Analyze the Problem 4 - Understand Stakeholder Needs 5 - Define the System 6 - Manage the Scope of the System 7 - Refine the System Definition 8 - Manage Changing Requirements 9 - Requirements Across the Product Lifecycle RMUC: Course Outline

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 3 Requirements Across the Product Lifecycle Problem Solution Space Problem Space Needs Features Software Requirements Test Procedures DesignUser Docs The Product To Be Built Traceability

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 4 Requirements Across the Product Lifecycle Requirements

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 5 Each Iteration Makes a Pass Through Requirements

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 6 Inception Iterations: Typical Requirements Results  Collect information to develop the business case:  A draft of a survey of the use-case model  An initial terminology  A few use-case flow of events (requirements capture)  Sketches of user interfaces  A prototype (optional)

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 7 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

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 8 Construction Iterations: Typical Requirement Results  Build the complete system. At this point, requirements should be relatively stable.  Change requests on use-case’s flow of events  Updated use-case flow of events  Emphasis on analysis&design, implementation and test

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 9 Transition Iterations: Typical Requirements Results  Normally, requirements should not change at this late stage of the project.  However, if decisions are made to add new features to the system, an iteration (and produced results) would be similar to a typical construction- phase iteration.

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 10 Iteration Assessment  Assess requirements capture results relative to the evaluation criteria established during iteration planning:  Functionality  Performance  Capacity  Quality measures  Consider external changes that have occurred during this iteration  Examples: changes to requirements, user needs, competitor’s plans  Determine what rework, if any, is required and assign it to the remaining iterations

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 11 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

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 12 Types of Reviews  Walkthrough  Inspection  Formal Review Less Formal More Formal IEEE, 1994

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 13 Reviewing 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

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 14 Reviewing 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

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 15 Reviewing Requirements: Inspection  Purpose  To get views from different parts of the organization  To become aware of each other’s views  To find errors and problems early Problems surfacing at the end may kill the project!  To decide whether the reviewed document should be Approved, approved with corrections, or rejected  Participants  Moderator  Recorder  Author  Inspectors

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 16 Who Should be Inspectors?  Users of the system  Members of departments using the new system  Representatives of all departments using new system  Not just those that are involved in this use case  Process owners  Managers of the users  Domain experts  Designers of the system

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 17 How to Organize an Inspection  Before the meeting - At least 1 week in advance  Invite Inspectors (Hint: < 8)  Distribute materials to review (Hint: < 50 pages)  Distribute instructions and questions  Have inspectors read materials and write comments  At the meeting  Moderator leads and keeps meeting focused Keep the meeting short and fast (Hint: < 2 hours)  Recorder records all issues  Inspectors look for and discuss errors Objective is to find problems - not to solve them Handle spelling/typographical errors outside the meeting

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 18 Results of an Inspection  Major Problems  Severe problem: a section has to be reworked  Use case can’t be approved: a new inspection is required  Minor Problems  Things that can be fixed  Approval of use case may be delegated to moderator  Recommendations  Give concrete, constructive suggestions for improvements  Avoid too general comments like “bad” or “unclear”  Do not focus only on the negative, note positives too

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 19 Review Questions For The Use-Case Model  Is the use-case model understandable?  By studying the use-case model, do you understand the system's functions and how they are related?  Have all functional requirements been met?  Does the use-case model contain any superfluous behavior?  Is the division of the model into use-case packages appropriate?  Is it worth the money to build the system?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 20 Review Questions For Actors  Have all the actors been identified?  Is each actor involved with at least one use case?  Is each actor really a role? Should any be merged or split?  Do two actors play the same role in relation to a use case?  Do the actors have intuitive and descriptive names? Can both users and customers understand the names?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 21 Review Questions For Use Cases  Name and brief description  Is it clear which actor wishes to do the use case?  Is the purpose of the use case also clear?  Does the use case have a unique and intuitive name so that it cannot be mixed up with others?  Flows of events  Are the flows (basic and alternative) accurate?  Is it clear how and when each flow of events starts and ends?  Are actor interactions and exchanged information clear?  Does the communication sequence between actor and use-case conform to the user's expectations?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 22 Review Questions For Use Cases (Continued)  Does the use case deliver a result of value?  Do you understand how the result of value is achieved?  Is this a good way to do it?  Is there a better way to do it?  Is anything missing?  Is the use case overly complex?  Is the use case independent of the others?  Do any use cases have very similar behaviors or flows of events?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 23 Exercise: Review the Use-Case Model  Review the current state of the use-case model of one of the groups in the class  What type of review would be appropriate at this point in time?

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 24 Review: Requirements Across the Product Lifecycle 1. What is the typical state of a use-case model at end of  The Inception phase?  The Elaboration phase?  The Construction phase?  The Transition phase? 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?

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

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 26 Requirements Drive Design and Implementation Analysis and Design Add detail and design decisions Developer’s Perspective Use Cases Develop model of requirements User’s Perspective

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 27 The system displays a list of transaction offerings. The system retrieves and displays a list of current transaction offerings from the ATM database. Analysis/Design Adds Information To Use Cases

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 28 Bank ConsortiumWithdraw CashBank Customer > Card Reader > Bank Interface Analysis/Design Defines Classes

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 29 Use-Case RealizationUse Case Sequence Diagrams Collaboration Diagrams Analysis/Design Defines Interactions Among Classes For each use-case flow of events, show interactions in interaction diagrams UC7: UC Collaboration Diagram

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 30 Example: Withdraw Cash UC Sequence Diagram

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 31 Example: Withdraw Cash UC Collaboration Diagram

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 32 Requirements Drive Test Test Add detail and test case decisions Tester’s Perspective Use Cases Develop model of requirements User’s Perspective

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 33 Scenario 1: Normal Flow  Insert card  Read card  Enter PIN  Select transaction type  Enter account  Enter withdraw amount  Check cash in ATM  Ask bank for authorization  Give money and receipt  Take money, receipt, and card Bank Customer Withdraw

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 34 Use Case: Cash Withdrawal Test Type - Business Function Test Cases For Scenario 1 Test Parameters

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 35 Withdraw Bank Customer Scenario 2: Alternative Flow Insufficient Cash in ATM  Insert card  Read card  Enter PIN  Select transaction type  Enter account  Enter withdraw amount  Verify cash amount in ATM  Warning message given  Press cancel  ATM returns to select transaction type prompt

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 36 Use Case: Cash Withdrawal Test Type - Business Function Test Cases For Scenario 2: Alternative Flow UC 6: Withdraw Cash Tests Cases TP8:Test Plan Template

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 37 RMUC: Summary  Build the right system right by following a process to define and manage requirements to meet the customer’s real needs  Effective problem analysis will help avoid the “Yes, but…”  Elicitation helps you understand your stakeholders’ needs  Use features and a use-case model to come to an agreement with the customer on the definition of the system  Increase your chances to deliver on time and on budget by managing scope throughout the lifecycle of the project  A use-case model of the software 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”

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 38 Applying RMUC Concepts: Handouts  Summary: Key Skills for Requirements Management  White Paper: Applying Requirements Management with Use Cases WP3 WP4

Requirements Management with Use Cases v2000 Copyright © 1998, 2000 Rational Software, all rights reserved 39 Why Are We Here? The GOAL is to deliver quality products on time and on budget which meet the customer’s real needs.