Home

How to Recruit Participants for a Business Analysis Requirements Review

|
|  Updated:  
2016-03-26 14:16:35
Buying a Business For Dummies
Explore Book
Buy On Amazon

Who participates in the reviews of your business analysis requirements depends on whether the review is formal or informal and on what kind of data/information you want feedback on.

We mention a lot of different potential meeting participants, but managers are nowhere to be found. In most cases, managers shouldn’t attend review sessions because

  • They can change the behavior of a room. People may not voice their opinions because they’re afraid of management retribution. If the managers in your organization have this power, it’s best to keep them out of a room.

  • They may use it as a chance to review the business analyst’s job performance. The review is designed as a way to improve the artifact, so it isn’t effective as a grading session for the business analyst anyway.

We aren’t saying that managers absolutely, positively can’t be at a session. Some managers can provide a great deal of knowledge and have a great oversight of system interfaces and other parallel projects. Also, you want them in the room reviewing the deliverable; just ensure their presence doesn’t disrupt the flow of the meeting.

Informal reviews

An informal review is a great sanity check for a business analyst. You can pass a document — such as meeting minutes, business requirements, or a scope document — to any other team member and ask her for feedback.

The point of the informal review is to improve the overall quality of the document. You don’t even need to review an entire document. You can just meet with someone to get feedback on a particular area of the document.

For example, if you need feedback on test cases, meet with a QA analyst — because these folks deal with testing all day long, they’re in the best position to review your work. If you want feedback on a prototype, meet with a software application developer.

A great way to mutually improve your document and feed yourself at the same time is to have lunch with another business analyst on another project and swap documents for peer review. Not only do you improve the quality of each other’s documents, but you also gain insight into each other’s projects, interfaces, and requirements. Based on the review, you may wind up finding a missing interface!

Formal reviews

A formal review is structured and has defined participants. Each participant plays a role in the review, but not all of them may participate in every review. The list of participants is as follows:

  • Author: This person is the creator of the product being reviewed. The author is the one who can clarify what a particular statement within the documentation means, so she needs to be available to answer questions.

  • Recorder: The recorder is the person making detailed notes about the changes to be made in the document being reviewed. Generally, this participant should be someone other than the author because the author is busy explaining what certain areas of the document mean. However, more and more companies are leaving this role to the author as well.

  • Facilitator: This person conducts or moderates the session, calling on participants for comments and questions and directing the flow of conversation. Ideally, the facilitator should be someone other than the author, but this hat often gets put on the author’s head as well.

  • Peers: Peers are people who hold the same job and/or title as the author and can critically review the product and offer suggestions. For example, if the document is a business requirements document, you want other business analysts as peers in the review session to help ask questions about what a business analyst needs to include in the document.

  • Reader: The reader reads the document aloud during the session and prompts participants for their comments and suggestions on each section. This optional role generally ends up falling to the author or facilitator.

  • Additional reviewers: This category is basically anyone else on the project team who can provide input on different aspects of the documentation. For instance, a usability engineer or lead developer may make quality suggestions on a prototype and the user experience.

The wider the range of viewpoints, the greater the comments, so invite enough people to the session in order to get the feedback you need. Just make sure it’s not so many that you overwhelm yourself.

About This Article

This article is from the book: 

About the book author:

Kupe Kupersmith, CBAP, President of B2T Training, possesses more than 14 years of experience in software systems development. He serves as a mentor for business analysis professionals.

https://www.b2ttraining.com/about-us

Paul Mulvey, CBAP, Director, Client Solutions, B2T Training, has been involved in business analysis since 1995

Kate McGoey, Director, Client Solutions, B2T Training, has more than 20 years' experience in application development and life cycle processes business.