Requirements Best Practices

1. Requirements Best Practices

2. Webinar Host Presenter: Cheryl Hill, PMP Requirements Experts cheryl@reqexperts.com 956-491-8277

3. Cheryl Hill, PMPChief Operating Officer, Requirements Experts • Since joining Requirements Expertsin 2003, Cheryl has worked extensively with REclients to properly define scope and to effectively elicit, validate, document and manage requirements. • Cheryl's project management experience includes managing full-life cycle implementations of Siebel CRM and SAP application packages as well as managing custom software development projects. • Recognized as a leading provider of requirement definition and management training and consulting services • Wide variety of 1, 2, and 3 day seminar offerings to address the different challenges organizations face with requirements

4. Importance of Requirements to Project and Product Success

5. Standish Group Losing sight of requirements is often the first step on the road to projects that come in over budget, are late, do not meet specifications or are canceled. Standish Group CHAOS Chronicles 2003 report Successful 1994 Challenged Failed Successful 2009 Challenged Failed

6. Standish Group CHAOS 2003 Chronicles Report Features

7. Defining and Baselining Scope Document Scope Baselined Scope Document Validate Scope Baselined Requirements Document Document Requirements Validate Requirements Manage Change

8. What is Scope? The set of information that provides a clear vision and common understanding for those who will write, review, and manage product requirements or have a significant interest in the product across its life cycle.

9. Components of Scope Need Operational Concepts Goal Goal Goal Assumptions Objective Objective Objective Objective Objective INTERFACES Stakeholders DRIVERS Defines the productSets the limits

10. Scope - Benefits Set the boundaries Avoid battles Get issues resolved Prevent incorrect requirements Less time to write requirements Speed up review process Help manage change 10 Customer-Centered Products, p. 58

11. Scope Document Template • 1.0 Introduction • 1.1 Purpose • 1.2 Document History • 2.0 Business Case/Mission • 3.0 Need • 4.0 Goals and Objectives • 5.0 Operational Concepts • 6.0 Assumptions • 7.0 Drivers and Constraints • 8.0 Stakeholders • 9.0 Authority and Responsibility • 10.0 Interfaces • 10.1 External • 10.2 Internal • 11.0 Risk • 12.0 Approvals

12. Scope Review • Baseline vision • Get stakeholder buy-in • Set expectations • Make Go/No Go Decision Scope Requirements Design Manufactureor Code SR Verification SDR Operations SRR PDR Upgrade/Maintain CDR TRR SR: Scope Review SRR: System Requirements Review SDR: System Definition Review PDR: Preliminary Design Review CDR: Critical Design Review TRR: Test Readiness Review Customer-Centered Products, p. 58

13. Management’s Role in a Scope Review • Review and approval of scope information prior to dissemination • Ensure the right participants • Provide guidelines, standards and templates • Act on participant feedback • Document and communicate disposition of participant feedback • Obtain approval and sign-off from all participants

14. Identify Scope Risks • Do we have product boundary questions? • Have we missed a key stakeholder? • Have we missed a product life-cycle phase? • Are there areas of strong disagreement? • Are there technical issues? • Are there schedule issues? • Are there cost issues? • Are there too many uncertainties? Yes = High risk No = Low risk

15. What to do now • High scope risk • Postpone requirement writing • Mitigate the risks • Rethink • Low scope risk • Put risk mitigation plan into work • Start requirement writing

16. Documenting Requirements Document Scope Baselined Scope Document Validate Scope Baselined Requirements Document Document Requirements Validate Requirements Manage Change

17. Good Requirements • Needed • Verifiable • Attainable • Technically • Cost • Schedule Mandatory Characteristics Customer-Centered Products, p. 119

18. Characteristics of Good Requirements Improving Communications • One Thought • Concise • Simple • Stated Positively • Grammatically Correct • Can only be understood one way Customer-Centered Products, p. 119

19. What a requirement must state Who Connect What • WHOis responsible • The system • The software • The structure • WHAT shall be done • operate at a power level of … • acquire data from … • withstand loads up to …

20. Avoid Ambiguous Terms • etc. • Maximize • Sufficient • User-friendly • Robust • High speed • Support • Accommodate • Indefinite pronouns • it • this • Including, but not limited to • Minimize • Adequate • Easy • Ultra-low power • TBD • And / Or • Be able to/be capable of Customer-Centered Products, p. 162-4

21. Implementation Versus Requirements • How:The System shall include flight performance instrumentation. • What:The System shall measure its flight performance. What do you want to verify? • How: The aircraft shall have three engines (DC-3 initial requirements). • What: The aircraft shall meet the operation requirements with a single engine out. The magic of “why”

22. Perform a Goodness Check • Format (who-what) • Terminology (shall, unambiguous,..) • One Thought • Concise • Simple • Stated Positively • Grammatically Correct • Can only be understood one way • Needed (at the right level) • Verifiable

23. Using Attributes to Improve Quality Document Scope Baselined Scope Document Validate Scope Baselined Requirements Document Document Requirements Validate Requirements Manage Change

24. Requirement Attributes A valid requirement includes attributes Rationale Verification Priority Risk Allocation Traceability SR1 - Why - How to prove - How important - Unknowns - Who is affected - Is it covered System Shall What

25. Rationale captures why I have the requirement and other information relevant when the requirement was written Captured when requirements are written Non-generic e.g., unique for each requirement Reflects operational concepts, assumptions, drivers, constraints ROI is high Ensures better requirements Reduces review time Supports maintenance and upgrades Captures corporate knowledge Rationale Customer-Centered Products, p. 132

26. Prioritization • Prioritization assigns relative importance to requirements • Assigned after we have a set of requirements • Simple is better • Has to involve multiple stakeholders and all are not equal • Has to be maintained through levels of requirements • ROI is medium • Enables you to better plan and manage the effort • Helps you manage the unknown unknowns • Helps improve communications • Reduces the number of requirements Customer-Centered Products, p. 210

27. System Requirement Review (SRR) • Assess feasibility • Set expectations • Baseline Requirements Scope Requirements Design Manufactureor Code SR Verification SDR Operations SRR PDR Upgrade/Maintain CDR SR: Scope Review SRR: System Requirements Review SDR: System Definition Review PDR: Preliminary Design Review CDR: Critical Design Review TRR: Test Readiness Review TRR Customer-Centered Products, p. 58

28. System Requirements Review • Key milestone that requires time and resources • Formal process • Complete document • Involves a wide range of stakeholders • Requires standards and feedback mechanisms • Requires training • Management has to ensure responsiveness • SRR results in a requirement baseline • Benefits IF • The right people are involved • The products are ready for review • The participants know what to do

29. 4½ Step Requirement Review Process

30. The Baseline Decision • Are the requirements “done enough” to proceed to design? “Done enough” = point where cost of potential changes is less than the investment required to anticipate every requirement • No simple indicator! • Should be content driven, not milestone driven A well-constructed and conducted review is an important part of baselining requirements.

31. What’s Coming Next Requirement Management Manage Change

32. Why Requirements Change • Poor original requirements • Ignored original requirements • Changed needs • Don’t know what is wanted without seeing an example • To keep pace with technology upgrades • Reset expectations

33. The Management of Change • Scope • Any change in scope needs to be integrated in a controlled manner into all documentation • Requirements • Before baseline, change as needed • After baseline, documented process • Metrics of change • Total amount • Rate-of-change, up and down • Resources applied

34. Wrap-up

35. Types of Requirement Defects • Incorrect information • Omissions • Ambiguities • Poorly written • Misplaced 49% 50 40 31% 30 20 13% 10 5% 2% 0

36. How to avoid requirement defects

37. Questions?Comments?