How-to Requirement Reviews
Reviews! Either the safety net you always wanted or the hammer that knocks your teeth out. In this blog post we will explain how to conduct a valuable, effective and pleasant requirement review.
The importance of reviews
Reviewing requirements is an essential part of quality assurance. A review is so much more than laying your hand on a document while nodding with an intense look on your face that says: “I approve this”. We often see, hear and experience requirement review sessions that are either a waste of resources, or worse resemble a battlefield. A battlefield on which opinions and characters clash. Let me assure you it doesn’t have to be this way. Requirement reviews can rapidly become a welcome and effective process in your organization. Here is how:
Roles and responsibilities.
Any process needs the who does what outline. For a successful requirements review you need the following roles:
- The author. The author writes the requirements and stays responsible for the requirements until the end of the review process.
- The lead-reviewer. The lead-reviewer manages the review-process and people involved. In addition, the lead-reviewer can act as a main decision maker.
- Reviewer. The reviewer carries out the actual review of the author’s requirements.
Just to clarify, the author cannot be a reviewer withing the same review process. Adjust the roles and responsibilities to your organization, but for the following steps we stick to roles listed above. Let’s dive into the three-step review process.
Step 1: Lead-Reviewer, Prepare
In Dutch there is a saying “goed begin is het halve werk” which translates to “well begun is half done”. An idiom that holds true for reviews too. A well prepared review session safes time, energy and is a lot more effective than a roughly gathered up piece of text that someone wants you to “take a look at it”. Hence as the lead-reviewer do the following:
- Select the newly written requirements for review carefully and sparsely. Make sure the requirements are grouped in a logical manner, so that they are related to another. There is no magical minimal or maximum number of requirements that should be selected for review. Not too much or too few, but enough that the effort of a review is acceptable and no requirement is logically missing. (hint: use scenarios or state transition diagrams to group requirements into coherent chunks of functionality or to discover missing requirements, but this is a separate topic).
- Select the reviewers, yes plural! Select various people from your organization. People that are experts in different domains. What domains you might ask? Product-Stakeholders, Testing or Product Quality Control are the usual suspects, but also the Engineers that are entrusted with implementing the requirements are all excellent candidates.
Why Testing? Testability of requirements is an essential quality aspects and requires domain knowledge and knowledge of testing strategies. Having a dedicated reviewer that analyzes requirement from a testing perspective is highly beneficial. Checking if the requirement is measurable is one example of those benefits. - Plan the Review Session. Pick a date and deadline, then invite the reviewers. In the review invitation you explicitly state that the reviewers are requested to perform the review before the deadline.
Step 2: Reviewer, Perform Review
Let it be said: “thee shalt perf’rm thy reviews systematically” (Shakespearean for you shall preform your reviews systematically). I cannot stress this enough! No seriously, if there is one problem we identify over and over again it is that reviewers do not adopt a systematic approach. Adopting and constantly applying a systematic requirement reviewing process is your number one priority as of today. Which kind, brand, serial number or species of process you choose to adopt, is of secondary importance. The main thing is to adopt A process. Here is a basic process just to get you started:
2.0: Plan and take your time!
Doing a requirement review while your colleague is giving a presentation is not the way to go. Ensure you have time blocked for a review.
2.1: Get the bigger picture
Read through all the requirements and build a mental map. Understand the bigger picture: what are the use cases and their related functions, are there quality requirements for those functions. Take the following example requirement (EARS Syntax off course):
(REQ-A) If a defective component is detected, the system shall notify the operator.
As a reviewer I am triggered by words like “detected” and “notify”. Why? I want to see the requirements that support those words. Meaning, I either know -if not verify- that the system is already possesses such functionality, or I look for such functionality in the requirements that are currently under my review. I’ll look for requirements such as:
(REQ-?) The system shall detect defective components
(REQ-?) The system shall show visual textual messages to the operator.
(REQ-?) The system shall send acoustic signals to the operator.
Not the best requirements, but they do portray the kind of functionality that supports the requirement (REQ-A). If I find the supporting requirements in either the existing system or in the requirements that I have to review, I make a mental or actual note. During the time I make a mental map of the requirements and their relationships, I am constantly making sure that nothing is missing from the bigger picture. If I do find that requirements are missing a note this in my review. Missing requirements are the biggest threat to the success of a system under development!
The same can be done for quality requirements.
2.2: Review each requirement on its own:
- Is the requirement unambiguous and clear. If you have to read the requirement more than once in order to fully understand it, it is highly likely that the requirement is ambiguous or unclear.
- Is the requirement compliant with your company’s quality rules (you really should have those!). Maybe your company has a requirement-syntax, or use other guidelines such as the INCOSE guidelines for writing good requirements.
- Read the requirement from an explicit role-based perspective, by answering specific questions, For example: As a tester, can I create a test for this requirement? Or, as a engineering, can I make a design for this requirement? This is called perspective based reading This technique catches 35% more flaws in requirements than ad hoc reading [1]. That is like … a lot more! So do it, check out this paper for more information on perspective-based reading.
2.3 Review the requirements as a whole:
Other than the bigger picture, where we focused on getting a metal map of all the requirements, we now focus on how the requirements relate to each other such as:
- Do requirements contradict each other? Contradicting requirement cannot be implemented, and often indicate a misunderstanding of stakeholder needs.
- Are there semantically duplicated requirements? Duplicates are bad, causing extra work and a lot more trouble, see here for more information.
- Are any requirements missing? Missing requirements are the biggest risk to your project!The process of requirements engineering it is not a time to be brave, fear the unknown. Identifying missing requirements or stakeholders is an essential goal of any requirement review.
2.4 Check your comments and consistency
You are not done yet. Go trough all your review comments and assure that they are constructive and consistent. Your may find that after a long review session your comment style or level of critique changes. Stay positive, polite and consistent.
Overall comments regarding the review process
Always go through all the steps, even if you find a flaw or you are not happy with a requirement; make a note and continue. You want to present the author with the complete results of your review. This shows respect to the author and increases the efficiency of the entire requirement authoring process. Hence, do not stop the moment you find a flaw!
If you diligently preform these steps, the quality of your requirement reviews will rise. Modify, add or remove steps to fully tailor the review process to your situation. If you need any help, I am happy to assist!
Step 3: Lead-Reviewer, wrap up the review.
All the reviewers did their thing, submitted their verdict and now you can finally act like a roman emperor and point you thump up or down! No, that is not how this process works! The author must receive all the review commands in a structured format. Therefore, combine similar review comments and structure them for the author. In addition, instruct the author on how to proceed. Perhaps some requirement has been criticized by multiple reviewers, indicating that more than just an adjustment of the requirement is required. In that case instruct the author to meet with the reviewers and create consensus. But in any case, regardless of the kind of review comments, instruct the author to go trough the review-comments and adjust the requirements if necessary.
This all sounds like a lot of work, and you are right! But, doing this quality assurance now is a lot cheaper than fixing mistakes in production later.
TL;DR
Requirement reviewers are an essential tool for finding errors or holes in your product specification. We often see that reviews are done in an ad hoc way. This ad hoc approach is detrimental to the effectiveness of the entire requirement review process.
Use a systematic approach to conduct requirement review.
- Plan the review session and carefully select the requirements for review
- Select the appropriate reviewers from different domains within your organization.
- Each reviewer systematically reviews all requirements
- After the review is done, the author must create consensus among reviewers.
A few final words. This summary doesn’t do the process justice. Reviews are essential but also a cultural aspect of the company culture towards quality. Please do not consider reviews a formality, but rather a way of supporting your colleagues and having their back!
