Just Enough Requirements Management : Where Software Development Meets Marketing

Preface xi ONE: Introduction 3(37) Requirements 3(3) Requirements Management 6(2) Just Enough 8(2) The Context of Requirements 10(8) The Relationship Between Schedule and Requirements 18(5) How Much Time to Spend on Requirements? 18(2) Who Should Define the Schedule? 20(1) Schedule Should Drive Requirements 20(1) How Much Time Between Releases? 21(2) The Components of Requirements Management 23(13) The Importance of Requirements Management 36(4) TWO: Requirements Elicitation 40(23) Definitions and Terminology 40(5) Why Do Elicitation? 45(1) Elicitation Techniques 45(14) Interviewing 47(1) Facilitated Group Meetings 48(4) Computer-Supported Cooperative Work 52(1) Observation 53(1) Questionnaires 54(1) Prototyping 55(1) Scenarios, Use Cases, Stories, and Storyboarding 56(2) Modeling Notations 58(1) The Result of Elicitation 59(2) The Secrets of Just Enough Elicitation 61(2) THREE: Requirements Triage 63(56) Definitions and Terminology 63(4) Why Do Triage? 67(1) Basic Triage Techniques 68(29) Prioritizing Candidate Requirements by Importance and Cost 69(5) Estimating Effort for Candidate Requirements 74(1) Disagreements Concerning Relative Priority of Requirements 75(2) Disagreements Concerning Effort to Satisfy a Requirement 77(1) Establishing Requirements Relationships 78(5) Performing Triage on Multiple Releases 83(1) Making the Triage Decision 84(13) Delivery Date: Talking Apples and Apples 97(1) Advanced Triage Techniques 97(18) Considering Risks Inherent in Addressing Specific Requirements 98(3) Considering Market and Market Size 101(1) Considering the Market Window 102(2) Considering Market Penetration 104(1) Considering Price 105(3) Considering Costs 108(2) Considering Revenues 110(1) Considering the Effect of Investment 110(4) Putting It All Together 114(1) The Result of Triage 115(1) The Secrets of Just Enough Triage 116(3) FOUR: Requirements Specification 119(44) Definitions and Terminology 119(3) Classic Requirements Documentation Styles 122(3) The Content of a Requirements Document 125(2) The Role of a Requirements Document 127(1) Qualities of a Requirements Document 128(8) Specification Techniques 136(20) Feature Intensity 136(4) State-Based Problems 140(2) Decision-Based Problems 142(4) Nonbehavioral Requirements 146(7) User Interface 153(2) Hardware Interface 155(1) Requirements for Reports 156(1) The Result of Specification 156(5) The Secrets of Just Enough Specification 161(2) FIVE: Requirements Change 163(9) Where Do Changes Come From? 164(1) How to Keep Track of Requested Changes 165(1) Choices for Handling the Changes 165(5) The CCB Meeting 170(1) The Secrets of Just Enough Change 171(1) SIX: Summary 172(5) Requirements Elicitation 173(1) Requirements Triage 174(1) Requirements Specification 175(1) Requirements Change Management 176(1) APPENDIX A: Quick Recipes 177(23) Brainstorm 178(5) Decide What Is or Isn't a Requirement 183(2) Decide What to Build 185(3) Produce a Requirements Document 188(2) Assess the Quality of a Requirements Document 190(2) Baseline the Requirements 192(1) Ensure That Everybody Knows the Requirements 192(2) Handle New Requirements After Baselining 194(2) Handle Multiple Customers 196(4) APPENDIX B: A Set of Documented Requirements 200(9) References and Additional Readings 209(18) Index 227(12) About the Author 239