Requirements Review – Why is It Important?

Blog Post

Our Business Analyst, Victoria Aleshko, would like to share her experience in setting up a clear and effective Requirements Review process on the project.

The idea of the project came to mind to our clients not so long after the global pandemic hit the world and they started realizing all the possible consequences.

Our clients came up with the idea to address mental health issues within Healthcare systems, as in large hospital systems workers carry a lot of emotional weight in their job every day and require some assistance in their day-to-day lives.

As this was an innovative idea and the client only investigated the approaches to creating such kind of the app, the requirements were changing constantly. This issue frequently leads to conflicting requirements in documentation, gaps, and incompleteness of requirements due to sometimes hectic changes. That is why we decided to introduce the Requirements Verification process and avoid any potential inaccuracies.

Requirements Verification Process

Requirements verification helps to find errors and point out other matters of concern in the requirement specification of system.

It is a well-known fact that one cannot neglect requirements review process. Even such a well-known bona fide requirements guru Karl Wiegers to a question:

“If someone said you could only perform a single quality practice on a software project, what would you choose?” -answers: ‘I’d pick peer reviews of requirements. I believe this the highest-leverage software quality technique we have available today.”

Even if it seems unobvious at a first glance, your project will only benefit from implementing a Requirements Review. Just give it a try, and you will not be able to say “No” to this practice going further!

The Start

At the very beginning of the project, we already knew that we are going to keep to the best practices of working with requirements, that is why we did not have a single doubt whether to introduce the process of Requirements Review or not. The team had welcomed the idea, PM and QA team leads have expressed their willingness to assist with setting up this process and we immediately started taking care of it.

The Process

There are quite a few different ways to establish peer requirements review process, but there is not a single one that will be a good fit for every project, and not a single method will guarantee the project success.

In the pre-pandemic times the idea about the perfect requirements review process used to be different. The most effective review process was a meeting where you gather all your stakeholders together and walk-through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project. But the world is changing fast, and we had to adapt to these changes.

Although we understood that in our case such approach might have worked, we realized it would not have been the most effective one. We decided to tap the expertise of the whole team (which is a lot!) to establish a clear, effective, and time-saving peer review process.

With the efforts of the whole team, we created a diagram and established the following process:

1. After requirements are ready and outlined in the Jira story – send the task from “Backlog” status – to “Ready for Review” and assign to QA Team Lead.

2. QA Team Lead will review the task and assign it to QA team member.

3. If after reviewing a task QA Team Member has any comments or concerns – they leave these in the Comments section for the appropriate Jira task and assign the task back to BA, sending it to “Backlog” status.

4. BA in their turn corrects all the inaccuracies and adds the missing scenarios. After that the task is sent back to “Ready for Review” status and is assigned to the QA team member who was reviewing the task.

5. Once there are no comments left – the task is sent to the “Reviewed” status by the QA team member, meaning that it is ready for Backlog Refinement with the team.

Useful tip

Before we even started implementing peer review process on the project, we agreed on the following: if the requirements need to have more than 3 cycles of review before QA team finally confirms they are reviewed (step 5 of the process above) – it means that process is not working as expected and something needs to be changed. It might be useful to ask one of the colleagues who is not involved in the Review process to take a fresh look at the situation. Sometimes it helps to understand why the process is not effective in this very case. Luckily, we did not have such cases while working on the project. We always managed to find common ground and if anything was not clear – we could always hop on a call and discuss all the questions, live and in person! It appeared to be much better approach than having endless correspondence. Just don’t forget to always document any verbal agreements.

Requirements review – how to make it right?

Based on our experience I would like to point out a few key success factors that can help you establish an effective review process on the project.

Get the support of your team

The lack of clear understanding why you would like to establish peer review process can lead to a record of failure. Take the time to educate your team on why the review process is so vitally important for the project. You need to make sure that your team members understand the importance of the requirements review process and are “on board” with your idea.

Make sure reviewer has enough technical background

We concluded that a peer who reviews the requirements needs to be tech-savvy. In this case it will be easier for them to find gaps in requirements as well as help your team to avoid functionality changes in future. When reviewer is still in doubt regarding technical part of the process, you can always reach out to dev team to clarify all the questions and come up with best implementation ideas.

Mutual respect and understanding

It is extremely important to take the right approach to the process and agree to only provide constructive criticism. You can easily offend your colleagues with a harsh word. This can lead to the conflicts in the team or even to the suspension of the review process. At the same time, you should avoid using a language too belabored and ornate (the kind of language that royals used in the 17th century :). Go straight to the point of your review, work on a numbered list of points that you would like to bring up to a discussion. You can even create 2 separate lists – one for questions and the other one for comments or points for improvement. Do not forget to provide a unique ID to each of your comments/questions, this way your colleagues will be able to easily refer to any of them when answering.

Share reviewer’s vision on how to make the changes

We also took it a step further. Not only did we take approach to indicate points for improvement in a polite manner, but we also agreed that the reviewer will provide their idea for improvements. This practice allowed some space for an open discussion, the reviewer was also able to share their knowledge and their view of the situation.

There is no such thing as “too much communication”

Although one may believe that they are communicating their message very well and that their instructions are clear and succinct – multiple researches show that it is not always the case. Some important parts of your message might be missed when you put your thoughts in the written form. Never hesitate to jump on a call and clarify all the unclear moments. Also, never hesitate before asking your colleague whether any further explanation is needed of what you have just said/written. It also helps to set a warm tone for the conversation.

Be deliberate about following the exact process that you established

This one is especially important at the very start of implementing peer review process (or any new process overall). It might seem easier to avoid certain steps or just correct some errors on the reviewer’s end, however it can disrupt the review process that you were so carefully putting up together. The process can cease to exist. It would be great to have a person who would advocate for the process and won’t let anyone step away from it. They will always remind the team why it was decided to commit to the Requirements review process and how important it is.

Set the acceptable level of detail

Try to find the fine line between the acceptable level of detail and the amount of effort it will take you team to implement requirements. At the very beginning of the project, we set up the acceptable level of quality and detail, documented it and were always using this documentation as a reference when discussing controversial moments. Otherwise, the team could have been exhausted with long discussions regarding all possible edge cases.


A few months after implementing the process of requirements peer review, we can tell that the quality of requirements has improved, we spend less time clarifying the requirements and we also noticed that the level of requirements coverage has increased.

Feedbacks from the Team Members

Project manager:

“Well-structured process of requirements review is quite time-consuming and has a great impact on the project planning. Firstly, if it has been decided to set up a review process on the project a PM should add an extra 0.5-1 effort additionally to the team, because the process requires some extra-time spent by the QA team. Secondly, when establishing a review process, a PM should plan all the project events accordingly. So that all the reviewed tasks were smoothly transitioned to the sprint and those tasks that were not reviewed yet hold off for later.”

Mobile developer:

“The review process seems ok; I am happy with it. I only regret not having a designer in the team, so no one to argue with. But there is nothing to be done about it.”

Backend Developer:

“If we are talking regarding the processes on the project in general – I am happy with the way it is currently set up, I enjoy working on the project. I like the Backend Team a lot, we have a cool team lead, BAs are great to work with – I get answers to all my questions, the fact that all the change requests are handled in the appropriate manner makes our work lives better. I think we hit it off as a team and I was able to find approach to everyone. There are les questions during the sprint, no stress situations at work, it is all good!”

QA Team Lead:

  • “Many clarifying questions between BAs and a client were resolved before the start of development process. Thus, all the requirement gaps were fully planned, it affected the tasks backlog in a positive way.
  • Requirements clarification questions have formed client’s understanding of the project. This allowed us to share all the possible restrictions before the development has started.
  • Development and QA teams received a set of requirements that were well-designed from the business and user perspective (client + BA), as well as the technical perspective (development + QA). In the end, splitting implementation into technical tasks, test-cases, user scenarios was conducted with the utmost understanding of project tasks by all stakeholders./li>
  • Understanding the set of tasks as well as their complexity ensured predictability with high scheduling accuracy, budget utilization, and outsourced consultants.
  • In the requirements review, the business analysis team considered a number of typical situations that arise during the operation of the Product and developed a set of scenarios for the system performance. These scripts will be used again in future projects – thus, the outlook and technical expertise of the business analysis team have been increased.
  • In the process of requirements review and development, the project team has synchronized technical dictionaries, which will help to communicate more effectively in the future – all the parties involved will understand each other very well.
  • As a result of establishing and fine-tuning the process, company has increased its technical expertise and made a well-informed decision to extend the practice of checking requirements to other projects.”

We use cookies to optimise site functionality and enhance your experience.

I agree