Prepping Your Requirements For Primetime: Validating Requirements

In parts one and two of this series, I discussed how confirming elicitation results and verifying requirements act as gates during the vetting process to ensure that your requirements are ready to be used by the rest of the project team. In this installment, we examine the last gate: requirements validation.

By this time, we should be confident we have fully understood the business problem we are solving for and closed any gaps in our information. We have written requirements in whatever way is appropriate for our project and are confident the project team can use them to build an appropriate solution.

Now we want to look at how well the requirements and their designs contribute to the overall value of the solution. To do that, we need an objective way to measure the value a requirement offers against the overall value we expect an initiative to deliver. As circumstances change throughout the life of a project, the value of any given requirement may also increase or decrease, so requirements validation may happen more than once during a project.

To begin, we need to know how much the business problem or opportunity is worth. Let’s suppose a business estimates inefficiencies in their purchase order approval process have cost the company $50,000 over the last 4 years. They want to reduce the cost of these delays with a solution that saves them $75,000 over the next 5 years.

For simplicity, let’s assume one project will implement a solution that achieves that outcome. You have been working to identify the right combination of requirements that lead to a solution that will meet or exceed that $75,000 benchmark. We call this the potential value of the solution, or the maximum value it would provide under ideal circumstances. We can use this as one benchmark to measure how well each requirement increases or decreases the solution’s potential value.

Techniques like financial analysis, risk analysis and management, stakeholder reviews and even item tracking can all influence the requirements validation process. If conditions change that make a requirement too costly or won’t add much value to the project you and the project team can reevaluate it to determine whether the requirement should be re-prioritized or even dropped, and what effect that would have on the rest of the project.

Let’s return to the project we referenced previously. Through your elicitation, you discovered users have to log in two different places during the purchase order approval process to complete it. Therefore, one requirement states the user should only have to log in one time. You calculate this will save 30 seconds per purchase order and tie it to a dollar amount that over 5 years adds up to savings of $10,000. To accomplish that, however, the project also has to make improvements to your company’s single sign-on policies that will cost $8,000 to implement. The requirement may save $10,000 in time spent by the users, but if you spend $8,000 in infrastructure updates to make it happen the real contribution is only $2,000 over the life of the solution. You also know that while leaving the two-step process in place is not a user-friendly experience, it isn’t strictly necessary to achieve the overall objectives of the project.

Should you drop the requirement? That depends. The requirement does add value, it just may not add as much value as something else. Knowing this can help with prioritizing which features are rolled out first, or whether that requirement gets dropped from the project all together. As compared to other features or enhancements, it might simply be too expensive to pursue.

When we test our requirements at each of the three gates, we are drawing a direct line from the stated business need that kicked off the project to the solution that addresses it in a way that allows us to assess how well we meet that need. As conditions change, our requirements might change, and things that were relevant and important yesterday may not be today.

Learn more in part one and two of this blog series!

Tamara Copple