Requirements Management with Use Cases Module 2: Introduction to RMUC

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

2. Traceability Test Procedures Design User Docs Overview: Introduction to RMUC Problem Space Problem Needs Solution Space Features The Product To Be Built Software Requirements

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. 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. 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. 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. 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. TheGOALis to deliver quality products on time and on budget which meet the customer’s real needs. Why Are We Here?

9. What Is a Quality Product? Components of FURPS+ F unctionality Feature Set Generality Capabilities Security U sability Human Factors Consistency Aesthetics Documentation R eliability Frequency/Severity Predictability of Failure Accuracy Recoverability MTBF P erformance Speed Throughput Efficiency Response Time Resource Usage S upportability Testability Configurability Extensibility Serviceability Adaptability Installability Maintainability Localizability Compatibility Robustness Grady, 1992

10. How Much Work Can We Do? On Time and On Budget? Resources Time

11. To Meet the Customer’s Real Needs? How do we know what the needs are? • 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? Time Project Start Date Target Release Date

12. Agreement on What the System Should Do The Goal Customer User Community System To Be Built RequirementsVerification Surrogate Goal Requirements Adapted from Al Davis

13. What Factors Contribute to Project Success? Project Success Factors 1) User Involvement 2) Executive Management Support 3) Clear Statement of of Business Objectives However... • 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) Standish Group, ‘99 (www.standishgroup.com)

14. The High Cost of Requirement Errors The 1-10-100 Rule “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.” Stage Requirements Time .5 - 1 2.5 Design 5 Coding 10 Unit Test 25 Acceptance Test 100 Maintenance Relative Cost to Repair Errors: When introduced vs. when repaired Average cost ratio 14:1Grady 1989 Boehm 1988

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 Discipline: Workflow Details

17. Roles and Artifacts

18. Involve the Whole Team in Requirements • 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

19. Review: Introduction to RMUC • What is a requirement? • What is requirements management? • What factors contribute to project success? • What factors contribute to project failure? • What team members are involved in requirements management and how? • How would you explain the 1-10-100 rule?