How Long Do Requirements Activities Take?

Business analysts and managers sometimes ask me how long it will take to “do requirements” on their next project.

As with so many issues in software and product development, the correct answer to this question is “it depends.”

Multiple variables contribute to this issue. Various industry averages have been published to suggest what percentage of a typical project’s effort should be devoted to requirements development, which includes activities such as requirements gathering (also known as requirements elicitation).

Data from different benchmarks don’t agree very well, though, and whether these “typical” projects are similar to your own is questionable. In this article, adapted from my book, “More about Software Requirements,” I’ll offer some suggestions about how you can determine an appropriate amount of time and effort to invest in things like requirements gathering.

Industry Benchmarks

Here’s an illustration of how benchmarks may or may not be helpful. Table 1 (below) presents some industry benchmark data for the average percentage of total effort and the average schedule time that projects in several different categories devote to requirements elicitation and prototyping (data from Capers Jones’ “Software Assessments, Benchmarks, and Best Practices”). These benchmarks are for very large projects of 10,000 function points in size (approximately one million lines of code). How similar are your projects to these benchmarks?

Table 1. Benchmarks for Requirements Work on Large Projects

There’s another problem with using industry benchmarks such as these. The data doesn’t indicate how successful those projects were or define what “success” means for each project. Nor does this data indicate whether the more successful project teams devoted more of their effort to requirements elicitation activities than the less successful teams — they’re just averages of actual performance.

Whereas typical project teams devote perhaps 10% or less of their effort on things like requirements gathering, investing more has a big payoff, provided the team doesn’t get trapped in analysis paralysis. Contrary to what many people believe, spending more effort in improving your requirements development process can actually accelerate development.

A recent study by Engineering.com found that development teams without strong requirements management platforms reported more production outcome failures and reprimands by regulatory agencies.

Read it now.

While working on small projects when I was employed at Kodak, my team would typically devote 15%-to-18% of our total effort on requirements activities. We found this investment reduced the amount of post-delivery rework. It’s difficult to link causes and effects with certainty, but I believe the greatest contributing factor to our low maintenance level was the extensive user participation we cultivated.

I can’t tell you how long you should expect to spend on requirements gathering for your next project. However, Figure 1 identifies some of the conditions that can accelerate your requirements process and several other factors that lengthen the time needed for developing effective requirements.

Figure 1. Factors that influence the time needed for requirements development.

Your Own Experience

For starters, your best bet is to collect some data on how much of your own project effort is spent on requirements gathering. That’ll help you judge how well that has worked for you in the past. Use this historical data when estimating the requirements effort needed for future projects. Adjust your initial estimate by using the considerations in Figure 1 to compensate for differences between your next project and the benchmark projects. Consider any additional factors that would influence your own project. You might weight each of the factors shown in Figure 1 on a scale of 0 (no effect) to 5 (major impact). This analysis can help you spot risk factors that could prolong your requirements development work.

Another factor to consider is the development life cycle that the project is following. Not all the requirements elicitation effort should be allocated to the early stages of the project, as is the case in the sequential or waterfall life cycle (dotted line in Figure 2). Don’t think in terms of a discrete “requirements phase,” but rather about a set of requirements-related activities that span the project’s life cycle. In particular, requirements management will be performed on an ongoing basis once a set of requirements baselines emerge for the System Requirements Specification (SRS) and change requests begin to appear.