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

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.

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

Data from Boehm et al., Software Cost Estimation with COCOMO II

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.

And next you must ask: who owns that responsibility in your organization? If the answer is “no one” or “I don’t know”, there’s a ripe opportunity to cut your schedules by 30% to maybe even 50%, all while improving your quality.

Code is not enough. It’s all about requirements; and that’s all about communication.