1 Requirements Best Practices

Webinar Host Presenter: Cheryl Hill, PMP Requirements Experts

Cheryl Hill, PMP Chief Operating Officer, Requirements Experts 3 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 Since joining Requirements Experts in 2003, Cheryl has worked extensively with RE clients 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.

Importance of Requirements to Project and Product Success 4

Failed Challenged Successful 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 2009 Challenged Successful Failed Standish Group

6 Standish Group CHAOS 2003 Chronicles Report Features

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

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. 8

Components of Scope 9 DRIVERS INTERFACES OperationalConcepts Stakeholders Defines the product Sets the limits Assumptions Need Goal Objective Goal Objective

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 Customer-Centered Products, p. 58

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

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

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

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

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 15

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

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

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

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

Avoid Ambiguous Terms 20 Customer-Centered Products, p 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

Implementation Versus Requirements 21 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”  How: The System shall include flight performance instrumentation.  What: The System shall measure its flight performance. What do you want to verify?

22 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 Perform a Goodness Check

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

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

Rationale 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 Customer-Centered Products, p. 132

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 26 Customer-Centered Products, p. 210

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

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 28

4½ Step Requirement Review Process 29 StepReview forWho How Many 1Editorial Person with editorial skills 1-2 2Goodness Knows rules; some technical knowledge 2-3 3ContentAll stakeholders As many as needed 4Risk Technical and management knowledge 2-3 4½Editorial Person with editorial skills 1-2

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 30 A well-constructed and conducted review is an important part of baselining requirements. The Baseline Decision

What’s Coming Next 31 Manage Change Requirement Management

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 32

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 33

34 Wrap-up

2% 35 Types of Requirement Defects Incorrect information Omissions Ambiguities Poorly written Misplaced % 31% 13% 5%

How to avoid requirement defects 36 Requirement DefectsMethods of prevention Incorrect Information  Complete scope  Operational concepts  Rationale  Include stakeholders Omissions  Ditto  Standard outline Ambiguities  Define verification  Validation Poorly Written  Simple format  Use editor Misplaced  Standard outline (template) Implementation or Operations  Ask “Why?”  Ask “What do you want to verify?”

37 Questions? Comments?

38 REQUIREMENTS EXPERTS SEMINARS FUNDAMENTALSADVANCEDSPECIALIZED Before Requirements Duration: 1-day PDU: 7 Writing Interface Requirements, Performing Requirement Allocation and Traceability Duration: 1-day PDU: 7 Managers and Requirements Duration: 1-day or shorter PDU: 7 Writing Good Requirements Duration: 1-day PDU: 7 Case Study Workshop Duration: 1-day PDU: 7 Conducting a Requirement Review Duration: 1-day PDU: 7 Managing Requirements Duration: 1-day PDU: 7 Work Product Inspections Duration: 1-day PDU: 7 Requirement Definition Duration: 2-day PDU: 14 Work Product Inspections – Moderator Workshop Duration: 1-day PDU: 7 Requirement Management Duration: 2-day PDU: 14 QA and Requirements Duration: 1-day PDU: 7 Requirement Definition & Management Duration: 3-day PDU: 21 Writing Performance-Based Statements of Work Duration: 2-day PDU: 14 Requirement Fundamentals for the Business Analyst Duration: 2-day PDU: 14 For more information, contact us at