INTRODUCTION

Requirements authoring is a tedious process.

An inevitable effect of complex and tedious work is the possibility of introducing errors along the way. This is where the requirements review process comes in.

A requirements review is a structured process where key stakeholders from the user groups and the project team walk through the requirements document line-by-line. They analyze the requirements looking for problems to ensure the requirements are complete, correct, clear, and represent an accurate and mutual understanding among all of the stakeholders. Although simple, the requirements review is highly valuable. The process is typically a manual one, but using automation, such as QVscribe, both during initial authoring and during the review can streamline it significantly. For example, companies like RCAF used QVscribe to ensure requirements had at least a 4 out of 5 quality score before submitting them for review, reducing review time by over 50%.

QVscribe harnesses Natural Language Processing to proactively check for compliance of the best requirements analysis tactics identified by associations such as INCOSE and leading industry experts. Ensuring requirements have a high-quality score before beginning the review process ensures teams can focus on content, rather than syntax.

WHY REQUIREMENTS REVIEWS ARE IMPORTANT

Well-written requirements form the foundation of a successful project. The requirements review is an opportunity to check the requirements document for errors and omissions and confirm that the overall quality of the requirements is acceptable before the project proceeds. It is also one final opportunity to communicate and confirm project requirements with all stakeholders.

While stakeholders may complain that they are too busy to attend, requirements reviews are crucial. Simply sending the document out for review will likely lead to rubber stamping by busy people, although a formal signoff can still happen following the requirements review meeting. Since some important stakeholders may not even really know what they are looking at, they need guidance to effectively understand the requirements.

There are many benefits of a face-to-face review meeting.

• The discussion among the broader team to validate the clarity and accuracy of requirements is likely to be higher quality than individuals independently reviewing the requirements document.
• It ties the web of requirements together in everyone’s minds as they discuss the complete requirements in context.
• Stakeholders align around the scope and confirm the requirements are clear enough that they all interpret them the same way. They also gain an understanding of how the requirements affect them.
• Stakeholders who may not be knowledgeable about requirements gathering, authoring, and reviewing will be educated in the process. This may not be important for the project at hand, but it facilitates long-term knowledge transfer and retention.

Some benefits can be enhanced both before and during the review by tools like QVscribe:

• Improving the quality of requirements
• Finding redundancies and similarities between requirements
• Improving the consistency of the requirements
• Generate configurable, shareable reports

STEPS IN THE REVIEW PROCESS

1. Decide how to conduct the review.

There are several things to consider as you decide how the review will be conducted.

Will the review be formal or informal? Depending on project complexity, stakeholder maturity, and organizational culture, the review process can be conducted either formally or informally. In a formal review, the project team steps through each requirement with the stakeholders and explains the implications one-by-one. An informal review is more relaxed in its depth and is generally better suited to stakeholders who are very familiar with the process.

Will the review be broad or focused? In a broad review, the entire team reviews the entire document. A broad review is usually best for smaller documents. In a focused review, different parts of the document are distributed among different teams, so the review is a less overwhelming task. This approach can also be useful if different stakeholders are affected by different parts of the requirements document. Of course, it is easier to miss the big picture and potentially conflicting requirements when the review is divided. You will likely still want a broad review of the entire document following focused reviews, but it will go faster knowing that the details have already been reviewed. A QVscribe report can give you an added level of confidence in the cohesiveness of large requirements documents.

Will the review be onsite or offsite? Consider holding the review meeting offsite. While this likely involves the cost of renting meeting space and can be less convenient, it offers the opportunity for participants to be more focused. They will not have the ability to wander off to their desks or to other meetings or to be caught in the hallway by other employees with questions.

Will the review be face-to-face or involve remote meetings? Without a doubt, face-to-face meetings are always better. But there are almost certainly stakeholders distributed around the country – or even around the world. If remote meetings are the only option, check that necessary communication and screen sharing technology is available and functions well. One option to consider for dispersed participants is to meet face-to-face in an airport hub city. Although this means everyone must travel, it also means all participants can get a non-stop flight. Many airports even have meeting space available for rental right at the airport.

2. Identify the participants and schedule the meeting.

It is essential to identify the right participants for the review. Take the time to do this well. Look back at your stakeholder register. Assuming you have kept this current throughout the project, it will make it easy to generate your participant list and ensure the proper cross-section of stakeholders.

Consider how best to get representation from each department or function, from the shop floor users to management, and one personality type to another. Be sure there are people with different skills, backgrounds, and knowledge in the review. Wide representation is best so as many stakeholders as possible are involved and no viewpoint or input is missed.

In most organizations, it is difficult to find a time when all participants are available for a lengthy review. Schedule the meeting as far in advance as possible to allow all key stakeholders to attend.

As mentioned at the outset of this article, requirements reviews can be tedious. Schedule sufficient time for the review. For all but the smallest projects, it may require several days of work. You may want to schedule a series of half-day meetings rather than full days to help maintain energy and focus among the participants and arrange the agenda to respect natural energy cycles and tackle the hardest parts early in the day.

3. Set the stage

After the meeting time is set, distribute copies of the requirements document as pre-work far enough ahead of the meeting to allow participants to review the document and come prepared. Instruct them to mark up the document as needed with questions and notes. The requirements document should include the output from QVscribe’s report function so that all requirements are listed and potential quality issues already noted.

Along with the requirements document, distribute the agenda for the meeting in advance. This lets everyone know how the review will be conducted so they can come prepared and know what their role in the review is. Remind participants of the business objectives to help them focus on the project’s “why.”

It is helpful to set ground rules for the review meeting ahead of time. This can include things such as:

• Come prepared, having read the requirements document and making notes of any proposed corrections, changes, or questions.
• Full participation and presence in the meeting is expected. Phones are silenced and laptops are closed except when being used for the review. Remind people that they have been invited for a reason and their input is too important to the project for them to not be fully engaged in the review.

Inevitably, there will be some introverts and some extraverts in the meeting. Let introverts know they are expected to speak up, and extraverts know they cannot dominate the conversation.

4. Conduct the review

Start the meeting by reminding the attendees of the ground rules. Projecting the document on the screen will keep everyone together on the particular issue being reviewed, but distributing hard copies of the documents – ideally by using the QVscribe reporting functionality – is important too. This allows them to see the bigger picture and refer to other sections of the document as needed. The quality scores assigned to each requirement by QVscribe will help drive the discussion to the more problematic areas of the document, and the term summary will ensure everyone is speaking the same language.

Begin walking through the requirements document section by section, requirement by requirement, line by line. Using QVscribe live on-screen during this process helps to flag new conflicts and issues during the process. Remember to log any changes for traceability purposes.

Keep the following in mind as you review each requirement.

• Is each requirement testable as written? Are there objective pass/fail criteria?
• Are the requirements correct? Do they define the actual needs and solutions
  the stakeholders require?
• Are the requirements complete? Are business and software requirements met? Do they support the business and project objectives? Are there missing requirements?
• Are the requirements clear and unambiguous? Does everyone understand them? Is there only one way to interpret them? Are they short and concise? Do they use a consistent and standard format, such as EARS?
• Do the requirements conform to all relevant company or industry structural mandates? QVscribe is configurable to take these specifics into account.
• Are there redundant requirements? A QVscribe duplicate check and similarity assessment can be especially helpful here.
• Are there unnecessary requirements?
• Are the requirements consistent? Are there requirements that contradict or are mutually exclusive? Are all terms and units consistent?
• Are the requirements feasible? Can they realistically be implemented using available technology, on time, and on budget?
• Are the requirements adaptable to future needs?
• Are the requirements traceable?

As the team reviews each requirement, they must address conflicts, contradictions, errors, and omissions live or record them for future action.

Make sure an experienced person is “driving” during the review. It slows a review down considerably when the person making changes in the document is not skilled with the tools being used. You will likely find it beneficial to use a scribe and/or facilitator from outside the project team. This frees the participants’ minds to engage. The facilitator can ask questions from an outsider’s perspective, elicit participation from quiet members, and generally direct the session. The scribe can “drive” the projection
and document changes as they are made.

At the end of the meeting ask if everyone is in agreement with the document as edited, including any issues deferred for further action. If any issues or concerns remain, address them.

5. Follow up

After the meeting, act on any action items and update the requirements document. Use QVscribe to reanalyze the document. Send the updated materials to the stakeholders for their final review and signoff. If the review uncovered a significant number of changes, it may be necessary to conduct a second face-to-face review to find new errors and inconsistencies that may have been introduced and to validate the final document.

THINGS TO KEEP IN MIND

Do not do the review too early. The review should be just that – a review of an ostensibly final document. If there are still open issues, address them prior to the meeting rather than using the review meeting as a design meeting. The availability of tools like QVscribe make it much easier to go into the review with a nearly final document. The purpose of the review is to make sure everyone is aligned, not to get everyone aligned. It may even be helpful to hold an informal “pre-review” session to check for general alignment before the final review. Only if there is a fatal flaw should wholesale changes be made during the review. Stick to the scope of the meeting.

At the same time, do not hold the review too late. While it needs to be late enough to have a complete set of requirements for review, it needs to be early enough to have time to make any changes identified in the session.

QVscribe will help the team resolve conflicts and find other issues in the requirements before the review. Use QVscribe reports to identify and correct as many issues as possible ahead of the meeting. Be aware of different personalities in the meeting and make an effort to allow everyone a chance to speak up. It is easy in large groups for just a few people to dominate the meeting, while others disengage. Also, be on the lookout for personality clashes where errors are defended and corrections criticized.

Be alert for groupthink and rubber-stamping of the document without really understanding it or critically assessing it.

Do your stakeholders know how to read requirements? Standards like EARS, INCOSE, and tools like QVscribe help keep things in readable language. For some stakeholders, though, other approaches may be necessary – pictures, lists, stories, flowcharts, etc.

Stay focused! If the meeting becomes unfocused and goes down the proverbial rabbit hole, people will get bored, and their attention will drift. Use a flipchart to capture unrelated issues or issues that need to be addressed later and keep the meeting moving.

While more of a warning for earlier in the process, lack of stakeholder engagement can become apparent at this stage. Without proper engagement and communication from the very beginning of the project, the final requirements document may not represent what the stakeholders actually want and can blow up the requirements review meeting.

Learn how QVscribe can transform your design process.

Download a PDF copy of this guide.

REFERENCES

Bridging the Gap, https://www.bridging-the-gap.com/meaningful-sign-off-on-requirements/.

Famuyide, Stephanie. “Effective Requirements Review Sessions: Before, During & After.” Business Analyst Learnings, Business Analyst Learnings, 16 Feb. 2014, https://businessanalystlearnings.com/blog/2014/2/16/organizing-effective-requirements-review-sessions-before-during-after.

“How to Do a Requirements Review from a BA Perspective.” ReQtest, 3 Dec. 2019, https://reqtest.com/requirements-blog/requirements-review-from-ba-perspective/.

Kupersmith, Kupe. “How to Conduct a Requirements Review for Business Analysis.” Dummies, https://www.dummies.com/business/business-strategy/how-to-conduct-a-requirements-review-for-business-analysis/.

“Requirements Analysis.” Wikipedia, Wikimedia Foundation, 13 Dec. 2019, https://en.wikipedia.org/wiki/Requirements_analysis.

“Requirements Reviews.” Software Engineering 10th Edition, 7 Feb. 2019, https://iansommerville.com/software-engineering-book/web/requirements-reviews/.

“System Requirements Review (SRR).” AcqNotes, http://acqnotes.com/acqnote/careerfields/system-requirements-reviewsrrse.

Thakur, Dinesh. “Dinesh Thakur.” Computer Notes,  http://ecomputernotes.com/software-engineering/