1 Requirements Best Practices. Webinar Host Presenter: Cheryl Hill, PMP Requirements Experts...

1

Requirements Best Practices

Webinar Host

Presenter:Cheryl Hill, PMPRequirements Expertscheryl@reqexperts.com956-491-8277

2

Cheryl Hill, PMPChief 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

5

1994

FailedChallenged

SuccessfulLosing 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

2009Challenged

Successful

Failed

Standish Group

6

Standish Group CHAOS 2003 Chronicles Report

Features

7

Baselined Scope

Document

Document

Scope

Document

Requirements

Validate

Requirements

Manage

Change

Validate

ScopeBaselined

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

DRIVERSINTERFACES

OperationalConcepts

Stakeholders

Defines the product

Sets the limits

Assumptions

Need

Goal Goal

Objective

Goal

Objective ObjectiveObjectiveObjective

1010

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.0 Introduction1.1 Purpose1.2 Document

History2.0 Business Case/Mission3.0 Need4.0 Goals and Objectives5.0 Operational Concepts6.0 Assumptions

7.0 Drivers and Constraints8.0 Stakeholders9.0 Authority and Responsibility10.0 Interfaces

10.1 External10.2 Internal

11.0 Risk12.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

Manufactureor Code

SR: Scope ReviewSRR: 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

Requirements

Validate

Requirements

Manage

Change

Validate

Scope Baselined Requirements

Document

Documenting Requirements

Good Requirements

• Needed• Verifiable• Attainable

– Technically– Cost– Schedule

17Customer-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

wayCustomer-Centered Products, p. 119

19

• 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

WhatConnect

Avoid Ambiguous Terms

20Customer-Centered Products, p. 162-4

• 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

Requirements

Validate

Requirements

Manage

Change

Validate

Scope Baselined Requirements

Document

Using Attributes to Improve Quality

Requirement Attributes

24

SR1 RationaleVerificationPriorityRisk

AllocationTraceability

A valid requirement includes attributes

System

Shall

What

- Why- How to prove- How important- Unknowns

- Who is affected- Is it covered

25

Rationale

• 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

26Customer-Centered Products, p. 210

System Requirement Review (SRR)

27

• Assess feasibility

• Set expectations

• Baseline Requirements

Customer-Centered Products, p. 58

SR: Scope ReviewSRR: System Requirements Review SDR: System Definition Review PDR: Preliminary Design Review CDR: Critical Design Review TRR: Test Readiness Review

SRRPDR

CDR

TRR

SR

Design

Verification

Operations

Upgrade/Maintain

Requirements

Scope

SDR

Manufactureor 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

Step Review for Who

How Many

1 Editorial Person with editorial skills

1-2

2 Goodness Knows rules; some technical knowledge

2-3

3 Content All stakeholders

As many

as needed

4 RiskTechnical 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

30

10

0

20

40

50 49%

31%

13%

5%

How to avoid requirement defects

36

Requirement Defects Methods 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

FUNDAMENTALS ADVANCED SPECIALIZED

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 www.reqexperts.com