What should someone be looking for when they approve requirements?
I'm not sure what direction to give the stakeholders for the upcoming requirements review. What should someone be looking for when they approve requirements?
The short answer is: it depends on the person, their experience, their familiarity with the requirements, and the reasons they've been assigned a reviewing role. Ideally, you'll have more than one or two reviewers. For medium or large projects, you'll need at least six reviewers to examine the requirements from various perspectives. For small projects, having more than one or two reviewers increases the odds of achieving complete, high-quality requirements that reflect the business need accurately, in doable, testable ways.
The following table lists six types of reviewer, and what they typically evaluate during a requirements review.
Type of Reviewer
Business Analyst peer or Business Analyst leader
Often considered a peer reviewer, this person should appraise the quality and structure of the written requirements to ensure that their organization best meets the needs of the project. A seasoned business analyst or leader will also be able to identify gaps in the requirements and give feedback based on the pain points and successes they've experienced in the past.
Because the developers are responsible for creating a solution that meets the requirements, they must ensure that the requirements are feasible (can be translated into a solution), clear (can be understood as written), and complete (include everything that's needed to build a solution, e.g., the correct data points).
Quality Assurance Analyst or Tester
The people responsible for checking the quality of the solution will need to ensure that the requirements are testable and unambiguous. They will ensure that every requirement can be translated into a test case or scenario, and that the expected results are defined clearly.
The project manager should review the requirements with an eye to whether they adhere to the project scope and clearly state any dependencies and risks. The project manager may also identify common pain points, based on past experience.
Stakeholder or Requirement Submitter
The people who first submitted the requirements (business stakeholders, subject matter experts, etc.) should review them for accuracy, to ensure that they represent the business needs. These people may also want to review the ease or difficulty of eliciting the requirements—with a focus on requirements that were unusually easy or hard to capture—to ensure that nothing was missed.
Sponsor, or someone less close to the day-to-day project; or a higher-level management reviewer
While it's unlikely that these reviewers will examine all the details of every requirement, you may want to ask them to examine the quality of the higher-level requirements to ensure that they support the project objectives and the highest-level business needs.