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, the correct answer 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. 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 (Microsoft Press, 2006), I’ll offer some suggestions about how you can determine an appropriate amount of time and effort to invest in your own requirements development activities.
Here’s an illustration of how benchmarks may or may not be helpful. Table 1 presents some industry benchmark data for the average percent 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, Addison-Wesley, 2000). 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?
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 activities than the less successful teams—they’re just averages of actual performance.
Whereas typical project teams devote perhaps ten percent or less of their effort on requirements, investing more has a big payoff, provided the team doesn’t get trapped in analysis paralysis. Contrary to what many people believe, spending more time on requirements can actually accelerate software development.
While working on small projects when I was employed at Kodak, my team would typically devote fifteen to eighteen percent of our total effort on requirements activities. We found this investment reduced the amount of post-delivery rework we had to do. 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 development for your next project. However, Figure 1 identifies some of the conditions that can accelerate requirements development and several other factors that lengthen the time needed for effective requirements development.
Your Own Experience
Your best bet is to collect some data on how much of your own project effort is spent on requirements development and to 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 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 is baselined and change requests begin to appear.
Iterative and Incremental Approaches
Projects that follow an iterative life cycle will include requirements development at every iteration (dashed line in Figure 2). Projects using the iterative Rational Unified Process (RUP) will devote considerable effort to the requirements workflow during the early Inception phase and particularly during the Elaboration phase. As Scott Ambler and Larry Constantine (The Unified Process Elaboration Phase: Best Practices in Implementing the UP, CMP Books, 2000) point out regarding RUP’s Elaboration phase: “The basic idea is that your goal is to understand the core 80% of the system that you are building—you might be missing a few details, but you understand what it is that you are trying to build.” In this model, requirements activity continues at a reduced intensity level throughout the iterations in the later Construction and Transition phases.
Projects that follow an agile development approach, such as Scrum, take an incremental approach, rapidly building small portions of the product. This puts potentially useful functionality in the users’ hands quickly so that users can refine their needs and developers can keep up with changing business demands. Agile projects will have frequent but small requirements development efforts (solid line in Figure 2). Rather than being front-end loaded as on traditional projects, the requirements effort on an agile project is threaded throughout the project. Initial requirements explorations lead to a backlog of intended functionality of various priorities. When a particular feature or function is allocated to a specific iteration, the team will then refine the requirements for that functionality to whatever level of detail is needed to enable development and testing to proceed with confidence.
Many years ago, one of my software development group’s successful projects took just such an incremental approach. This project released useful functionality to the internal corporate user community every three weeks. The first part of each three-week cycle was spent on project planning and developing the requirements for that increment. The team did just enough requirements development for that increment, quickly implemented it, and provided new functionality to the users a piece at a time. The users provided feedback on those increments that helped steer the rest of the project toward delivering maximum value.
Not all projects are amenable to such fine-grained incremental delivery. When reengineering an existing application, for instance, the new system needs a critical mass of functionality before users can switch to it. Regardless of how large an increment your team tackles on each project cycle, they need to understand the requirements for that increment to avoid extensive rework of designs, code, and tests.
As with so many aspects of software projects, there’s more to requirements development than initially meets the eye. As you’re identifying the tasks your analysts might need to perform, consider whether activities such as the following will be necessary:
- Negotiating commitments with product champions.
- Holding elicitation workshops and conducting interviews.
- Reviewing existing documents and products.
- Preparing, distributing, and analyzing surveys.
- Creating and evaluating prototypes, analysis models, and other requirements views.
- Performing feasibility, risk, safety, failure, and hazard analyses.
- Entering requirements information into a database.
- Reviewing requirements specifications.
- Developing test cases from requirements and walking through the test cases.
- Revising requirements specifications following review or test analysis.
Your team might not perform all these activities on each project, and they might have to do other tasks as part of requirements elicitation, analysis, specification, and validation. Anything you learn about the tasks the analysts actually perform and how long those tasks take will improve your ability to estimate the requirements development effort needed for future projects.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.