Requirements Analysis and Modeling
from The UML Guy
An Argument for
Requirements Analysis
|
What follows is chapter 1 from my upcoming book, Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements.
I find that on many projects, we don't need better technology, we need better requirements.
I hope this gives you something to think about.
-- Martin L. Shoemaker
(The UML Guy)
|
 |
An attempt to trade quality for cost or schedule actually
results in increased cost and a longer schedule.
-- Steve McConnell, Professional Software Development
|
What has long been known in other businesses is true for software development as
well: if you cut corners for shorter schedules or lower costs, you will get
longer schedules, higher costs, and higher defect rates; but if you
take the right measures to lower defect rates, you can get lower defect rates
and shorter schedules and lower costs. As Crosby wrote,
“Quality is free.” But it’s free only in terms of ROI, meaning the investment
must be made first; and it’s only free if you first define what you mean by
“quality”.
|
Fortunately, Crosby provided the appropriate definition as well: quality is
conformance to requirements. That can be a concrete, quantifiable definition;
but in some way it just moves the problem down the road, leaving us to define
requirements: not just the term, but the specific requirements of our projects.
It leaves us with this inescapable truth:
If we don’t know our requirements,
we can’t have quality.
|
…we must define quality as “conformance to
requirements” if we are to manage it.
-- Philip B. Crosby,
Quality is Free: The Art of Making Quality Certain
|
|
Recent surveys have found that the most frequent causes
of software project failure have to do with requirements problems – requirements
that define the wrong system, that are too ambiguous to support detailed
implementation, or that change frequently and wreak havoc on the system design.
-- Steve McConnell, Professional Software Development
|
Data from Boehm et al., Software Cost Estimation
with COCOMO II
|
Poorly defined requirements are endemic to the software development industry.
Boehm’s research on factors that affect development schedules and costs show
that:
Excellent requirements analysts can reduce a project’s
schedule by almost 30%,
while inadequate analysis can increase the schedule by
over 40%.
Again and again, schedule pressures lead teams to start developing before they
have sufficient requirements definition.
|
Data from Boehm et al., Software Cost Estimation
with COCOMO II
|
Even though requirements analysis is a key skill, the
topic isn’t as “hot” as new technologies and tools that are promoted by vendors
and conferences and magazines. And many development teams feel swamped just
trying to keep up with technologies and tools.
-- Martin L. Shoemaker, Requirements Patterns and Antipatterns: Best (and Worst) Practices for Defining Your Requirements |
Among all personnel factors, Analyst capability has the widest range of impact
(multiplier range of 2, worst case divided by best case). Teams may tout their
application experience as a strength; but application experience has an
Influence Range of only 1.51. Application and platform experience combined
have an Influence Range of 2.11. Teams would never throw out their domain
knowledge and develop for an entirely new platform; but poor
requirements practices have almost the same Impact Range.
These teams aren’t foolish, yet they foolishly let a critical aspect of their
process get out of control on project after project. A look at their team
rosters may give a clue as to why: while there are many roles on the rosters,
there may be none with requirements as a primary responsibility.
Marketing and sales have requirements responsibilities, but many conflicting
responsibilities as well. Lead engineers are supposed to verify requirements;
but they are also too busy, and are commonly focused on solutions, not
requirements. Designers and developers also focus more on how than on
what. Traditionally in software development, analysts have primary
responsibility for and are evaluated on the correctness of requirements.
The role of requirements analysts is
to define the problem in a verifiable form,
so that teams may recognize a valid solution.
If you would like to discuss how to improve requirements analysis and cut
costs and schedule on your next project, contact The UML Guy.
Or maybe you want The UML Guy to train your team to be better requirements analysts...
|