{"id":3100,"date":"2019-06-11T08:00:37","date_gmt":"2019-06-11T15:00:37","guid":{"rendered":"https:\/\/www.jamasoftware.com\/?p=3100"},"modified":"2023-01-12T16:51:37","modified_gmt":"2023-01-13T00:51:37","slug":"how-long-do-requirements-activities-take","status":"publish","type":"post","link":"https:\/\/www.jamasoftware.com\/legacy\/blog\/2019\/06\/11\/how-long-do-requirements-activities-take\/","title":{"rendered":"How Long Do Requirements Take?"},"content":{"rendered":"

\"\"<\/p>\n

Business analysts and managers sometimes ask me how long it will take to \u201cdo requirements\u201d on their next project.<\/p>\n

As with so many issues in software and product development, the correct answer to this question is \u201cit depends.\u201d<\/p>\n

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

Data from different benchmarks don\u2019t agree very well, though, and whether these \u201ctypical\u201d projects are similar to your own is questionable. In this article, adapted from my book,\u00a0\u201cMore about Software Requirements<\/a>,\u201d I\u2019ll offer some suggestions about how you can determine an appropriate amount of time and effort to invest in things like requirements gathering.<\/p>\n

Industry Benchmarks<\/strong><\/p>\n

Here\u2019s 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\u2019\u00a0\u201cSoftware Assessments, Benchmarks, and Best Practices<\/a>\u201d). 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?<\/p>\n

\"\"

Table 1. Benchmarks for Requirements Work on Large Projects<\/p><\/div>\n

There\u2019s another problem with using industry benchmarks such as these. The data doesn\u2019t indicate how successful those projects were or define what \u201csuccess\u201d 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 \u2014 they\u2019re just averages of actual performance.<\/p>\n

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\u2019t get trapped in analysis paralysis. Contrary to what many people believe, spending more effort in improving your requirements development process can actually accelerate development.<\/p>\n

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.<\/p>\n

Read it now<\/a>.<\/p><\/blockquote>\n

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\u2019s 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.<\/p>\n

I can\u2019t tell you how long you should expect to spend on requirements gathering for\u00a0your<\/em>\u00a0next 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.<\/p>\n

\n
\n
\n

\"\"

Figure 1. Factors that influence the time needed for requirements development.<\/p><\/div><\/dt>\n<\/dl>\n<\/div>\n

Your Own Experience<\/strong><\/p>\n

For starters, your best bet is to collect some data on how much of your own project effort is spent on requirements gathering. That\u2019ll 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.<\/p>\n

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\u2019t think in terms of a discrete \u201crequirements phase,\u201d but rather about a set of requirements-related activities that span the project\u2019s 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.<\/p>\n

\"\"<\/p>\n

Figure 2. The distribution of requirements effort over time varies for projects that follow different development life cycles.<\/p>\n

<\/p>\n

<\/div>\n