Skip to main content

Bad Ass BA; Peer Review. Part 2.

Co-authored by Rebecca Burges

Rubber Stamp or an Objective Quality Check?

This article is part two of a 4-part series on the topic of peer review of a requirements document.

Just to review, here are the four go/no go checkpoints checks:

  1. Business Case Synchronicity Check
  2. Requirements Document Sanity Check
  3. Requirements Statements Content Check
  4. Requirements Document Housekeeping Check

And here are the typical excuses not to do a peer review, and why those excuses are bogus.

  • It’s scary! They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.
  • It takes time. Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.
  • We are already behind schedule. Would you rather let the customer catch the errors? Or worse yet, miss the errors?
  • I don’t know anything about that project. So you’ll limit your review to the more general, BA-level comments; that’s still valuable.
  • It’s hard to do. True. The more you practice, the less difficult it will be the next time.

In the previous article we looked the first check, Business Case Synchronicity. Let’s assume that your Business Requirements Document (BRD) syncs up with the business case, that is, benefits for doing the project have been identified, there is an expectation of Return on Investment, there is an expectation that the project will report on progress towards achieving the ROI claim. Moreover the Customer has identified the means for validating project success. Now it is time to perform the Sanity Check.

Requirements Document Sanity Check

This check verifies that the document is worth continuing to read at the business context level. If stakeholders could read this document and come away with different perceptions about what the project is about, that would result in an insane expenditure of time and money that can’t possible have a good outcome.

Check the box next to the item if you can answer ‘yes’ for the document you are reviewing. It sometimes helps to approach this review the way you approach testing; by looking for ways to willfully misunderstand the document.

Requirements Document Sanity Check

□ Does the Scope section identify what is in and what is out of scope?
□ Do the Scope statements describe what the project’s customer expects will get done – without specifying who is doing the work, or how the work will get done?
□Can you understand the scope of the project and does it make sense?
□ Do you believe that the stakeholders share the same understanding of the project’s scope?
□ Is there a Business Context Diagram that provides a high-level overview of the functionality in terms of the system, the business entities that will interact with the system and information that is exchanged between the entities and the system?
□ In the Business Context Diagram, are the Business Entities defined in a concise (1-3 sentences) manner that makes sense to the customer? Are the business Interactions equally concisely defined?
□ Is there a shared understanding of “what have we got now”? Does the BRD need an “as-is” process map?
□ Is there a process flow diagram that helps the reader understand the impact of the new (or changed) functionality that will come from this project?
□ If this project focuses primarily on moving data around, is there a high-level data model? This is especially important when the application being developed will be pulling data from multiple sources outside of the application.
□ Have the business rules been articulated? Business rules are essentially constraints that the business imposes on itself. Typically one or two business rules govern a set of requirements.
□ Do the requirements categories make sense? If the requirements are jumbled together like unmatched socks in a sock drawer, the readers of your BRD will be as unhappy as the person who can’t find a pair of matching socks on a Monday morning.
□ Are the business level requirements stated in terms that reflect the needs of the business (as opposed to identifying a solution)?
□ If the document has a mix of business (high-level) and functional/non-functional (low-level) requirements, are the business-level requirements clearly identified as higher level? You might want to put the business requirements in a section separate from the functional and non-functional requirements or they might be at a higher numbering level, e.g., requirement 2.0 is business-level, and requirements 2.1 through 2.6 are functional requirements that provide detail for requirement 2.0
□ If there is existing functionality that must not be changed in the course of executing the project, does the BRD identify what that functionality is?
□ Is there a requirement for baseline values to be recorded for the existing functionality so that a comparison can be made prior to deployment of new functionality to verify that no unwanted changes will occur?
□ If the Customer has an expectation for specific tests to demonstrate that the requested functionality has been achieved, are those tests reflected by one or more requirements to an appropriate level of detail?
□ In the project execution methodology, is there an expectation for a communication plan? There may be a need for an explicit requirement for a communication plan as a deliverable.
□ In the project execution methodology, is there a process for obtaining stakeholder approval of the BRD? It may be prudent to collect an email from each stakeholder documenting their approval and embed those emails in the appendix of the BRD so that the BRD can become a complete historical artifact.

For more information about Context Diagrams, see Software Requirements, Karl Wiegers, Microsoft Press, 2nd edition, 2003, Chapter 5.

If the project will change an existing business process then it is particularly important to have a map of the as-is process mapping so that there is a baseline to compare the future state to. This is not the time to document the to-be process because the solution hasn’t been chosen yet. If it is easier to convey the requirement with a to-be process flow, make the process flow as solution-agnostic as possible and indicate that the process flow is a hypothetical example.


Did the document pass the sanity check? If one or more of the items in the list above is not checked, there is some risk that the requirements document is insufficiently clear or is incomplete. When a BRD can’t pass a sanity check, it is time for brave BAs to “just say no” to pressure to proceed with the review of the requirements themselves, let alone approve the entire BRD.

If you are a peer reviewer, your job is help the BRD author determine the best course of action is to correct these flaws and errors. As a peer reviewer you are expected to return written feedback. Take time to explain what is missing, and provide examples of the misunderstanding that might ensue. It would be a kindness to provide feedback to the BRD’s author in advance so that they have time to think about your comments and perhaps initiate the conversations to get some of the questions resolved.

Once your BRD has passed the sanity check then and only then proceed to the review of the requirements statements themselves which we’ll cover in Part 3 to be published In November.

Use and Profit from Peer Reviews on Requirements Documents

  1. Business Case Synchronicity Check
  2. Requirements Document Sanity Check
  3. Requirements Statements Content Check [November, 2009]
  4. Requirements Document Housekeeping Check [December, 2009]

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding, at She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected]