A requirements review or walk-through is a meeting where you gather all of 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 valuable enough that it just simply has to be done.
All too often I’ve seen this important step in the requirements process skipped, often to the detriment of the project as a whole and especially to the detriment of getting all the stakeholders on the same page about the scope or details of a project.
Common Objections to Doing a Requirements Review
But I email the document out for review, that way everyone can do this when it works for them and I get better input. Let’s get honest here for a minute. In today’s workplace, people have competing priorities and are constantly multi-tasking. Opening up and reviewing that document is not the most exciting or probably the most pressing the most pressing task on their list. Few stakeholders will provide their best input in this manner. Those that will are probably conscientious enough to read the document before your meeting and come prepared.
I want an email sign-off because it’s traceable. Nothing about the requirements walk-through precludes an email sign-off. But if your reason for using email is to get a passive sign-off and cover your you-know-what, not to actually create the alignment that the sign-off actually entails, then you are doing your technology team a disservice.
My stakeholders don’t have time. Then one of two things is wrong–either you’ve identified the wrong stakeholders or you’re working on the wrong project. Either of these issues might not be your fault. But if the people benefiting from and contributing to the project can’t spend 2 hours in a room finalizing what exactly that project is supposed to do, there are larger issues at play.
When you sit down to review a requirements specification in a meeting, you know that people are actually reading it. You also will find that one comment leads to another and that can help discover new requirements before it’s too late. Besides, a review meeting cultivates a certain accountability – if you ask your stakeholders to look you in the eye and confirm they are ready to take the next step with the project.
How to Facilitate a Requirements Review Session
- Set the stage. Send out an email/calendar requirements with the document and a description of how the meeting will go. Let everyone know that their role is to provide any feedback on the requirements and ultimately sign-off on the document. Re-iterate this message at the beginning of the meeting.
- Be prepared. Have a few extra hard copies. If possible, project the document onto the wall using an LCD unit.
- Lead the walk-through section by section. Give everyone an appropriate amount of time to read and consider the requirements in that section. Ask for comments, clarifications, and questions. Ensure the discussion focuses on the requirements, not how to build them or what tasks need to be done or the marketing plan. As the review group agrees to updates, note these on your hard-copy or make them electronically where everyone can see them.
- Ask for sign-off. Say “I’ll make these edits and distribute an updated copy. Provided I get all these notes incorporated, is everyone prepared to sign-off? Are there any lingering issues or concerns?” Look at everyone in the room for a visual cue.
Some of the More Common Requirements Review Issues
Doing the requirements walk-through too early. As BA, do your homework first or you will be wasting everyone’s time. Vet out the big issues in small teams. Meet individually with the stakeholders to make sure you understand their needs. Recognize and elevate conflicts in requirements so these are resolved. By the time you do the walk-though, requirements should be almost ready to sign-off and the purpose is really to make sure everyone is aligned and to trigger any last gotchas.
- Reading every requirement aloud. I’ve done this and it worked, but it was inefficient and I wouldn’t suggest it. Instead, review the requirements in meaningful sections that people can read through in the meeting.
Not including the right people. Ideally, your review should include one person from every area of the business impacted by the requirements, good examples include marketing, operations, product management, customer service, and IT. Often times you’ll need more than one person from a group because of the decision matrix within that group.
- No one says a word. Be prepared with some questions to get discussion going. Often people don’t have something to say but don’t want to appear to be critical of your work. Even throw a few mistakes in to make sure people are paying attention. Then you can point out your own mistakes, a practice that can often trigger similar responses from others.
Feedback is centered around typos, not meaningful content. Politely say you’ll take editorial feedback in an email or by hard-copy, unless, of course, the feedback impacts the meaning of the requirement.
- It turns into a design meeting. Stop it from happening. This can be a great time to start your issues list.
The business uncovers a fundamental flaw in the project. No matter how diligent you are in ensuring your stakeholders are ready for this meeting, someone can have a middle-of-the-night insight the day before your meeting and blow it to pieces. Take a deep breath. Ask the group if they feel this issue has to be dealt with in order to finalize the requirements for this project. If they say yes, you have two choices: you can refocus the meeting to deal with the new issue or disband the meeting and work out a plan to deal with it ASAP.
A walk-through is not the right technique. As valuable as reviews can be, some stakeholder groups benefit from different techniques for validating the requirements.