Javascript required
Skip to content Skip to sidebar Skip to footer
Home / Srs Stands for System Requirements Solution

Srs Stands for System Requirements Solution

How Long Do Requirements 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.

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 foryour 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.

Figure 2. The distribution of requirements effort over time varies for projects that follow different development life cycles.

Iterative and Incremental Approaches

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 gathering 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, developing, and gathering 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.

Planning Requirements Elicitation

As with so many aspects of projects, there's more to requirements gathering 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. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at ProcessImpact.com.

In This Webinar, Learn More About Requirements Traceability

DEFINITION OF TRACEABILITY:

Traceability: relationships between items to show evidence of requirement decomposition and verification coverage.

Srs Stands for System Requirements Solution

Source: https://www.jamasoftware.com/requirements-management-guide/requirements-gathering-and-management-processes/how-long-do-requirements-take