Best Practices QA Managers Should Implement When Reviewing Requirements

Successful projects are built on the foundation of precise requirements and the ability of teams to interpret, analyze, and review requirement documents. There are many customers who find it difficult to express their thoughts in words. Even if they are able to express themselves, there are many complexities that can arise due to the number of people involved, the skills of different team members, and the complexity of the domain. Without understanding the requirement documents (yes, there is a distinction between the requirements and the requirement documents), we would be on the path to making costly mistakes. Many projects suffered losses when the teams discovered the differences between intentions and implementation during the first demo.

Let us examine a few good practices that QA managers and the teams can follow to ensure that we have maximized our chances of understanding the requirements in detail.

Beware of the Difference Between Map vs. Territory

A model is a representation of an idea. A map is a representation of a territory but is not the territory. A requirement document is a representation of a requirement but is not the final product. Many teams base their understanding and test design based on the documents. There is nothing wrong with that if you are also using the product and are aware of the current reality. In software, the product is closer to reality than a document. If discussions are happening about the feature and the requirements are modified, ensure that it is documented and circulated with all stakeholders. People leave projects, priorities change, and soon the data might be lost.

Be in Touch With the Person Who Updates

Know who created the first document, and if possible, get in touch with that person. Also, understand who else updates it. Figure out a way to be notified when the document also goes through an update. Try not to be “lost in translation” as more and more people are involved in translating the requirements into requirement documents. If you have ever played the Telephone game, you will understand what can go wrong when the information chain is long. Keeping track of the changes and the reasons for the decisions is also recommended. While you can accept ad hoc changes, make it a habit to update the document. This process will help you scale faster and have a robust system.

Apply Heuristics to Review

One such heuristic is: “Mary had a little lamb” – While emphasizing each word, a new perspective emerges. Similarly, pick the critical statements from the document and apply the heuristic. Let me explain it with an example:

Assume that one of the lines in the requirement document reads: “A user can upload 50 files”. Applying the heuristic, we will start by emphasizing the first phrase – A user.

A user

• Is it a specific user or any user?
• Who is a user here?
• Are there any special permissions enabled for this user?
  Can upload
• Can? Or must?
• Only upload? What about downloading?
• Upload where?
• Any expiry?
• Mechanism of uploading?
• UI, API, Backend?

Can upload

• Can? Or must?
• Only upload? What about downloading?
• Upload where?
• Any expiry?
• Mechanism of uploading?
• UI, API, Backend?

50 files 

• All at once
• One at a time?
• File types?
• File sizes?
• Why 50?
• What will happen if we upload less than 50?
• What will happen if we upload more than 50?

It is possible to generate multiple ideas by changing the focus on words. One could also replace each word with its synonym, as highlighted in the book: “Are your lights on?” and dive deep until everyone understands the problem statement/requirement line.

Active Reading

When analyzing the requirements, dig deep. I prefer to use different colored pens and highlight the following for each sentence. Is it a:

• Note (N): Something to be paid attention to.
• Question (Q): To ask the stakeholders
• Test Idea (I): An idea to test the product
• Test Data (D): Could be potentially used in a test
• Bug (B): Looks contradictory to earlier sections and most probably is a bug

Once the document is marked with the notations, we collate all the N, Q, I, D, and B separately and take appropriate actions. This activity helps identify important gaps early in the cycle. Some of the contradictions are discovered even before the product is fully developed.

Ask Questions

Usually, requirement meetings are one-sided, with the product owner explaining the features and the business impact generated. While most teams are not usually prepared for these meetings, you can take the help of a few checklists such as Context Free Questions and Critical Thinking Cheatsheet. The teams also need to be ready with the next logical questions. When more and more questions are answered in the initial meetings, there is less rework and a better understanding of the product and the project.