Channels ▼
RSS

Design

The Requirements Payoff


Karl Wiegers is principal consultant with Process Impact, where he focuses on practical software process improvement.


Investing the time to create better requirements for a software project takes a major leap of faith, since people tend to think the extra up-front work will just delay development. That's generally true, but getting requirements right also prevents problems later that can not only delay projects but lead to their failure.

Incomplete requirements and specifications, as well as changing requirements, are a main cause of project distress. For example, the FBI abandoned its Virtual Case File case management software project in 2005, along with $170 million and 700,000 lines of code, in a large part because of poorly defined and slowly evolving design requirements, according to a scathing report by Department of Justice's Inspector General Glenn Fine. "It was a classic case of not getting the requirements sufficiently defined ... from the beginning," Fine says in the report. "And so it required a continuous redefinition of requirements that had a cascading effect on what had already been designed and produced."

An error, omission, or misunderstanding in the requirements forces developers to redo work they've done based on the incorrect requirement. Thirty percent or more of the total effort spent on most projects goes into rework, and requirement errors can consume 70% to 85% of all project rework costs, according to a 1997 study by Dean Leffingwell. Development teams often implement functionality that someone swore they needed, only to find that no one ever uses it. Techniques that can prevent this wasted effort are a solid investment.

What's To Be Gained

Good preliminary requirements help CIOs make effective business decisions regarding which projects to fund. Well defined and documented final requirements are critical to letting developers devise the most appropriate approach, estimate the effort needed to execute an iteration cycle or complete the project, incorporate changes that will deliver maximum customer value, and develop accurate test cases to verify the implemented functionality.

Putting more effort into requirements development can actually accelerate software development. At a large insurance company I worked with, increasing the front-end requirements effort from 19% to 33.6% of total effort reduced projects' overall effort and cost by an average of 4%. Another company trained its development teams on requirements engineering and implemented improved requirements practices. In a year, the share of projects that were behind schedule dropped from 21% to 12%, and the total days those projects were behind dropped from 1,738 to 518.

While no one can predict what ROI you're going to get from your investment in better requirements, consider these questions as a first step in determining payback:

  • What fraction of your development effort do you expend on rework? Some rework is unavoidable and adds value, but a lot of rework is nothing but wasted effort.
  • How much does a typical customer-reported defect cost your organization? A system-test defect? One of my clients spent an average of $4,200 to deal with each customer-reported defect. That was 21 times more than it cost them to discover a defect through formal inspection.
  • What fraction of user-reported defects and what fraction of defects discovered through system testing stem from errors in requirements? Defect root-cause analysis is an excellent technique to gauge how much you could gain from improving quality.
  • How much maintenance cost, from defect correction and unplanned enhancements, can you attribute to requirement defects such as missed requirements?
  • How much could you shorten your delivery schedules if your project teams could reduce requirement defects by, say, 50%?

Practices that result in fewer requirement defects will reduce the amount of development rework your teams must perform. This provides immediate payback through reduced development costs and quicker time to market. Techniques that get your analysts and customers working closer together also lead to products that better meet customer needs and need less reworking. All of these approaches have the potential to increase customer satisfaction.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video