Co-authored by Rebecca Burgess

Rubber Stamp or an Objective Quality Check?

When I ask for a "peer review" of a requirements document, I'm expecting a quality assurance check before the requirements document is presented to the Stakeholders. Some people think, "Oh, you're my friend. I could never criticize your work." But if you just rubber stamp (approve without a critical review) my work, you aren't really my friend at all. If my friend/peer/co-worker/fellow BA doesn't "take out a red pen" (or turn on track changes) and come back with lots of comments and questions, I worry. You would tell your friend that she had spinach on her teeth before letting her go back to the office after lunch, wouldn't you? By the same reasoning, wouldn't you do a careful review of her requirements document before it goes to the customer for review and approval?

There are a number of levels at which a document should be reviewed. In general, they are:

• Business Case Synchronicity Check
• Requirements Document Sanity Check
• Requirements Statements Content Check
• Requirements Document Housekeeping Check

These checks are filters; that is, if the document doesn't pass the Business Case Synchronicity Check, you will stop the review. Only if the document and the business case are in sync, will you check for sanity, then if both of those checks pass, review the content quality of the requirements statements. Finally, do a housekeeping check on the version of the document that is ready to go to the Customer.

By checking the requirements document at each of these levels, you will be doing your peer a favor, and help her/him produce the highest quality document possible. We will detail the purpose and method for each check in articles over the next three months.

Why Peer Review?

Why bother with peer reviews in the first place? Here are a few concise reasons to use this powerful tool:

Improve the quality of the document being reviewed - More eyes are better.

Identify and correct project problems, errors, and omissions as early in the project cycle as possible - Early fixes are cheaper, by orders of magnitude.

Learn from colleagues' insights and errors - If they can't be a good example, they can be a horrible warning.

Broaden your knowledge of other areas of the business - The more you know about the business, the easier it is to move up to that "enterprise analyst" position.

Ask the stupid questions - see Bad-Ass BA Lessons. Part 2.

What excuses do people use to avoid peer review and how can you counter those excuses? There are many excuses, but these are the most common:

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. Also see "Broaden your knowledge" in the reasons to do peer reviews, above.

It's hard to do! True. And these articles will make it easier, so read on....

Business Case Synchronicity Check

The requirements document needs to sync up with the business case. Really, it does. We need to check benefits, ROI claims, reporting on ROI, success criteria, and the means to validate success.

Incidentally, for this article, the business case is assumed to contain a statement of the problem that needs to be solved, who the problem impacts, and the benefits, goals, and success criteria expected to be achieved, both financial and non-financial. For more information about business cases, see Building the Business Case and/or the Enterprise Analysis section of the BA BOK.

Check the box next to the item if you can answer 'yes' for the document you are reviewing.

If one or more of these items is not checked, there is some risk that the requirements document does not match the business case. Your peer review mission is to convey these errors and omissions in a constructive manner. If you are expected to return written feedback, take time to explain what is wrong or missing, and provide examples if possible. If you will be participating in a peer review meeting, make notes of what you want to say so that you don't sound too negative.

Have you convinced yourself that the requirements document and business case are in sync? No? Then the review of the requirements document should stop right now. The business case needs to be updated and everybody needs to agree that the business case is still valid. Once the documents are in sync, you can proceed to the sanity check, which will be covered in Part 2.

This article is part 1 of a 4-part series. The four sections are:

• Business Case Synchronicity
• Requirements Document Sanity (October, 2009)
• Requirements Statements Content Check (November, 2009)
• 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 balsamfir.com. She can be reached at Cecilie_Hoffman@Symantec.com.

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 Rebecca_Burgess@symantec.com.

Comments (8)