1. Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC

2. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 2 Overview: Introduction to RMUC Problem Solution Space Problem Space Needs Features Software Requirements Test Procedures DesignUser Docs The Product To Be Built Traceability

3. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 3 Objectives: Introduction to RMUC  Define requirements management terms  Identify the factors that contribute to project success or failure  Explain how requirements management impacts project success  Determine the role of team members in requirements management

4. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 4 Definitions: Requirements and their Management Requirement - a condition or capability to which the system must conform “User requirements describe what the screen looks like as well as the report formats” (technical writer) “User requirements are technical requirements re-written so the users can understand them” (training vendor) “User requirements describe what the user must do” (process engineer) “User requirements try to explain to technical people the problems we have with the systems they give us” (user) “User requirements are what the users think they want, but we are the only ones who know what they really need” (web programmer)

5. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 5 Definitions: Requirements and their Management  Requirement: A condition or capability to which the system must conform  Requirements management: A systematic approach to:  Eliciting, organizing, and documenting the requirements  Establishing and maintaining agreement between customer/user and project team on the changing requirements

6. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 6 Developer’s Bill Of Rights You have the right to know what is needed, via clear requirements, with clear declarations of priority. You have the right to say how long each requirement will take you to implement, and to revise estimates given experience. You have the right to accept your responsibilities instead of having them assigned to you. You have the right to produce quality work at all times. You have the right to peace, fun, and productive and enjoyable work.

7. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 7 Customer’s Bill Of Rights You have the right to an overall plan, to know what can be accomplished, when, and at what cost. You have the right to see progress in a running system, proven to work by passing repeatable tests that you specify. You have the right to change your mind, to substitute functionality, and to change priorities. You have the right to be informed of schedule changes, in time to choose how to reduce scope to restore the original date. You can even cancel at any time and be left with a useful working system reflecting investment to date.

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

9. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 9 What Is a Quality Product? Grady, 1992 Components of FURPS+ Functionality Feature Set Capabilities Generality Security Usability Human Factors Aesthetics Consistency Documentation Reliability Frequency/Severity of Failure Recoverability Predictability Accuracy MTBF Performance Speed Efficiency Resource Usage Throughput Response Time Supportability Testability Extensibility Adaptability Maintainability Compatibility Configurability Serviceability Installability Localizability Robustness

10. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 10 On Time and On Budget? Time Resources

11. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 11 To Meet the Customer’s Real Needs?  Feature 1: The system...  Feature 2: The system...  Feature 3: The system...  Feature 4: The system...  Feature 5: The system...  Feature 6: The system…  Feature 7: The system...  Feature n: The system... How do we determine priority? What is in the baseline? How do we know what the needs are? Time Project Start Date Target Release Date

12. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 12 Agreement on What the System Should Do The Goal Surrogate Goal Requirements Verification Customer User Community Requirements System To Be Built Adapted from Al Davis

13. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 13 What Factors Contribute to Project Success? Standish Group, ‘99 (www.standishgroup.com) Project Success Factors  Only 26% of projects completed on time and on budget  24% (large companies)  32% (small companies)  46% of projects over-ran original estimates ($22 billion over)  28% of projects canceled before completion ($75 billion before cancel) However... 1) User Involvement 2) Executive Management Support 3) Clear Statement of of Business Objectives

14. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 14 The High Cost of Requirement Errors Relative Cost to Repair Errors: When introduced vs. when repaired 100 2.5 5 10 25.5 - 1 Requirements Time Design Coding Unit Test Acceptance Test Maintenance Stage “All together, the results show as much as a 200:1 cost ratio between finding errors in the requirements and maintenance stages of the software lifecycle.” Boehm 1988 Average cost ratio 14:1 Grady 1989 The 1-10-100 Rule

15. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 15 How Can Projects Succeed?  Problem analysis  Understand the problem  Gain stakeholder agreement  Requirements elicitation  Determine who will use the system (actors)  Elicit how the system will be used (use cases)  Requirements management  Specify requirements completely  Manage expectations, changes, and errors  Control scope creep  Enlist all team members

16. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 16 Requirements Discipline: Workflow Details

17. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 17 Roles and Artifacts

18. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 18  Developers, Testers, Writers  Help develop requirements management practices  Monitor adherence to practices  Verify elicitation process  Help document requirements  Participate in requirements reviews  Participate in or chair a CCB (Change Control Board)  Review traceability outcomes  Verify quality, testability, completeness Involve the Whole Team in Requirements

19. Requirements Management with Use Cases Copyright © 1998-2001 Rational Software, all rights reserved 19 Review: Introduction to RMUC 1.What is a requirement? 2.What is requirements management? 3.What factors contribute to project success? 4.What factors contribute to project failure? 5.What team members are involved in requirements management and how? 6.How would you explain the 1-10-100 rule?