Risk-based requirement prioritization — save project money, time and effort

Risk-based prioritization (RBP) is about identifying requirement risks, understanding testing needs and ranking requirements in line with business priorities.

Testing has its own set of risks including ambiguous requirements, test environments, unavailability and not having proper stubs or automation tools for testing. Crucially, if you don’t address a particular risk, it could become a costly issue in production.

RBP can streamline your entire software development process if carried out efficiently and effectively. It can also save money diverted to testing bugs you could have captured earlier in the software development lifecycle (SDLC).

Fix the risk before it becomes a production issue

The entire team is responsible for developing crystal clear requirements at the beginning of your project. If team members don’t understand a requirement, it will cause defects in production. It’s extremely expensive to fix anything in production. After all, you’ll need to stop applications, risking losing reputation points because your system is down (imagine your bank system failing for 5 minutes just when you want to make an important transaction).

The cost of fixing defects increases exponentially if you allow them to propagate from one phase to another. Let’s say a requirement issue surfaces in the design phase; it would be much timelier and more cost-effective to contain it in the requirements phase itself.

It pays to know what’s what

If programmers, testers and managers know precisely what they’ll be implementing as a team, there will be very few change requests, reducing time-to-market and saving a great deal of money and effort. Clearly, if your requirements are frozen with next to no changes, you can stick to the project scope and schedule, and deliver on time or even early.

The challenge is whether you can test, prioritize and categorize your requirements to optimize and test development.

RBP is a process that enables you to clarify, redefine and rank your requirements according to importance, even before you begin development and testing. This article looks at identifying non-testable requirements and making them testable, plus the practical benefits of risk-based prioritization.

Are your requirements testable?

You rarely encounter project supervisors or test managers at pains to understand whether your requirements can be tested or reviewed as a team exercise. It’s one of test management’s critical challenges and a threat to your entire testing process.

These five characteristics help team members understand and interpret requirements consistently.

So, when you’re in the sprint planning or analysis phase, business analysts gather requirements so the testing team can go through the lot and check the testing criteria. If you haven’t fully identified your testing team, make sure you have a test manager, plus some test engineers and developers who can work on clarification.

Making requirements testable

If you see that you can’t test some of your requirements, try to make them testable by applying risk-based prioritization. For instance, your requirement definition might say, “The application should show a status message or disconnect a user if there is no activity for about 60 seconds.”

The statement raises the following questions:

• Which application are we talking about?
• Should it show a status message, disconnect a user, or both?
• If the interval is ‘about 60 seconds’, is it okay to disconnect a user if there’s no activity for 50 seconds?

You cannot test ambiguous requirements. Inevitably, different people interpret things differently. Developers might implement one thing, and testers test something else entirely. Then the resulting product will have little value and create no customer satisfaction. Consequently, you must make requirements crystal clear.

To make it testable, you have to work with your business analysts to clarify the ambiguities, update the requirements, and circulate the updated documentation throughout the team. Once you’ve completed this initial exercise, you can start the core process of risk-based prioritization.

The risk-based prioritization process

The three-step risk-based prioritization process:

1. Checks your requirements are testable. Earlier, we covered how to assess your requirements against the five testability principles and convert them into testable requirements.
2. Helps you understand what to test. Every requirement in the SDLC has an element of risk. Take “Change the font on your company’s website.” Even though this appears to be a straightforward requirement, it still carries a risk. Familiarize yourself with the steps needed to mitigate that risk.
3. Prioritizes requirements based on business criticality. This is the core element of risk-based prioritization.

Number two input parameters (impact and probability) for each requirement. “Impact” gauges the ramifications of your requirement failing in production. “Probability” indicates the chance of failure or errors creeping into production. These two parameters are generally rated from 1 to 3 (low-high).

Multiplying the impact and probability ratings together gives you the requirement risk scores (1-9). Having identified the risk scores, we divide your requirements into high-risk, medium-risk and low-risk requirements by setting up some guidelines as follows:

Parameters and the scoring model can vary depending on the company you’re working with.

The left table shows the guidelines set for requirements categorization. The table on the right shows permutations and combinations along with basic categories like high, medium and low.

The test manager consolidates all the inputs and circulates the results, detailing the number of high-, medium- and low-risk requirements as follows:

Based on these inputs the team starts working on development, testing and implementation.

Benefits of risk-based prioritization

In summary, risk-based prioritization helps:

• Identify untestable requirements and make them testable
• Focus on testing activities right from the analysis phase
• Keep all stakeholders up to date
• Identify critical requirements so you can increase their testing
• Communicate the quantifiable risks in your projects
• Optimize UAT by ignoring low-priority requirements (you’ll need business-team buy-in)
• Streamline your entire testing process

All three are interrelated, in terms of the sequence of change and the technologies involved. However, institutions can’t wait to complete each step in sequence, rather having to adopt hybrid solutions to progress on all fronts.

The bottom line

The risk-based prioritization testing process allows you to scrutinize requirements in the gathering phase. It enables you to focus on testing and minimizing defects that penetrate the system due to inaccurate requirements. At the same time, it helps you identify priorities and category requirements, and optimize your UAT. RBP provides a strong foundation for testing, automatically improving your development process quickly and with maximum business value.

Find out more about how Zoreza Global can help you streamline your software development process by visiting luxoft.com/capital-markets or contact us — we have many more insights to share with you.