1 requirements best practices. webinar host presenter: cheryl hill, pmp requirements experts...
TRANSCRIPT
1
Requirements Best Practices
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