Transcript Requirement Development and Management

Requirements Best
Practices
1
Webinar Host
Presenter:
Cheryl Hill, PMP
Requirements Experts
[email protected]
956-491-8277
2
Cheryl Hill, PMP
Chief Operating Officer, Requirements Experts
• 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.
• 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
3
Importance of Requirements to
Project and Product Success
4
Standish Group
Successful
1994
Failed
Challenged
Successful
2009
Challenged
Failed
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
5
Standish Group CHAOS 2003 Chronicles
Report
Features
6
Defining and Baselining Scope
Document
Scope
Validate
Baselined
Scope
Document
Scope
Baselined
Requirements
Document
Document
Requirements
Validate
Requirements
Manage
Change
7
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
Need
Goal
Objective
Objective
Goal
Objective
Operational
Concepts
Goal
Objective
Objective
Assumptions
Stakeholders
INTERFACES
DRIVERS
Defines the product
Sets the limits
9
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
10
10
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
8.0
9.0
10.0
Drivers and Constraints
Stakeholders
Authority and Responsibility
Interfaces
10.1 External
10.2 Internal
11.0 Risk
12.0 Approvals
11
Scope Review
Scope
Requirements
Design
•
Baseline vision
•
Get stakeholder buy-in
•
Set expectations
•
Make Go/No Go Decision
Manufacture
or Code
SR
Verification
SDR
SRR
Operations
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
12
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
13
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
Documenting Requirements
Document
Scope
Validate
Baselined
Scope
Document
Scope
Baselined
Requirements
Document
Document
Requirements
Validate
Requirements
Manage
Change
16
Good Requirements
Mandatory Characteristics
• Needed
• Verifiable
• Attainable
– Technically
– Cost
– Schedule
Customer-Centered Products, p. 119
17
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
18
What a requirement
must state
• WHO is responsible
– The system
– The software
– The structure
Who
Connect
What
• WHAT shall be done
– operate at a power level
of …
– acquire data from …
– withstand loads up to …
19
Avoid Ambiguous Terms
• etc.
• Including, but not limited to
•
•
•
•
•
•
•
•
•
•
Maximize
Sufficient
User-friendly
Robust
High speed
• Support
• Accommodate
Minimize
Adequate
Easy
Ultra-low power
TBD
• And / Or
• Be able to/be capable of
• Indefinite pronouns
– it
– this
Customer-Centered Products, p. 162-4
20
Implementation Versus
Requirements
•
•
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?
21
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
22
Using Attributes to
Improve Quality
Document
Scope
Validate
Baselined
Scope
Document
Scope
Baselined
Requirements
Document
Document
Requirements
Validate
Requirements
Manage
Change
23
Requirement Attributes
A valid requirement includes attributes
Rationale
Verification
Priority
Risk
SR1
System
Shall
What
-
Why
How to prove
How important
Unknowns
Allocation - Who is affected
Traceability - Is it covered
24
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
25
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
26
System Requirement
Review (SRR)
Scope
•
Assess feasibility
•
Set expectations
•
Baseline Requirements
Requirements
Design
Manufacture
or Code
SR
Verification
SDR
SRR
Operations
PDR
SR: Scope Review
SRR: System Requirements Review
SDR: System Definition Review
PDR: Preliminary Design Review
CDR: Critical Design Review
TRR: Test Readiness Review
Upgrade/
Maintain
CDR
Customer-Centered Products, p. 58
TRR
27
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
Step
Review for
Who
How
Many
1
Editorial
Person with editorial
skills
1-2
2
Goodness
Knows rules; some
technical knowledge
2-3
As many
as
needed
3
Content
All stakeholders
4
Risk
Technical and
management knowledge
2-3
Editorial
Person with editorial
skills
1-2
4½
29
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.
30
What’s Coming Next
• Manage Change
31
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
Wrap-up
34
Types of Requirement
Defects
•
•
•
•
•
Incorrect information
Omissions
50 49%
Ambiguities
40
Poorly written
30
Misplaced
20
10
0
31%
13%
5%
2%
35
How to avoid requirement defects
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?”
36
 Ask “What do you want to verify?”
Questions?
Comments?
37
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
38