Tuesday, 08 December 2009 08:20

Bad Ass BA; Peer Review. Part 4.

Written by

Co-authored by Rebecca Burgess

Use and Profit from Peer Reviews of Requirements Documents

This is Part 4 of a 4-part series on how to perform a Peer Review of a requirements document.

The four steps in a Requirements Document review are:

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

Remember that 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 the document survives both of those checks, you'll review the content quality of the requirements statements. In Part 3 we did the heavy lifting, we scrubbed the content of the requirements sparkling clean and we tidied up the categories. We aren't done yet, we need to put on the white glove and do the housekeeping check. Once the document passes the housekeeping check, it has passed Peer Review and is ready to go to the Customer or the Requirements Review Board, or whatever the last step is in your organization's requirements review process.

First, a quick recap....

Why Perform Peer Reviews?

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....

Requirements Document Housekeeping Check

Why bother with housekeeping? We've been back and forth over this document already and know that the contents are correct, so what if there are a couple of little typos, or a diagram is mislabeled? Unfortunately, this is another example of the first impressions principle; when reviewers see small mistakes, they begin to suspect that there are bigger mistakes hiding in the document. It's the "spinach in the teeth" problem again.

Create a chart and check off each item if you can answer "yes" for in the document you are reviewing

Part 4. Requirements Document Housekeeping Check

Is the BRD template the "current" template?

Cutting and pasting content from a previous BRD is easy, but it could create problems if the current template has new sections or revised instructions. If the document is perceived to have "missing" sections, that is not okay.

Is the Table of Contents in sync with the document content? Look at both the section headings and the page numbers.

Is the business owner or executive sponsor named as an approver?

If not, should they be?

Are all figures, tables, and diagrams labeled? Is the numbering consecutive?

Are all units of measure defined?

For example, in international companies the default currency needs to be defined, not assumed.

Are terms that may not be familiar to the reader defined?

Take pity on the people who read the requirements document who aren't domain experts but have a responsibility to ensure the quality of the document. As a peer reviewer, if you don't know what the term or acronym means, it is your duty to ensure that the term/acronym finds its way into the glossary.

Are all diagrams referenced in the text actually present in the document?

Copy and paste, or copy and edit from other documents isn't plagiarism, it is "leverage". Sometimes we forget to make sure that diagrams will be available in this new context.

Is information presented in the most clear and concise format?

Should some text blocks be converted to a bulleted list? Or a table? Should some text blocks be accompanied by a diagram?

For those sections provided by the template that do not apply to this specific project, is there a sentence that says, "This section does not apply to this project."

Leaving a section blank looks sloppy, as if you forgot something. Removing a section looks like you are hiding something.

Is each requirement uniquely identified?

The unique identifier is needed for traceability.

Does each requirement have a priority?

The PM will want to know what is most important to the Customer. Third party vendors will want to know what is most important to include in their quotes.

If most or all requirements are "high" priority, is there a secondary way to indicate which requirements could be cut or delayed if scope must be trimmed?

Providing this alternate means to analyze the scope isn't critical for all requirements documents. If you used a criteria-based matrix to determine the priority of the requirements, your PM will love you if you provide a reference in the appendix to that matrix, "just in case".

Does each requirement have a source (person's name, organization) and the date that it was added to the document?

If there are questions about a requirement, who will the PM / BA call? Just providing a name isn't good enough. A year from now, a key stakeholder could easily have moved to a different organization.

Has someone who cares about good grammar and spelling reviewed this document?

We work in an international environment. Most native speakers of English have no appreciation for how difficult it is to learn English grammar and spelling. And even native speakers of English may not be able to write a grammatically correct sentence. Find someone with grey hair and wrinkles who has a real wood red pencil. If you do nothing else, for heaven's sake use the spelling and grammar checkers in your word-processing application.

Have all duplicate requirements been consolidated into unique requirements?

After the "final" review it is normal to have to remove notes you left for the reviewers, such as, "This requirement was removed because it is a duplicate of Scalability-004." Producing the "final final" document will vary organization to organization. For some groups, you maintain history by presenting the document with the duplicates still in place and enumerated, but called out as duplicates. Other organizations won't give their approval unless the document is presented in a "clean" form, where you have removed the duplicates and renumbered the requirements so that the document is a clean starting point for the Design team. If you aren't sure what your organization expects, ask.

If any requirements refer to standards or policies, is the documentation of the policy or standard referenced?

You may need to provide hyperlinks to internal or external documents or websites.

Do all hyperlinks work?

Follow the links - they may work for the BA author but if they don't work for you, then the links may not work for other people.

Has information that is not relevant to the requirements been separated from requirements, e.g., into an appendix, or put into a separate document?

A requirements review is supposed to be a review of requirements, only, but related topics often seem important and distract people's attention from the requirements. Examples abound:

  • Roles and Responsibilities: Who is going to do what? In large companies both Product Engineering and IT will be doing development work. In an outsourced model, development may be done by a third party working in conjunction with an internal customer. This information belongs in an appendix, not in the main body of the BRD.
  • Project Management: It is not uncommon to see project check points articulated as requirements, but these requirements need to be kept separate from functional and non-functional requirements so that the evaluation of the requested functionality can focus on meeting the overall business needs rather than on the short term project needs and constraints.
  • Project Delivery: Some requirements documents are maintained as the project moves through project delivery stages, such as Phase 1 and Phase 2. For Phase 3, the "old" requirements from Phase 1 and Phase 2 that have been met need to move from the Requirements section of the document to an Appendix.

If one or more of these items is not checked, there is some risk that these errors or the lack of document organization will taint the perceived quality of the document as a deliverable and possibly cast doubt on the quality of the requirements themselves. Just because the white glove test came back with some lint is no reason to lose heart. Your document is so close to being done that you can taste it. And the truth is that you may be so sick of the document that if you never saw it again you wouldn't miss it. So, what does a Bad-Ass BA do? Think about what you need. Time away from the document? Just two days away from the document can refresh your eyes and your attitude. Help with grammar? Find that person who reminds you of your high school English teacher and ask for a favor. Remember, Bad-Ass BAs set their egos aside to get the job done. You can do this.

If the answer to all of these questions is yes, then your document has not been carelessly rubber stamped, it has completed a true objective peer review. Is your heart filling with pride? Good. Each time one of your peers found something, did you feel embarrassment? Don't beat yourself up; just fix the problem, learn from it, and let it go. Do you feel like standing outside in the sunshine for "just a moment"? Good, go do it. If nothing else, do take a moment to breathe before you send the document on to the next step in approval process.

So, is a peer review an easy task? No, it is a painstaking effort and one that I hope will bring you a great deal of personal satisfaction and pride. Each time you bring a document through peer review, think about what you have learned, and find a way to share your new knowledge and confidence with your peers. We are all in this together.

Use and Profit from Peer Reviews on Requirements Documents

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

Make a date to join Cecilie Hoffman for the Bad Ass BA Peer Review Webinar on January 14, 2010. Click here for time and other details.

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.

Read 19242 times

© BA Times.com 2019

macgregor logo white web