Several factors impact the average time to gather software requirements. For example, the more complex a project, the more time it’ll take. Similarly, stakeholder participation is also a factor. Without considering these factors, there is no way to determine the average time to gather software requirements. Therefore, this article does not give a fixed figure, rather it takes describes the factors that influence the average time to gather software requirements. It also lists some tips for each factor. After reading this article, you’ll be able to create more accurate estimates for the gathering software requirements activity.
Let’s start from the source of software requirements – client stakeholders.
Since requirements essentially come from client stakeholders, it’s obvious that their participation is mandatory to gather software
requirements. The level of involvement of client stakeholders during this activity should be very high. This collaborative approach to gathering software requirements ensures a higher degree of accuracy and ownership. However, before engaging client stakeholders, make sure you have the right ones onboard. Use tools such as the Salient Model to determine which stakeholders can provide rich information.
Tip: To encourage active stakeholder participation, develop trust and make stakeholders understand why their participation is a necessity.
To understand this better, think about all the things that could go wrong when gathering software requirements without active client stakeholder participation. The level of client stakeholders participation dictates the average time to gather software requirements. There may be instances when some stakeholders aren’t available or when multiple gathering software requirements sessions are required. The schedule needs to accommodate this possibility! This is especially true for complex projects. Let’s look at how project complexity can influence the average time to gather software requirements.
Image Credit: SXC
Project complexity is a very subjective term and prone to several interpretations. To reduce the misunderstanding, in this section, the
term project complexity refers to level of difficulty in understanding how to achieve the project objectives. In complex projects, the ability to gather clear and accurate requirements is difficult because the requirements are vague and may even be evolving. To improve the accuracy of software requirements, you may need to create a prototype, storyboards, and modeling. In addition, some projects may require multiple gathering software requirements sessions.
For example, suppose you are planning for software that when deployed will reduce the time taken to checkout by 30% and increase the overall sales (online or product software) by 20%. To meet these objectives, during the gathering software requirements phase, you’d probably conduct user testing of the existing system. In addition, to better understand the audience, you might have interviews and observations. To increase sales, the overall business strategy would have to be looked at. Some factors you’d consider include product portfolio, the competition, the current unique selling points, and the advertising strategy. You might even develop user surveys asking the audience what exactly they like and don’t like. Or, if there are multiple paths to a solution, you may use decision trees. By using this holistic approach, a higher probability of success in meeting the project objectives is possible.
As you can see, project complexity can significantly increase or decrease the average time to gather software requirements.
Image Credit: SXC
What About Software Requirements Accuracy!
So far in this article, I’ve focused more on the average time to gather software requirements, than on the accuracy of gathering software requirements. The factors discussed in this article also influence the accuracy. For example, by making client stakeholders actively participate in the gathering software requirements activity ensures you have the requirements from the source. This collaborative approach makes it easier to get sign-offs and decreases the overall project risk. As a matter of fact, during this activity, many project risks will also get revealed. If a client stakeholder does not want to participate, she may not participate or provide timely feedback for other critical milestones, such as design.
As a project manager, your first priority should be to ensure software requirements accuracy and not to reduce the average time to gather software requirements. This is because design and implementation are dependent on the requirements. If they are inaccurate, your worst nightmare would be a reality. Needless to say, the project objectives will definitely not be met!
Tip: Never fast track or compress the schedule during the software requirements phase.