Improving Quality Through
Better Requirements
Dr. Ralph R. Young
Northrop Grumman Information Technology
www.ralphyoung.net
Solving the Software Quality Puzzle
Page 1
www.psqtconference.com
The Importance of Requirements
•
•
•
•
•
•
Requirements are the basis of all of the technical work
performed on projects.
Requirements errors are the largest class of errors
typically found in a project (41-56% of errors discovered).
Reducing requirements errors is the single most effective
action developers can take to improve project outcomes.
There is great leverage (and cost savings) in identifying
omitted requirements and in finding errors in the
requirements stage vs. in later stages of the life-cycle.
The cost of rework is typically 45% of projects.
Requirements-related activities can reduce rework.
Solving the Software Quality Puzzle
Page 2
www.psqtconference.com
Industry Experience
The quality of software development efforts
improves when the investment in requirementsrelated activities is increased from the industry
average of 3% to an optimum level of 8-14% of
total project costs.
Solving the Software Quality Puzzle
Page 3
www.psqtconference.com
Areas to Focus On
1. Identify the real requirements (vice stated
requirements).
The stated requirements are never the
real requirements.
Customers and users need assistance in
identifying the real requirements.
This work needs to be accomplished
jointly.
Solving the Software Quality Puzzle
Page 4
www.psqtconference.com
Involve Your Customers and Users!
Acceptance,
integration &
verification
Detailed
design &
component
development
Storing
knowledge from
previous projects
User
requirements
System
requirements
Provisional
& final
acceptance
Supplier
work
Architectural
design
Customer work
Defining
results
for users
Defining what
the system
must do
Optimizing
the costbenefits
Solving the Software Quality Puzzle
Amount of effort
Informing the
enterprise
Deciding
Linking
Qualifying
Verifying
on potential deliverables
the
& validating
changes to requirements design
the product
Page 5
www.psqtconference.com
Involve All Project Participants:
Suggested Topics for “Early Project
Requirements Briefing”
•
•
•
•
•
•
•
•
•
•
Industry issues in requirements engineering
The value of investing more in the requirements process
The project and/or organization’s “Requirements Process”
Overview of the methods and techniques that will be used
Types of requirements
Gathering requirements
Roles of the requirements analyst
Criteria of a good requirement
Types of requirements errors and how these can be reduced
How we will reduce rework on our project
– Peer Reviews
– Inspections of all requirements-related documents
Solving the Software Quality Puzzle
Page 6
www.psqtconference.com
Areas to Focus On
(continued)
2. Document the rationale for each
requirement (why it is needed).
You may be able to eliminate up to half
of the requirements—saving a lot of
technical work and reducing cost, schedule,
and risk.
Solving the Software Quality Puzzle
Page 7
www.psqtconference.com
Types of Requirements Errors
(with thanks to Ivy Hooks)
Solving the Software Quality Puzzle
Page 8
www.psqtconference.com
Areas to Focus On
(continued)
3. Meet minimum requirements that satisfy
real needs.
We over-design systems, including
many features and capabilities that are not
“needed.”
The result: added cost, schedule, and
risk.
Solving the Software Quality Puzzle
Page 9
www.psqtconference.com
Areas to Focus On
(continued)
4. Use established criteria of a good
requirement.
Include this checklist in your automated
requirements tool.
Ensure each requirements meets these
criteria.
Solving the Software Quality Puzzle
Page 10
www.psqtconference.com
Criteria
of
a
Good
Requirement
•Necessary -- If the system can meet prioritized real needs without the
requirement, it isn’t necessary
•Feasible -- The requirement is doable and can be accomplished within cost and
schedule
•Correct -- The facts related to the requirement are accurate
•Concise – The requirement is stated simply
•Unambiguous – The requirement can be interpreted in only one way
•Complete -- All conditions under which the requirement applies are stated and it
expresses a whole idea or statement
•Consistent -- Not in conflict with other requirements
•Verifiable -- Implementation of the requirement in the system can be proved
•Traceable -- Can trace to the source of the requirement and it can be tracked
throughout the system (e.g., to the design, code, test, and documentation)
•Allocated --The requirement is assigned to a component of the designed system
•Design independent -- Does not pose a specific implementation solution
•Standard construct – The requirement is stated as an imperative using “shall”
•Unique identifier – Each requirement shall have a unique identifying number
Solving the Software Quality Puzzle
Page 11
www.psqtconference.com
Areas to Focus On
(continued)
5. Provide an effective mechanism to control
and manage new requirements and changes
to requirements.
This is how many projects get out of
control.
We need to explain to customers and
users how baselines, releases, versions, and
updated products can be used.
Solving the Software Quality Puzzle
Page 12
www.psqtconference.com
Areas to Focus On
(continued)
6. Write and use a requirements plan.
Consider employing proven effective
requirements practices and utilizing
requirements best practices.
Solving the Software Quality Puzzle
Page 13
www.psqtconference.com
Areas to Focus On
(continued)
7. Perform peer reviews and inspections of all
requirements-related materials.
Using peer reviews is a proven
technique to identify errors and save money.
The added cost of providing inspections
of requirements-related materials is cost
effective.
Solving the Software Quality Puzzle
Page 14
www.psqtconference.com
Use Metrics for Requirements
•
Number of requirements
–
–
–
Total number of requirements as of various dates
Number approved, added, deleted, modified
Number that are not clear
•
Number of requirements satisfied per build
• Project resources devoted to requirements
process (calendar time, staff hours, dollars)
• Percent requirements volatility per unit of time
(month and year), perhaps by functional
component of the system
Solving the Software Quality Puzzle
Page 15
www.psqtconference.com
Examples of Effective Requirements Practices
• Establishing and utilizing a “Joint Team”
responsible for the requirements.
• Using and continually improving a requirements
process.
• Iterating the requirements and the architecture.
• Performing requirements verification and
validation activities.
• Providing an effective mechanism to control
requirements changes.
Solving the Software Quality Puzzle
Page 16
www.psqtconference.com
Examples of Some Project Best Practices
1.
2.
3.
4.
5.
6.
7.
8.
Write (and iterate) a task or project “vision and scope
document.”
Identify and involve all of the stakeholders of the task or
project.
Use requirements workshops to achieve a shared vision,
facilitate commitment, and gain buy-in of all
stakeholders.
Use effective requirements gathering techniques.
Use a project glossary and a project acronyms list.
Prioritize requirements early and often.
Use an industrial-strength automated requirements tool.
Provide and use attributes of requirements.
Develop, implement, and enforce meeting rules that
describe how project staff members are to treat one
another.
Solving the Software Quality Puzzle
Page 17
www.psqtconference.com
Provide Training for Requirements Analysts
Suggested Topics:
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
The critical roles of the requirements analyst
Skills and characteristics of effective requirements analysts
The organizational and project requirements policies
The need for senior management sponsorship
The requirements process (flowchart and a narrative description)
Recommended project-approved methods, techniques, and tools
Metrics for the requirements-related activities
Suggested readings and reference materials
Effective communication techniques and mechanisms
How to control changes to requirements
Criteria of a good requirement
How to use the selected automated requirements tool
How to calculate the ROI from applying an improved practice
How to write a “Requirements Plan”
The value of a “Project Acronym List” and a “Project Glossary”
Solving the Software Quality Puzzle
Page 18
www.psqtconference.com
In Summary:
• We can improve software quality by paying more attention to
requirements activities.
• Requirements are important and provide many opportunities to
further strengthen and improve what we are doing.
• Several areas were suggested to focus on in your practical work.
• A set of “Effective Requirements Practices” was suggested.
• Some project best practices were suggested.
• It is only by making a few improvements in the actual practices
of what we do that we will get better.
• Inculcating values of continuous improvement, teamwork, and
support of each other will help.
Solving the Software Quality Puzzle
Page 19
www.psqtconference.com