Effective Requirements Review Sessions: Before, During & After
/Requirements Review Sessions or Structured Walkthroughs are designed to communicate, check and confirm requirements with stakeholders. During these sessions, participants are expected to ask and respond to questions, proffer suggestions and provide comments on the solution that is about to be implemented based on their requirements. This activity is particularly very important in exposing requirements that the analyst may not have considered beforehand and should not be skipped.
During this session, additional requirements may be identified while existing ones are confirmed, amended or cancelled.
The first step to conducting a requirements review session is arriving at a set of requirements which are presented in a format that stakeholders can understand. Employing visual models in favour of text will make the review session more stimulating and engaging for stakeholders.
Stakeholders usually do not have a lot of time to commit to review sessions. To maximize the limited time you have with them, follow these key steps to ensure you get it right the first time.
Before the Requirements Review Session
1. Decide on the List of Reviewers
A lot of things can go wrong with review sessions. Rubber stamping, groupthink, arguments, personality clashes and self-censorship are a few examples. Invest some time in stakeholder profiling to ensure you invite the right mix of stakeholders and prevent potential clashes.
The Requirements Specification Document (RSD) is usually reviewed by stakeholders and peers. The team of reviewers would typically involve the same stakeholders from whom requirements were elicited – the end users of the system. In some cases, a stakeholder may be elected to stand in for another. Make sure the role of each person is clearly defined and communicated to them in advance. In addition to the main reviewers, typical roles include author, scribe and facilitator. In most cases, the BA is the author and facilitator while a different person is assigned as scribe, though this is highly dependent on available resources.
2. Plan and Schedule the Requirements Review Session
Schedule the review session early enough to ensure that stakeholders have sufficient time to prepare.
An agenda should be developed, which contains an outline of the activities that will take place during the review session. Put the important issues higher up on the agenda, so that they are discussed when concentration is at its peak.
Decide on the location and materials you will need on the day. Will you make use of whiteboards or flip charts? Will you need a software to simulate process flows? Will you need a projector to display screen mock-ups? Is there any specific system (mobile/desktop) you intend to make use of? Will remote collaboration be necessary?
A major aspect to the review session is timing. Review sessions are hard work and require maximum concentration, so you want to avoid people getting bored. Consider splitting your sessions so that they are not lengthy, unnecessarily drawn-out and unproductive.
3. Send out the Requirements Package
This could be a set of documents or just one document to be reviewed prior to the session. What obviously precedes this is a list of requirements that would have been collected during the elicitation sessions. Though there is no guarantee that all stakeholders will go over the RSD after receiving it, the requirements will still need to be discussed to ensure that everyone has the same interpretation of them.
During the Review
4. Be Guided by the Objectives of the Session
The beginning of the review session is a good time to emphasize the objectives of the session, set the ground rules and reiterate your expectations of each reviewer.
Also, give your reviewers ideas of what to look out for. Examples include, but are not limited to:
- Missing requirements
- Redundant/unnecessary requirements
- Incorrect requirements
- Contradictory requirements
Requirements Review Sessions are about error detection, not error correction. Any errors detected should be corrected at a later time. Some guidelines to follow are:
1. Review the document and not the author
2. Avoid defending or challenging comments; this wastes time and can create unnecessary distraction.
3. Stakeholders should be clear on the objectives of the session and what exactly to look out for to improve the overall outcome.
5. Review the Requirements
Go over the requirements models and mock-up screens one at a time to ensure that stakeholders have the same understanding of requirements.
For contentious issues, use the parking lot to avoid distraction from the requirements that are being reviewed. Remember to avoid delving into design and implementation issues which are beyond the scope of the review session. You can achieve this by focusing on the main use cases of the system without spending an excessive amount of time delving into exceptions and rare uses.
6. Take Notes
Notes are important for future reference but it can be quite difficult facilitating a session and taking lengthy notes at the same time. Focus on facilitation (which involves asking questions, eliciting responses from the quiet ones and generally directing the session), which is a lot of work on its own and let the scribe do his bit.
After the Review
7. At the end of the review session, ask stakeholders if they are ready to formally approve the RSD by signing off.
In cases where there are major issues to be clarified, sign-off should be postponed till a later time. Typically, an agreement is reached on whether the RSD will be amended, requires additional reviewers or can be signed off the way it is.
The outcome of the review session will determine which specific actions need to be carried out.
View a summary of the tips for facilitating Requirements review sessions:
