Finding software testing opportunities early with the Requirements Review Model

Software testing isn’t just about catching bugs, it’s about preventing them. Ever looked at a requirement and thought, "that seems fine." Then, weeks later, you watched the code for that requirement unravel into a bug report, hours of rework, or a very unhappy stakeholder? You are not alone. 

That’s why the Requirements Review Model (RRM) was created: to give testers and teams a simple and consistent review method. This helps to improve quality, even before any code is written. 

The RMM was created for the Ministry of Testing (MoT) Software Testing Essentials Certificate to teach those new to software testing about requirement reviews. MoT saw the value in sharing the model beyond the certificate to support testers and their teams. This supports their goal to advance the industry by any positive means possible. And so I wrote this article!

By using this model, you’ll learn how to:

• Find unclear or risky requirements before they can cause problems
• Ask the right questions to improve clarity and reduce assumptions 
• Find risks and testing opportunities to contribute towards higher quality software 

Because, let’s be honest, refining a requirement usually takes a few minutes, maybe an hour. Fixing a bug caused by a vague requirement? That’s a whole different story. Hours? Days? It certainly will take more time than improving the requirement. Generally, the further along the development lifecycle bugs are found, the more costly they are to address. 

The requirements review model (RRM) at a glance

The model follows four steps:

1. Start – read with curiosity

Before diving into the details, understand the context. What problem is this requirement trying to solve? Who is affected? If you don’t know the "why," you can’t test deeply or with empathy for the users.

Read the requirement with your tester mindset activated. 

• What stands out? 
• What assumptions does it make? 
• Does anything feel too simplistic? 
• Are there any words that are vague, like "could" or "should"?
• Is the scope of the requirement well defined and understood? 

2. Spot – identify gaps, risks and testing opportunities 

Now, dig deeper. What’s missing? What could go wrong?

• Consider different user perspectives and needs: 
  • The happy path is easy, but what about the sad path or potential edge cases? 
  • How would a new user, an impatient user, or a malicious user interact with it? 
• Look for risks and constraints
• Ask questions like: 
  • What could break?
  • Can a user reuse an old password?
  • Is there a limit on password reset attempts to prevent abuse?
  • What security measures are in place for password resets?
  • What about performance, compliance, technical limitations? 

3. Turn – create scenarios and design tests 

Take those questions, risks, and ideas, and turn them into scenarios and tests. 

• What can we try? 
• What tests can we design? 
• What test charters can we create?
• Do we have the right capabilities to execute our tests? 

4. Apply – take action

Testing isn’t a solo effort. Take what you’ve learned and put it into action:

• Raise questions in refinement sessions
• Suggest changes before development starts
• Align your testing strategy based on what you uncover

Pull in developers, product managers, and stakeholders to share ideas. Better questions lead to better requirements.

Using the requirements review model in real situations

This isn’t just theory. Here’s how you actually apply it:

Understand the context

What’s the problem that this requirement is intended to solve? Who’s affected? If you don’t know the "why," you’re testing in the dark. 

Example: "Users can upload profile pictures." Why is this feature needed? Is it for personalisation? For identification? The purpose of the requirement affects how strict or flexible the rules should be.

Spot the ambiguities

Vague requirements lead to vague implementations.

"The system should allow high-quality images."

Cool. But what is the maximum image quality? What is the maximum file size? 

Challenge vague language before it causes real problems.

Think like users

The happy path is easy. What about edge cases?

• What if a user uploads a huge file?
• What if they are using a keyboard?
• What if a user with a slow connection tries to upload a file?
• What if someone tries to upload something malicious?  

Look for risks and constraints

Consider if the requirement adds or mitigates risk. Assess if there are any rules associated with it that need testing. 

• Should there be content moderation?
• What happens if the server runs out of storage?
• Can users delete or change their profile pictures?

Validate through collaboration

Don’t just guess. Pull in developers, product managers, and stakeholders. Better questions lead to better requirements.

If a requirement says, "Users can upload images up to 5MB in size", check with the team:

• Is 5MB too big or too small?
• Should we optimise images for performance?
• Do we need a fallback if the upload fails?

This model turns vague requirements into well-tested features before a single line of code is written.

Common challenges to thorough requirements review  

"There’s no time for this."

You don’t have time not to review. It’s faster to clarify a requirement now than to fix a bug later.

"The requirement looks fine."

Fine for whom? If one person interprets the requirement differently from the next person, it’s not clear.

"Testers don’t own the requirements."

True, but you play a key role in spotting risks. Clear requirements lead to better tests. Better tests lead to better coverage. Better coverage prevents production issues.

"Developers will figure it out."

Maybe. Or, maybe they’ll assume something that causes an issue down the line. Why leave it to chance?

To sum up 

Testing can start before development begins. You don’t need to wait for code to start testing. The Requirements Review Model can help you:

• Find issues before they become bugs
• Save time by preventing costly rework
• Improve collaboration and stimulate better questions

Next time you receive a new requirement, try applying the steps in the requirement review model and see what you uncover. The earlier you catch problems, the smoother development (and testing) will be. 

For more information 

• Learn to do requirement review better, MoT Club post by @amacormack
• Reviewing Requirements Documents, Bob Salmon
• Best Practices QA Managers Should Implement When Reviewing Requirements, Ajay Balamurugadas
• How do you manage testing ambiguity? - LinkedIn community article 
• What are the best practices for dealing with ambiguous or incomplete requirements and specifications? - LinkedIn community article