Is there any evidence suggesting that time spent on writing up, or thinking about the requirements will have any effect on the development time? Study done by Standish (1995) suggests that incomplete requirements partially (13.1%) contributed to the failure of the projects. Are there any studies done which show that time spent on requirement analysis will have any effect on development time of a project, or how successful the project will be.

  • 3
    $\begingroup$ How do agile models fit here? One can argue that they spend time of requirements (on and off) but there is no requirements "phase" as such. $\endgroup$
    – Raphael
    Mar 7, 2012 at 7:57
  • 1
    $\begingroup$ Agree with @Raphael. Are we going to take questions on software engineering? Or is the official policy of the site that it isn't worthwhile to distinguish between "computer science" and "software engineering" at this point in time? $\endgroup$
    – Patrick87
    Mar 7, 2012 at 14:52
  • 1
    $\begingroup$ @Patrick87 Let us move this to meta. $\endgroup$
    – Raphael
    Mar 7, 2012 at 15:19
  • $\begingroup$ It seems to me that this question would be a better fit for the existing Software Engineering and Project Management sites. $\endgroup$
    – Adam Lear
    Mar 11, 2012 at 1:07

2 Answers 2


See Code Complete, By Steve McConnell, Table 3-1. He compares the average cost of fixing defects based on when they're introduced and detected. Detection at construction time costs 5-10 times more than detection at requirements time, and 10-100 times more post-release.

The table is based on the following sources:

  1. "Design and Code Inspections to Reduce Errors in ProgramnDevelopment" (Fagan 1976)

  2. Software Defect Removal (Dunn 1984)

  3. "Software Process Improvement at Hughes Aircraft" (Humphrey, Snyder, and WIllis 1991)

and several more

  • $\begingroup$ That alone is not sufficient. Expensive mistakes have to happen often enough and have to be caught often enough by coming up with proper requirements. Otherwise, the extra cost of coming up with requirements might still outweigh mistake costs. $\endgroup$
    – Raphael
    Mar 7, 2012 at 7:57
  • $\begingroup$ That's true. We have to assume that up to a certain point, not rushing on requirements means that there are fewer errors in the requirements, but that doesn't seem like too much of a stretch. $\endgroup$
    – Joe
    Mar 7, 2012 at 8:06

Yes, there are plenty of studies on this topic. Of course, the question is too general to answer for all kinds of software development projects, but there is evidence from several contexts that support the notion that properly doing requirements analysis will have a positive impact on the implementation stage. This evidence has been partially collected into "laws", and here are three examples:

Glass' law: Requirement deficiencies are the prime source of project failures.

This law is backed up by case study evidence from large software development projects. Glass found that in the failed cases, there were far too many requirements, they were unstable due to late changes, and they were ambiguous and incomplete.

This suggests that there is a relation between the quality of requirements and the project outcome.

Boehm's first law: Errors are most frequent during the requirements and design activities and are the more expensive the later they are removed.

This is also backed up by case study evidence and contributes to answering the question in the following way: doing the requirements properly will reduce the number of errors in the system, and correcting the errors before starting implementation is going to be less expensive than hunting them down when implementation has already started (or worse, when the system has already shipped).

Boehm's second law: Prototyping (significantly) reduces requirement and design errors, especially for user interfaces.

This is backed up by controlled experiments in a student context. One possible interpretations is that requirements and design phases do not need to be entirely documentation-driven and theoretical. Instead, performing prototyping as part of the requirement and design phases – which amounts to spending time on and thinking about the requirements – is going to affect project success and implementation time.

There is also plenty of other evidence that points in the same direction: spending time on preparing for implementation pays off in the form of less risk and less chance of schedule overrun due to surprises. Although the question was not about testing, proper preparation positively affects testing, too.

The references for these laws are:

Glass' law: Glass, R.L.: Software Runaways. Lessons Learned from Massive Software Project Failures. Upper Saddle River, NJ: Prentice Hall 1998

Boehm's first law: Boehm, B.W., McClean, R.K., Urfrig, D.B.: Some Experience with Automated Aids to the Design of Large-Scale Reliable Software. IEEE Trans on Software Engineering 1, 1 (1975), 125–133

Boehm's second law: Boehm, B.W., Gray, T.E., Seewaldt, T.: Prototyping Versus Specifying: A Multiproject Experiment. IEEE Trans on Software Engineering 10, 3 (1984), 290–302

Also, the following reference may be of interest: Endres, A. and Rombach, D. A Handbook of Software and Systems Engineering. Empirical Observations, Laws and Theories. The Fraunhofer IESE Series on Software Engineering. Addison Wesley, 2003.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.