A requirements review is a structured audit within the business analysis process where participants ask questions, make suggestions, and improve the quality of the product being reviewed. When multiple people play a role in improving the quality of the artifacts under review, the result is a better product. You can conduct a requirements review at anytime during the course of the entire project.
Requirements reviews have several benefits:
Finding missing requirements: Because multiple people are involved in a review, you have multiple brains that can clarify textual descriptions and identify and correct inaccurate representations of the material.
You want everyone on the project team to come to a single interpretation of the requirements, so clarifying a misunderstanding in the requirements document early on (as opposed to after it has already been programmed into a product) is a huge benefit.
Identifying quality improvements: Remember, you can’t test in quality, so you have to figure out where to build in quality as you create your product.
Educating other team members on other parts of the project: This process can help with knowledge transfer because more people understand the entire project rather than just their own small components of it.
Requirements reviews are great ways to find defects in a document. Look for areas in the document where you state the same information in different ways, such as in the text and in a graphic. Make sure both sources of information say the same thing.
For instance, if an entity relationship diagram (ERD) (a logical map of the data structure) says a particular field is mandatory, make sure the corresponding text table doesn’t say that it’s optional.
At any point in the project, you can perform a requirements review on any artifact or deliverable in the project. Here’s what you should ensure when you review some of the most common artifacts:
Business requirements: They’re testable and support the original project objectives.
Software requirements (sometimes called detail design or software requirements specifications): They align with the functional design and business requirements.
Program walkthroughs: The program code is efficient and no interfaces are forgotten. In addition, you should make sure the code is the most efficient it can be and that it features industry best practices.
Test case: All the requirements are being tested. Additionally, this area is one in which the team needs to determine what data should be in place for testing.
Post-implementation user assessment: The product that was produced as the solution is actually being used.
A formal requirements review follows several steps:
Schedule the time with the participants.
Figure out who needs to be in the reviews and then determine when they can all meet. Some participants’ attendance may be mandatory, but other people may be optional participants. Make sure you find a time that works for everyone and officially schedule it (versus playing it by ear).
Deliver the review materials.
Determine how much time prior to the meeting people need to review the materials and send them out accordingly to the meeting participants. Generally, distributing review materials two business days beforehand is a good guideline, but project timelines and review material size may dictate a longer or shorter time frame.
If project time is tight, you can deliver review materials on a Friday for a Monday meeting. This gives you two days to review the materials before the review session. Don’t make this a habit because not many people like doing project work over the weekend. However, if you’re stuck, it does allow you to recapture some lost project time and still deliver materials with enough time to read them.
Review materials prior to session.
This step is the responsibility of all review session participants. They need to review the materials prior to coming into the working session.
Conduct the session.
This point is where the participants get together and make suggestions.
Record all the changes to be made to the review materials.
These notes include all the items you’ll make changes to following the review session.
Update the material.
Refer to your review notes and make changes according to what was requested.
Conduct a second review if necessary.
If the meeting produced a lot of changes or reviewed an artifact in the middle of a project, conducting a second review to verify the changes were applied properly is a good idea.