Just Enough Requirements Management

1. Just EnoughRequirements ManagementPresented at:Requirements Engineering ‘06Minneapolis, MN13 September 2006 by Alan M. Davisadavis@uccs.eduhttp://web.uccs.edu/adavis College of BusinessUniversity of Colorado at Colorado Springs

2. Tutorial Goals • Improve Likelihood that Products Will Meet Customer Expectations • Improve Likelihood that Project Will Complete On Schedule and Within Budget Even with a Compressed Life Cycle • Understand What Aspects of Requirements Management You Cannot Afford to Do • Understand What Aspects of Requirements Management You Cannot Afford to Not Do • Desired Reaction from You: “Everything Here is Just Plain Common Sense” Just Enough Requirements Management

3. Outline • Introduction to Requirements Management • 1. Elicitation • 2. Triage • 3. Specification • 4. Requirements Change • Summary Within each:- definition- effects of over- and under-doing it- list of “just enough” “tricks”- expand a few- show result of activity Just Enough Requirements Management

4. Outline • Introduction to Requirements Management • 1. Elicitation • 2. Triage • 3. Specification • 4. Requirements Change • Summary Just Enough Requirements Management

5. Definitions • Requirement: An Externally-Observable Characteristic of a Desired System • Requirements Management: • Learning (elicitation), • Pruning (triage), and • Documentation (specification) of Requirements Just Enough Requirements Management

6. Facts (1 of 4) • Needs Are in Constant Flux • The More the Customer Sees, the More They Will Want • Therefore . . . We Must Find Ways to Be More Responsive/Agile Just Enough Requirements Management

7. Facts (2 of 4) • We Want Our Products to Be Successful • The Match Between • What the Product Does, and • the Customers’ Perception of What They Need Will Determine the Degree of Product Success • Therefore . . . We Must Address the Customers’ Needs (Not Our Perception of What They Need) Just Enough Requirements Management

8. Facts (3 of 4) • Customers Do Not Like Surprises • Customers Are More Committed When They Are Involved • Therefore . . . Customer Involvement and No Surprises Just Enough Requirements Management

9. Facts (4 of 4) • Many of Today’s “Modern” Requirements Management Techniques Are • Ponderous • Overburdened with Procedure • Therefore . . . We Need to Learn Simple Ways of Doing Requirements Management Successfully Just Enough Requirements Management

10. Summary of Fact Implications • We Must Find Ways to Be More Responsive/Agile • We Must Address the Customers’Needs (Not Our Perception of What They Need) • Customer Involvement and No Surprises • We Need to Learn Simple Ways of Doing Requirements Management Successfully Just Enough Requirements Management

11. So, Why “Just Enough”?(1 of 3) • CMM(I) proponents tend toward • Heavy process • More emphasis on measuring progress than making progress • Lots of control • “Heavy” documentation & strict standards adherence • Rigorous reviews (peer and customer) • Bad: Very slow development • Good: Low risk of building wrong system Just Enough Requirements Management

12. So, Why “Just Enough”?(2 of 3) • Agile proponents tend toward • Light process • No emphasis on measuring progress • No control • “No” documentation (recent introduction of stories) • No reviews (peer or customer) • Good: Very fast development • Bad: Works only w/one client, few changes Just Enough Requirements Management

13. So, Why “Just Enough”? (3 of 3) Where Are You?Where Should You Be? 0No ProcessNo StandardsNo DocumentationNo ReviewsNo RequirementsHigh Risk of Building Wrong SystemPotential Quick Development 10 Heavy ProcessStrict StandardsHeavy DocumentationRigorous ReviewsMethodicalLow Risk of Building Wrong System Potential Slow Development Just Enough Requirements Management

14. What Is “Just Enough” Requirements Management? • What is “just enough” life insurance? • Enough so you sleep well at night knowing that others will be “taken care of” if you die • Not so much that you stay awake at night worrying about the money you are paying for insurance • What is “just enough” RM? • Enough so you can keep your customers happy • Not so much that your project becomes late or over-budget x Just Enough Requirements Management

15. Why Three Kinds of Req’ts Management Activities? • Understand Needs (Elicitation) • The customers’ needs are the candidate requirements • Must be understood up front or disaster • Select Appropriate Subset (Triage) • Must balance requirements, schedules and expectations • Record Desired External Behavior (Specification) • To ensure that all developers have same goal • To ensure that developers and customers have same expectations (No surprises!) Just Enough Requirements Management

16. Cust Rep or Marketing DevelopmentFinance Cust Rep or Marketing:Prioritization Cust Rep or Marketing Cust Rep or Marketing BugReports UnsatisfiedFrom PreviousRelease Development:Estimation Development Baseline List ofCandidateRequirements List ofAnnotatedCandidateRequirements Product Development A “Just Enough” Requirements Process C u s t o m e r s & C o m p e t I t I o n T e c h n o l o g y Just Enough Requirements Management

17. How Much Time for Requirements? ref - Forsberg 1996 Just Enough Requirements Management

18. Outline • Introduction to Requirements Management • 1. Elicitation • Definitions • Role in Overall Requirements Process • Effects of “Too Much” or “Too Little” • Tips for “Just Enough” Elicitation • The Result of Elicitation • 2. Triage • 3. Specification • 4. Requirements Change • Summary Just Enough Requirements Management

19. Elicitation • The Art of Listening to Stakeholders • The Art of Sending Appropriate Stimuli to Stakeholders So That the Responses are Worth Listening To • The Art of Establishing an Environment in Which Stakeholders Are Willing and Able to Describe Their Problems and Needs Just Enough Requirements Management

20. Cust Rep or Marketing DevelopmentFinance Cust Rep or Marketing:Prioritization Cust Rep or Marketing Cust Rep or Marketing BugReports UnsatisfiedFrom PreviousRelease Development:Estimation Development Baseline List ofCandidateRequirements List ofAnnotatedCandidateRequirements Product Development Elicitation in theRequirements Process C u s t o m e r s & C o m p e t I t I o n T e c h n o l o g y Just Enough Requirements Management

21. Effects of “Too Much” or “Too Little” Elicitation • Too much • You would spend so much time understanding the problem that no time would be left to solve it • Too little • You would build system before understanding problem, and would likely build the wrong system x Just Enough Requirements Management

22. (Expanded on Next Few Slides) Tips for “JustEnough” Elicitation • Don’t lose sight of the goal • Care • Don’t ignore elicitation • Maintain glossary of terms • Recognize that 1 stakeholder cannot speak for all • Select appropriate notations • Prepare for change  • Who’s smart? • Use appropriate elicitation techniques • Prepare for triage • Use sensible starting point(s) x Just Enough Requirements Management

23. Who’s Smart? • Don’t Try to Convince Stakeholders the You Are Smart – Wrong Place to Do That! • Instead Take Every Opportunity to Show You Think the Stakeholder is Smart • Contrast These Two Cases My Elevators AreToo Slow! I See.Tell Me WhyYou Feel TheyAre Too Slow. I Don’t Think So.I Think You Have anElevator ThroughputProblem, not a Speed Problem Just Enough Requirements Management

24. Use Appropriate Elicitation Techniques • One elicitation technique is not “good enough” • Function of people involved • Function of requirements not yet understood • Function of application domain • Interviews • Same Place, Same Time; Few People, Analyst-Driven • Questionnaires • Different Time, Different Place, Many People • Group Sessions • Same or Different Place, Same Time, <20 People, Analyst-Facilitated • Observation • Same Time, Same Place, Analyst-Observer Just Enough Requirements Management

25. Prepare for Triage • This is an “attitude” • Elicitation’s purpose is to gather all candidate requirements • Make sure everybody knows that triage will follow to select therequirements Just Enough Requirements Management

26. Use Sensible Starting Point(s) • Gause/Weinberg • Using Any of the Aforementioned Techniques, Aim for • Goals • Needs • Users • Scenarios (Use Cases) • Outcomes • Reports • Compatible with Any Technique • Events • Screens • Features • Non-Functional Requirements • Requirements Just Enough Requirements Management

27. Appended to the OldRequirements The Result of Elicitation Here are the NewCandidateRequirements Just Enough Requirements Management

28. Outline • 1. Elicitation • 2. Triage • Definitions • Role in Overall Requirements Process • Effects of “Too Much” or “Too Little” • Tips for “Just Enough” Triage • The Result of Triage • 3. Specification • 4. Requirements Change • Summary Just Enough Requirements Management

29. Requirements Schedule Cost Triage • The art of selecting the “right” features to include in your next release • Engineering View: Balancing Requirements with Development Cost, Risk, and Schedule • Business View: Balancing Requirements with Development Cost, Risk, and Schedule, and Market, Sales, Revenues, Pricing, Profit, and ROI Just Enough Requirements Management

30. Cust Rep or Marketing DevelopmentFinance Cust Rep or Marketing:Prioritization Cust Rep or Marketing Cust Rep or Marketing BugReports UnsatisfiedFrom PreviousRelease Development:Estimation Development Baseline List ofCandidateRequirements List ofAnnotatedCandidateRequirements Product Development Triage in theRequirements Process C u s t o m e r s & C o m p e t I t I o n T e c h n o l o g y Just Enough Requirements Management

31. Effects of “Too Much” or “Too Little” Triage • Too much • You would spend so much time prioritizing, establishing interrelationships, and selecting/debating that no time would be left to build the system • Too little • You would build the wrong system • You would try to build more than you can build x Just Enough Requirements Management

32. (Expanded on Next Few Slides) “Just Enough” Triage • Maintain requirements in lists • Annotate requirements • by at least relative priority and cost-to-satisfy • Establish practices that pit the team “against” the problem, rather than between team members  • Let schedule drive requirements inclusion • Involve representatives from all key groups • Use probabilities of success, not absolutes • Often solution lies in out of box thinking x Just Enough Requirements Management

33. “It Will Take Us 9 Months” “Okay, Here Are Our Requirements By When Can You Build Them?” “Sorry, They Must Be Completed in 6 Months” Let Schedule Drive Req’ts(Not the Reverse) (1 of 2) • Typical Scenario NOW WHAT? Just Enough Requirements Management

34. “Let’s see. If we build reqts 1 through 9 and 12, we’ll be able to do them in 3 months” “Okay, we’re going to build in a series of 3 month increments. Here are all the requirements.” “But we really need reqt 17 in that first release.” “Okay. How about if we add reqt 17 and drop reqt 12?” Let Schedule Drive Req’ts(Not the Reverse) (2 of 2) • Better Scenario Just Enough Requirements Management

35. “Well if we drop requirements 3 and 4, we could do it.” “Hmmm. I really liked reqt 12. Can we drop reqt 3 instead?.” “Okay. How about if we add reqt 17 and drop reqt 12?” “Okay” Let Schedule Drive Req’ts(Not the Reverse) (2 of 2) • Better Scenario NOW THIS IS TEAMWORK Just Enough Requirements Management

36. Involve Representatives from All Key Groups • Customer (or a representative like marketing) • Development • Source of financial support (could be customer) • This is a Dynamic Three-Sided Negotiation Just Enough Requirements Management

37. “Solution” Often LiesOut-of-the-Box • Tell story from my experience at disk-farm company • New partial releases • Innovative marketing • Innovative pricing • Market re-segmentation Just Enough Requirements Management

38. The Result of Triage • Annotated list of requirements • Requirements selected for inclusion are flagged • Flagged requirements balanced with schedule and budget • All parties in agreement Just Enough Requirements Management

39. Outline • Introduction to Requirements Management • 1. Elicitation • 2. Triage • 3. Specification • Definitions • Role in Overall Requirements Process • Effects of “Too Much” or “Too Little” • Tips for “Just Enough” Specification • The Result of Specification • 4. Requirements Change • Summary Just Enough Requirements Management

40. Requirements Specification • The process of documenting the external characteristics of a desired system Just Enough Requirements Management

41. Cust Rep or Marketing DevelopmentFinance Cust Rep or Marketing:Prioritization Cust Rep or Marketing Cust Rep or Marketing BugReports UnsatisfiedFrom PreviousRelease Development:Estimation Development Baseline List ofCandidateRequirements List ofAnnotatedCandidateRequirements Product Development Specification in theRequirements Process C u s t o m e r s & C o m p e t I t I o n T e c h n o l o g y Just Enough Requirements Management

42. Effects of “Too Much” or “Too Little” Reqts Specification • Too much • You spend so much time documenting requirements that no time is left to build the system • Too little • You build the wrong system • Customers are surprised/disappointed by the system Just Enough Requirements Management

43. (Expanded on Next Few Slides) Secrets of “JustEnough” Specification • Avoid notations foreign to your customers • Include a glossary • Keep a list of “bonus” requirements • Don’t lose sight of goal • Customers have the right to change their minds! • Don’t go overboard checking for quality attributes • Maintain at “reasonable” level of detail  • Keep requirements in a list • Sign a baselining contract • To increase understanding, refine when necessary (and then maintain requirements in a hierarchical list) x Just Enough Requirements Management

44. Keep Requirements in a List(1 of 2) • Alternatives • Polished Standards-Based Document • Will at Least Double Your Requirements Effort with Little Appreciable Gain • A Collection of Diagrams • This is the Geek View of World: “If You Are Not a Geek, We’ll Train You to Be One” • “Real World” Pictures • Not Bad! But Potential for More Ambiguity • No Requirements Documentation • High Risk of Building Wrong System • Formal Specification • Except Under Special Circumstances, Will Alienate Customer Just Enough Requirements Management

45. Keep Requirements in a List(2 of 2) • Much Better • A List of Annotated Requirements (in Natural Language) Organized Hierarchically • Augment as Needed with More Formal Models (and Cross-References) Just Enough Requirements Management

46. Sign a Baselining Contract • All: We agree that the following list of requirements is the best set of requirements for which we can now agree to, and represents the best balance between requirements, schedule, and budget. • Marketing (or Customer Rep): I agree to not change the requirements prior to product delivery. • Development: I agree to deliver this set of requirements with sufficient quality on this date: _________________. • Finance: I agree to not reduce the total funding of this project below _________________ . • All: We agree to work together to arrive at a new optimal solution in the event that any of us are forced to violate the above contracts. Just Enough Requirements Management

47. When to Refine a Requirement • When a requirement is too general • When 2 stakeholders have differences of opinion concerning priority • Could be caused by ambiguity • Or could be legitimate difference in needs • When 2 developers have differences of opinion concerning effort • Could be caused by ambiguity • Could be caused by different assumptions Just Enough Requirements Management

48. The Result of Specification • Expanded List of Selected Annotated Requirements • Probably Augmented Selectively with Models • Probably Suppress Display of Rejected/Postponed Requirements Just Enough Requirements Management

49. Outline • Introduction to Requirements Management • 1. Elicitation • 2. Triage • 3. Specification • 4. Requirements Change • Background • Tips for “Just Enough” Requirements Change • Summary Just Enough Requirements Management

50. How Often Will Requirements Change? • On Average, 58% of Original Features Change* • The More the Customers See, the More They Will Want • Don’t Try to Suppress Requirements Change • Instead, Manage It and Understand It x *The Standish Group, “Chaos” 1995, www.standishgroup.com Just Enough Requirements Management