Write Version 1 of the Requirements Review

Understand What a Requirements Review Is

Imagine a flame under a glass dome: it’s running out of air. It fades and eventually goes out.

Remove the dome, and it comes back to life brightening its surroundings and flickering gently. Now replace that flame with a requirement, and the dome with a question. That’s the perfect illustration of what happens when you question a requirement. A requirement cannot be considered valid as long as uncertainty hangs over it.

In an agile environment, teams are small and communication flows easily. You’ll be tempted to ask questions verbally, on the spot.

The advice I can give you is: write everything down.

The goal is to keep a record of what you’ve questioned—material you can reuse later in discussions, follow-up work, or even project debriefs.

This document has several purposes, including:

• Facilitating collaboration: It encourages dialogue across team members, helping them share ideas and work together to improve requirements.

• Stakeholder alignment: It ensures everyone has the same understanding. This avoids misunderstandings or conflicting interpretations and keeps all parties aligned.

• Documenting decisions: It offers a way to document decisions made about requirements, track how they evolve over time, and maintain a history of changes.

You can categorize your questions based on criticality, for example using the criticality of the related feature or requirement:

• Critical: full blocker—prevents understanding.

• Major: a significant doubt but not blocking.

• Minor: a small comment (typo, etc.).

Write Your Notes

Time to put pen to paper!

When reviewing requirements, it’s essential to record all relevant observations to ensure the quality of the final product.

Here are some tips for writing your Notes:

• Be precise: clearly describe the problem or ambiguity you’ve identified.

• Give examples: whenever possible, support your comment with a concrete example.

• Suggest solutions: if you have improvement ideas, feel free to propose them.

• Prioritize: rank your notes based on their potential impact.

• Be constructive: stay objective and helpful. The purpose of the review is to improve the product—not to judge your teammates. Kindness is one of the best fuels for team progress.

• Use a tracking tool: to keep everything organized, use a project management or issue-tracking tool, or simply an Excel-type spreadsheet.

Here’s an example of how such a document can be structured:

Share Your Requirements Review

Once you’ve gathered your questions and remarks, you can share them with the appropriate stakeholders.

This can be done through:

• The Test team:

  • Start by sharing your review with your peers.

  • They may be able to answer some questions, and it will help them better understand the specifications.

• The Project team:

  • Then share your reflections with the wider team (Developers, PO, design office, etc.).

  • They’ve likely been working on the subject longer and may have deeper insight.

• The Business team:

  • Finally, you can share your questions with the business team, who will either have the answers or will go find or define them.

To help you navigate, here’s an example of what each team covers:

Remember: every project member has their own specialization. Developers tend to focus more on technical considerations, while testers prioritize functional behavior (without neglecting the technical side!).

Here’s another example: We were asked to add a search filter to an online beauty-products shop, based on skin type (dry, normal, oily).

• Developers added the filter using a dropdown list so users could select a skin type.

• Technically, they followed the specifications.

• But functionally, some products applied to multiple skin types. With the initial implementation, a product appeared in only one filter—potentially misleading customers.

After discussion, we found a proper solution.

Over to You!

Context

You’re becoming more familiar with the specifications. However, you’ve noticed that some elements lack clarity—or are even missing!

Shine a light on these grey areas to clear them up and remove any doubts.

Instructions

Let’s return to the specifications and the analysis you’ve already carried out.

Your task is to ask the questions and write the Notes needed to remove ambiguities:

• write your requirements review;

• write an email to share the key information from your review with all stakeholders.

Summary

• This document has several goals: to facilitate collaboration, align stakeholders, and document decisions.

• Use an Excel-type spreadsheet format to record your Notes.

• Ensure your feedback is clear, precise, and concise.

• Share your document internally with the Test or Agile team before distributing it more widely.

• Stay kind and constructive in your feedback.

You’ve highlighted all the grey areas you identified. Now it’s time to wait for customer feedback so you can complete your document and confirm your level of understanding.