The Most Complete Guide to Requirements Management and Traceability

How long Do Requirements Take?

Have you ever wondered how much time it would take to create the requirements for your upcoming project? Business analysts and managers often ask this question.

For most issues related to software and product development, there is no one-size-fits-all answer; the response truly depends on your unique circumstances.

Several variables contribute to this problem, leading industry averages suggesting what percentage of a project’s effort should be devoted to requirements development such as gathering and elicitation.

How can you determine the proper amount of time and effort required for activities such as requirements gathering? Not surprisingly, data from diverse benchmarks don’t always jibe with each other. It is also debatable whether these “usual” projects are akin to your own. To help you resolve this issue, I have adapted some ideas from my book “More about Software Requirements” in this article – check it out!

Industry Benchmarks

To provide an example of the potential usefulness of benchmarks, please refer to Table 1. The data presented indicates industry averages for various requirements elicitation and prototyping efforts regarding projects that are 10,000 function points in size (approximately one million lines of code), sourced from Capers Jones’ “Software Assessments, Benchmarks, and Best Practices.” How pertinent are these figures to your own project?

Utilizing industry benchmarks such as these is not without its drawbacks. The data fails to tell us whether the projects were truly successful or if there was any correlation between success and efforts placed on eliciting requirements. This information only gives us an average of what has been performed, thus making it difficult to accurately describe the success of each individual project.

Allocating 10% or less of the team’s efforts to tasks such as requirements gathering can prove beneficial, provided that they don’t become stuck in analysis paralysis. Contrary to popular belief investing an increased amount of effort into enhancing your requirement development process will actually speed up production. Leveraging this concept provides a massive return on investment for any project!

As I worked on smaller projects when employed at Kodak, our team often allocated 15% to 18% of the total effort to requirement activities. We found that this investment decreased the amount of post-delivery alterations needed. It’s tricky to connect causes and effects with certainty, but it is likely that our low maintenance rate was largely due to cultivating significant user participation.

Trying to figure out exactly how much time requirements gathering for your next project will take is a tricky ask, and can be difficult to gauge accurately. Yet luckily, Figure 1 gives us some insight into the variables that can shorten or lengthen said process; helping you estimate more effectively when creating those necessary requirements.

Your Own Experience

To kick off, it might be useful to review the data from past projects to determine what kind of effort was dedicated specifically to requirements gathering. This will allow you to assess how successful your development process has been in the past and use this information when estimating its cost for future endeavors. As an additional factor, adjust your initial estimates by referencing Figure 1 which outlines differences between upcoming projects and benchmark ones as well as taking into account any other relevant considerations concerning your project at hand. By assessing each of the elements listed in Figure 1 on a scale ranging from 0 (no influence) to 5 (great effect), this evaluation can help you detect risk factors that could extend your requirements development process.

Alongside other elements, it is essential to consider the life cycle of the project. Don’t assume that all requirements should be accumulated at the beginning like in a sequential or waterfall approach (illustrated by the dotted line in Figure 2). Rather than having a distinctive “requirements phase,” think about an array of requisites that traverse through each stage of development. As our System Requirements Specification (SRS) evolves and change requests begin to arise, we must remain diligent in actively managing the requirements baselines. This is an ongoing process that requires consistent attention.

Iterative and Incremental Approaches

Agile development approaches, like Scrum, take a progressive route. This allows users to get their hands on the product’s potentially useful features quickly and easily modify their requirements as needed. Thus developers can keep up with ever-changing business demands effortlessly. With agile projects, there is seldom a need for large requisition initiatives because of small but regular requirement collection efforts (solid line in Figure 2).

Instead of being focused on the beginning of the project, requirements effort in an agile project is spread across various stages. Initial explorations lead to a backlog detailing functionality based on its priority level. When it’s time for development and testing, teams refine requirements so they have enough detail to proceed confidently with each iteration.

Years ago, I was part of a software development team that leveraged an incremental approach to ensure success. Each cycle, our project would be released in three-week phases with the first portion being dedicated to planning out requirements and developing for that specific increment. We were met with great results from this method as it brought useful functionality every few weeks to the corporate user base. The team worked diligently to swiftly deliver new functionality in increments, providing users with frequent updates. These user insights were invaluable for guiding the project and helping ensure that maximum value was achieved by its completion.

Not all initiatives are suitable for delivering in small chunks. When rebuilding an existing application, the new system must possess a substantial level of functionality before users can transition over to it. Regardless of how much your team completes on each project cycle, they have to comprehend the requirements for that particular sequence in order to prevent any drawn-out redo’s and rewrites of designs, code, or tests.

Planning Requirements Elicitation

It’s often more complicated than it appears when you start to compile the requirements for a new project. When brainstorming activities that your analysts need to do, keep in mind whether they will have to carry out duties such as these:

Cultivating relationships with product champions through negotiation.
Gathering insights through interactive workshops and in-depth interviews.
Examining existing records and products to unearth potential improvements.
Constructing, disseminating, and deciphering surveys.
Designing, and assessing prototypes, studying models, and other requirement perspectives for success.
Achieving success through risk assessment, ensuring safety and security protocols are being observed, analyzing potential failures, and conducting hazard examinations.
Logging the details of your needs into a data repository.
Carefully scrutinizing the demands detailed in requirements specifications.
Crafting test cases from the listed requirements, and meticulously evaluating their performance.
After a thorough review or testing, fine-tune requirements specifications to ensure accuracy.

To be able to better estimate the effort needed for future projects, it is essential to learn about the various tasks your team might have to undertake as part of requirements elicitation, analysis, specification, and validation. This knowledge will further help you understand how much time each task involves and aid in improving your project’s performance. It doesn’t necessarily mean that all activities need to be done on every venture but rather understanding what needs doing leads the way towards a successful outcome.

Don’t forget to share this post!