Skip to main content

Author: Cecilie Hoffman

Bad Ass BA; Peer Review. Part 4.

Written by Cecilie Hoffman on . Posted in Articles.

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

Bad Ass BA; Peer Review. Part 3.

Written by Cecilie Hoffman on . Posted in Articles. 1 Comment on Bad Ass BA; Peer Review. Part 3.

Co-authored by Rebecca Burgess

Use and Profit from Peer Reviews of Requirements Documents

This article is part 3 of a 4-part series on the topic of peer review of a requirements document. Before we dive into part 3, indulge me in a personal note.

My organization recently changed from having a peer BA review another BA’s BRD to a novel process in which four BA peers review one BRD. Each of the four peers has a different perspective based on their professional experience. Two weeks ago one of my BRDs went through peer review. In our process, first the reviewers provide their written comments. Then the BRD author has a full day to review the comments before conducting a structured walk-through of the BRD with all the peers in a conference call.

While reviewing the combined comments on my BRD, I experienced a series of emotions I haven’t felt in quite a while: initial horror, shame, indignation, despair and dismay. One of my peers wrote me a note, “Hey Cecilie, is this a test? I’m commenting on your BRD with words that I hear in my head in your voice.” I wish I could say that it was a test, but it wasn’t. I had submitted a BRD to the peer review process under duress (time pressure); the BRD wasn’t my best work but I honestly didn’t expect that scrub cloths would come back so dirty after my peers had examined my work.

I spent several hours cleaning up that BRD. I wasn’t looking forward to the conference call review where, in accordance with our internal process, I would walk the group through the comments that were marked “High” and “Showstopper” – I would have to reply to each such comment and offer a suggestion for remediation. All High and Showstoppers had to be resolved, otherwise my BRD would fail the peer review and fail to move to the next step of the BRD approval process.

My BRD received a conditional approval from my peers – I had to get a couple of questions answered from the stakeholders first. Fortunately the answers came back quickly. Another hour to tidy everything up, and the BRD was fully approved by the peer group to move forward. Most of the time I do leave my ego at the door but apparently I kept it with me during the review because it took a couple of hours of mentally pouring honey on my bruised ego for me to recover.

We’ve been running this peer-group review process for about two months. We are hearing from the downstream reviewers – all managers – that the quality of the BRDs has improved noticeably. I can attest that the quality of my BRD benefited from the scrutiny of my peers. The difficulty in a peer review is that, if the peer reviewer is also your friend, your friend may not be able to be as honest as you need him/her to be. The team of four gave me honest, constructive comments about scope and risk; they caught inconsistencies in the requirements, and questioned the testability of some of the requirements. An un-anticipated side effect of this peer-group review process is that we are learning from each other about how to address BRD authoring problems much faster than anyone expected.

So, that was a long note, but I hope it is helpful to anyone who is nervous about giving peer review a try. Embarrassment will not kill you and in the end you will be more proud of your work.

Let’s do a recap before we begin part 3.

One way to conduct a review is as a series of go/no go checkpoints.

Just to review, here are the four checks:

  1. Business Case Synchronicity Check
  2. Requirements Document Sanity Check
  3. Requirements Statements Content Check (In this issue)
  4. Requirements Document Housekeeping Check (December 2009)

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 first article we checked for Business Case Synchronicity. We found that the BRD synched up with the business case, that is, benefits for doing the project have been identified, there is an expectation of Return on Investment, and 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.

In the second article we performed the Sanity Check. We verified that the Scope not only identifies what is in scope, but what is out of scope as well. The document has a business context diagram, a 30,000 foot view of what the project is about in terms of system functionality, the business entities that will interact with the system, and information that is exchanged between the entities and the system. Finally we verified that the categories of the requirements made sense for this particular BRD.

Now it is time to look at the requirements statements themselves, both individually and, as they relate to each other.

Requirements Statements Content Check

Take a deep breath, hold it, and let it out slowly. Make sure you aren’t going to be interrupted for at least half an hour. Depending on the length of the document, you’ll need chunks of uninterrupted time to do this part of the review.

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

 

Clarity
Is each requirement relevant to the business problem?
Are all requirements actually requirements, not design or implementation statements?

Design and implementation statements are “how” statements; a requirements document has “what” statements that ideally do not imply a desired solution.
Do you understand each requirement? Does each requirement make sense to you?

If a requirement doesn’t pass your “sniff test”, it likely won’t make sense to anyone else.
Are the requirements “solution agnostic”, i.e., do they convey the business need without specifying a solution?
Are the statements constructed as proper statements or sentences?

If you think the requirement statement is a fragmented thought, other people will too. The BA author may need to request more information (not necessarily more detail).
Is the content in each statement just sufficient to convey the idea?

Statements can become too terse (fragments), or too verbose. “Verbose” can be any of these:

  • Too wordy, but the statement is still just one requirement
  • More than three lines long.

A statement that is longer than three lines of text is not always verbose, but verify!
Are the business requirements written in non-technical language?

Is the text understandable to a business person and understandable by an independent third-party? The problem isn’t just a missing term in the glossary; if the requirement is jargon infested, the BA author should revise it for the benefit of mere mortals.
If a requirement needs specific business knowledge to understand, will the people who implement and/or test the requirement have that knowledge?

If not, the BA author may need to provide more information in the requirement, or explanatory text along with the requirement.
Are the requirements constructed to reduce the possibility of more than one interpretation?

If not, does the requirement need more detail to limit it to a single interpretation, or should there be a set of related requirements to reduce the likelihood of ambiguity?
Does each requirement address a single concept, topic, element, or value?

It takes a clever BA to decompile a complex idea and turn it into a requirement. The result of the first attempt may be an overloaded requirement, i.e., a single requirement that is actually more than one requirement. Look for requirements that have more than one relative clause, more than one instance of a semicolon, or the frequent red flag, more than three lines of text. These attributes are often indicators that the requirement needs to be split up into a set of multiple-but-related requirements, each with their own identifier, e.g., Security-011a, Security-011b.
Are requirements statements distinguishable from the explanation that often follows a requirement?

  • Sometimes a requirement needs an explanatory note, that is, text that is supplementary to the core requirement. Be sure that the note is separated, even by a blank line, from the core requirement so that it is clear which statement is the requirement and which is the explanatory note. Notes should not have the telltale “shall” verb.
  • Sometimes the explanation is a design constraint. Design constraints need to be assembled in their own section such as an appendix section for design constraints, or, at the very least, listed in the Assumptions.

Testable, Verifiable
Are the requirements verifiable by testing, demonstration, review, or analysis?
Do the requirements have success criteria, and a metric that specifies the success threshold?

“I’ll know when I’m happy” is not an acceptable evaluation criterion!

Key, high priority requirements need explicit success criteria and/or metrics. Lower priority requirements or very detailed requirements may have implicit success criteria.
Are the criteria for a “pass/fail” evaluation clear and quantifiable?

An example of a clear evaluation criterion is a named process that a human or a machine can execute to verify the requirement has been met.
If the success criteria/metrics for a requirement are known, is that information associated directly with the requirement?

Sometimes the success criteria/metrics get separated from the requirement, e.g., in another section of the document. Use cross-references or some other means for the reader to put the two together.
Are the requirements free from weasel words? (see BA Times article http://www.batimes.com/component/content/article/106-articles/377-bad-ass-ba-caution.html)

Weasel words will be the ruin of the project.

Business-Critical Dates
Are timing constraints such as due dates, deadlines, and completion-date dependencies identified?
Are the “critical” dates truly critical?

There are many ways to define “critical to the business”. It is important to distinguish “critical” and “important”. In my humble opinion, there are four types of truly “critical” dates:

  • Beyond this date there will be an impact on revenue generation
  • Beyond this date we will lose the ability to conduct business
  • If we miss this date (which we announced to the media) we will be subject to ridicule and derision in the press which will drive our stock price into the ground
  • If we miss this date we will be subject to contractual or regulatory sanctions, such as a monetary fine. For example, being out-of-compliance, or a real estate lease date expiring, or a contractual completion date not being achieved.
Are the “important to customer” dates articulated?

Even if the date isn’t “critical” by the definition above, a date can be important to the customer and should be identified as such so that the project manager knows about both the date and the expectation.

3rd Parties and Partnerships
Are the major requirements identifying the need for information to be shared, processed, or stored by 3rd party partners or hosted applications?

Compliance
Are compliance requirements identified?

Compliance requirements often first appear as an assumption. Assumptions can be overlooked during design and implementation. Calling out a compliance requirement ensures that the project test plan will have a line item for verification of compliance. Examples of compliance are data privacy (Personal, Identifying Information (PII)), payment card industry (PCI), legal, financial, and governing entity policy compliance.
If the project does not have any compliance requirements or impact, is that made explicit?

Adding the statement, “This project do not have any compliance requirements.” is better than just leaving the Compliance section of the document blank, which looks like the author forgot something.

Business Communication Processes
Are the major requirements related to supporting business communication processes included?

If the project is going to have an impact on how users do their work, in terms of what they see or what they do, then there needs to be a communications plan. The BA author may think that it is overkill to have a requirement for a standard project deliverable but the manager of the group that provides end user support may see things differently.

Internationalization and Localization
Are the major requirements related to internationalization and localization included?

Internationalization, known as I18n (meaning “I – eighteen letters -N”) to people who do this for a living, is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures. Doing the work of translating the text into local language and culture is called localization, aka “L10n”.

Timing / Response
If time-critical functionality is known when the requirement is written, is the time-criticality identified, and are timing criteria specified with metrics?

A requirement for “fast response” isn’t testable! “Fast” compared to what? Is less than 10 seconds acceptable? Is less than 2 seconds acceptable?

Reporting
Is there a requirement for creating a report to show progress towards achieving the projected return on investment (ROI) on the project/product?

According to best practices, a requirements document should have a business case. That business case identifies the expected ROI for the work that will be done. For the project to be truly successful, it needs to produce the evidence for delivering on the ROI claim.
Are the reports/dashboards/extracts that are expected from this project identified?
Are the audiences for those reports/dashboards/extracts identified?

Unknown, Missing, Incomplete Requirements
Are requirements where information is unknown, missing, incomplete or “to be determined” (tbd), annotated with a reason for the incompleteness?

Some BRD templates have an “Open Issues” section were unknown, missing, incomplete or “still under discussion” topics are called out. Ideally each issue has the following information to help the BA close the issue:

  • A unique identifier for the Issue, this could be as simple as “Issue.1”
  • A description of what the issue is
  • The date the issue was first identified
  • The name of the person responsible for resolving the issue and a target date for that resolution
  • A status for the issue, e.g., Open/Closed/Deferred. Seeing a column of “closed” issues is so satisfying.

Requirements Statement Style
Do the requirements statements use one verb consistently, e.g., shall or will?
Are the requirements articulated at a consistent level of detail?

Should any particular requirement be specified in more detail? In less detail? It is important that each requirement be stated at an appropriate level of detail, and that all the requirements in a given document be at the same level of detail.
Is level of information in the document consistent with commonly accepted practices for your company?

Each company has its own rules for the level of information that should be included in a requirements document. If your company doesn’t have a guideline, here is a possible starting point:

  • A Business Requirements Document has project-level requirements that describe the needs of the Stakeholders.
  • A Functional/Non-Functional Requirements document has requirements at the software system level and may include requirements at the subsystem-level.
  • A System Requirements document has even more detailed requirements.
Do the requirements statements use the “Trigger Actor Action Condition” syntax?

Requirements in the form of “Ability to …” are ambiguous unless there is a context-setting statement that all requirements describe who or what the actor is. Requirements must identify the actor as a human or an automated agent. “Ability to …” statements create problems because the reader has to guess at whom or what will have the ability.

Consistency of Requirements
Have inconsistencies, omissions or redundancy been identified and corrected?
Do requirements use consistent terminology to the same object?

It is normal for different groups within a company to have different terms for the same object. For example, in the United States what we call “regulations” may be called “rules” in Europe. It is important to identify both terms in the document’s glossary. Use one term consistently in the requirements.
Have requirements that describe two or more actions that conflict been identified?

The most common types of conflict are logical conflict and temporal conflict.

An example of logical conflict is when there is a general requirement for a “green” system, specifically, no printing, and, a conflicting requirement for the automatic generation of the quarterly sales results report to be faxed to the executives in Japan. An example of temporal conflict is when one requirement says that customer satisfaction data will be sent to an FTP site on a weekly basis and another requirement says that customer satisfaction data will be uploaded and processed on a daily basis.

Once such requirements have been identified, there are two possible ways to proceed. Either have the stakeholders come to an agreement, or, create an Open Issue to address the conflict as part of the design effort.

Requirement Traceability
Are all requirements traceable to at least one “in scope” objective?
Do all objectives/success criteria map to at least one requirement?

If not, there may be a gap in the body of requirements.

Common problems with Categories of Requirements
Do the requirements statements in the categories actually belong in those categories?

  • UI requirements are really good at hiding in a category other than a User Interface category.
  • System Interface requirements are often distributed throughout a BRD. Assembling interface requirements in one place makes it so much easier to understand what a project need is. Or, if there is a good reason for not moving the interface requirements from their functional category, give the technical team a reason to appreciate the BA by suggesting a table of Interface cross-references so that at least there is a logical assembly.
  • Be sure to distinguish internal interfaces from external interfaces. In some companies interface requirements are documented in a separate Interface Requirements Document (IRD) or Interface Control Document (ICD)
Are scope statements, assumptions, business rules and role/responsibility statements in the right category?

Sometimes a statement begins life as a requirement but over the course of revisions, it evolves into something different such as scope, assumption, business rule, or role/responsibility statement.
If there are interface and integration requirements, are they in separate categories?

Business people often use the terms interchangeably. The technical team knows there is a big difference!

Did you answer “yes” to the all the questions? If so, do you now believe in your heart that the requirements are good? If not, mark the requirements that need work and identify what your concern is.

If one or more of these items is not checked, there is some risk that the requirements are inadequate. Your mission now is to convey these “defects” to the BA author in a kind manner. If you are expected to return written feedback, take time to explain what is missing, and provide examples, if possible. If you will be participating in a structured walkthrough meeting, make notes of what you want to say so that your comments are thoughtful and constructive.

The document should not be seen by the customer or stakeholders until the problems are fixed. If the requirements are good, you can now move on to the last quality check, the good housekeeping check.

This is the third of four articles addressing Use and Profit from Peer Reviews of Requirements Documents

  1. Business Case Synchronicity Check
  2. Requirements Document Sanity Check
  3. Requirements Statements Content Check
  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 balsamfir.com. 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].

Bad Ass BA; Peer Review. Part 2.

Written by Cecilie Hoffman on . Posted in Articles.

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.

Summary

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 balsamfir.com. 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]

Bad Ass BA; Peer Review. Part 1.

Written by Cecilie Hoffman on . Posted in Articles. 1 Comment on Bad Ass BA; Peer Review. Part 1.

Co-authored by Rebecca Burgess

badassreq1

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.

 Part 1. Business Case Synchronicity
  • Is the business case document referenced in the requirements document?
  • Can you access the business case document from the reference (or could the business case be a figment of someone’s imagination)?
  • Is a stakeholder list available?
  • Do the individuals listed in the approvals section of the requirements document cover all the stakeholders?
  • Are the project benefits also benefits to the business? If the business sees no benefit, why is the project being undertaken?
  • Are the goals and/or success criteria from the business case represented by requirements (and can the requirements be traced back to the business case information)?
  • For each benefit/goal/success criteria, has a method for measuring the achievement of that benefit been described in the associated requirement, and does that measurement method make sense?
  • Are there clear requirements to provide any new data needed to measure the success of this project?
  • If the metric for the benefit/goal/success criteria is already implemented, has that benefit been baselined (measured in the recent past) and is the baseline data referenced in the appropriate requirement(s)?
  • Is there a target value and/or range for the benefit metric?
  • Is there a description of how and when the users expect to demonstrate achievement of the financial benefits resulting from the solution (after delivery of the project)?
  • Are the ROI claims (expected return on investment over a period of time) supported by requirements that describe how the business will periodically report on their progress towards achieving the ROI?
  • Based on the business case, do you believe that all of the critical business needs are represented by the body of requirements?

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:

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

Bad-Ass BA Lessons. Part 1.

Written by Cecilie Hoffman on . Posted in Articles.

Co-authored by Rebecca Burgess

Ten Steps to Becoming a Bad-Ass Business Analyst

Do you want to take your professional capabilities to the next level? Do you want to add more than just techniques to your tool kit? Wanna become a Bad-Ass Business Analyst? Here are ten opportunities to apply “intelligent disobedience” and judicious audacity to your environment to earn those bad ass stripes.

The term intelligent disobedience comes from guide dog training. Blind people who live in cities listen for the auditory cues from a traffic light turning green to tell them it is safe to step off the curb into an intersection and walk across the road. Their guide dog is trained to watch for cars that aren’t showing signs of stopping. When the dog sees danger to their human, the dog is intelligently disobedient, and stays in a “sit” position, letting the human know that they shouldn’t step into the path of danger.

Judicious audacity is the intelligent application of aggressive boldness; that is, taking control of the situation in a fearless fashion because it is the effective and efficient thing to do.

Caveat emptor: there is a significant amount of risk inherent in many of these actions, though the payoff is high. Buckle up tight, fellow BAs, here we go.

Step 1. Exploit the Hidden Power in “Menial” Tasks
Step 2. Delegate!
Step 3. Compose in Real Time
Step 4. Define Gonzo Success Criteria
Step 5. Ask the Crazy-as-a-Fox Stupid Questions
Step 6. Get Their Attention
Step 7. Schmooze those Stakeholders
Step 8. Rat Out those Underachievers
Step 9. Speak Truth to Power
Step 10. Put on Your “Facilitator Flak Jacket”

We’ll cover the first four steps in this article. The remaining steps will be revealed in subsequent articles.

Step 1. Exploit the Hidden Power in “Menial” Tasks

We think that as we advance in our role, we shouldn’t have to do menial work. Tasks like taking notes or writing the first draft of a document or process may feel like they should be beneath us. Wrong perspective! Menial tasks aren’t always low brain power tasks; below are two examples of hidden power for the BA who can leave their ego at the door.

#1: Note taking and the power behind it

When you are the person recording the meeting minutes, you are in control of the official record of the decisions, action items, and open issues. Is the speaker making pronouncements in sentence fragments? You can stop the meeting and request that the speaker give you a statement that can be recorded. Does it appear that a decision has been made but you aren’t sure exactly what was decided? You can stop the meeting and request that someone give you a summary so that you can record it properly. Has an action item been agreed to? You have the power to suggest who should own that action item and what the due date should be. Is note taking a menial task? Hardly. You’re actually running the meeting and finalizing the decision making.

And, of course you are taking these notes directly in electronic form. Pen and paper is a luxury reserved for CEOs and poets; the rest of us have to be more efficient.

Before sending out the meeting notes, you should summarize the key points and decisions. Was there some fuzziness around a particular topic? Clarify it based on your business understanding or by contacting the Subject Matter Expert (SME). This is like stealth direction setting. And think of the visibility you have when you send around the meeting notes for comments and correction. Just be sure to have “recorded by ” in the meeting notes.

#2: Seize the moment: Draft the initial process/doc yourself

Do you ever get impatient with the lack of progress, or the inability of some people to get past a blank template? Start the document yourself and send it out to the team as a “suggestion”. The trick is to influence the process by presenting your ideas to kick-start everyone else’s thinking. Your natural BA instinct will be to try to get everything right before you show the document to anyone. In this case, though, you don’t need to get everything right because you are influencing, as opposed to analyzing; you’re pointing people in the general direction that you think is best, and encouraging them to build on top of your suggestions.

Step 2. Delegate!

Delegate? How am I supposed to delegate? I’m a single contributor, I can’t delegate; I get tasks delegated to me!

True. We BAs are single contributors, we don’t have the authority to delegate, but we have earned the right to suggest that a particular person or group should perform a task. In Step 1, above, there are two methods of “stealth delegation”:

You can delegate by recommending a person to own an action item from a meeting. If a person has special knowledge or interest in a particular area, it is appropriate to suggest they bring their expertise to bear on a task in that area. Minimally, you could ask them to draft a few slides or a couple of paragraphs outlining their ideas or concerns, which you can incorporate in the deliverable. They are likely to come up with some points you wouldn’t have thought of as well as being more invested in the success of the effort.

Delegate by putting a comment in a draft implicitly assigning a section by asking a question of a specific stakeholder, e.g., “Stakeholder A, do you have anything to add here?” Then follow up with that stakeholder both privately and publicly.

There’s also delegating by trading tasks – what can you do for the individual that you want to do something for you? This sort of “horse-trading” is a great way to leverage your own skills to obtain something you need, but can’t accomplish on your own.

In all these cases, be very clear about what you need from the person and when you need it. Follow up with them approximately half way through the time you have allowed for the deliverable to make sure it’s still on their radar. Be sure to emphasize that their special knowledge and input is vital to the success of the project and thank them for taking the time to contribute.

Step 3. Compose in Real Time

Whether you are doing a structured walkthrough of your BRD, or real time process development, when you have a live audience for work that is happening in real time under your fingertips, the pressure is on. This is one of the stages on which you earn your Bad-Ass BA performance award, if you are truly a master of your craft.

Let’s say you are using one of the many application sharing tools that allow people to see what is on your computer screen, no matter where in the world they are physically located and that you are revising the phrasing of a requirement that is giving people heartburn. Three people are talking at once. While you retype the offending requirement before everyone’s eyes, you get to say,

“Folks, let’s agree on who is the actor, here. Do we agree on that it’s the system? Good. Now, what was the exception condition that someone identified? Wait, what has to happen to trigger this requirement to come into play. One at a time folks! One at a time! Any conditions? No? Okay. Let me read this out loud to see if makes sense…. I think we want a different word, here, how about “configuration”? Any disagreement? Good. Now give me a moment to tune up the action … okay, please read this to yourselves. (count from one to five silently) Does anyone feel this does not express what we are trying to capture? Great. What’s the next one we need to work on?”

You own the stage, you clearly own the material, you are in the driver’s seat and you are getting the job done. Furthermore, you are putting pressure on the people who disagree to get their issues out in the open and resolve them by asking if anyone disagrees and explicitly making silence equal consent. The key is to determine when you’ve captured the meat of the idea and not let people wordsmith themselves to death.

How did you develop this skill? You’ve been taking notes in meetings (see Step 1, Point #1, regarding CEOs and poets) for years and doing the same thing; now you’re just doing it before everyone’s eyes and making it look easy.

Step 4. Define Gonzo Success Criteria

Slang: “gonzo” means conspicuously or grossly unconventional or unusual

As an exceptional BA, you should already have gotten all your project team members and stakeholders to focus on the success criteria for the project and the on-going process. Now take a dramatic step and get them to focus on the end customers’ success criteria for the on-going process. When you start doing this, the team members and stakeholders are likely to tell you that you are crazy and what you’re suggesting is impossible to do/measure/implement. Don’t worry, that’s a natural reaction to out-of-the-box thinking, and you are way out of the box.

The point of focusing on the customers’ success criteria is that we usually measure what is important to us, and what we feel is reasonable to measure. Too often, what we think is important is not what the customers consider important. Here are two examples to illustrate different aspects of this.

Scenario 1.

Airlines have determined that customers’ satisfaction is impacted by how long it takes to check in for a flight, so it makes sense to have a requirement that the flight check-in process be as efficient as possible, and to measure the time it takes to check in. It would be sensible and relatively easy to measure the time it takes for the counter personnel to key in the customer’s information and provide the customer with a boarding pass. If you are the customer, however, when do you start measuring the time to check in? Probably when you get in line at the counter.

So if there’s a 20 minute wait in line because the airline hasn’t staffed the counter properly, it may not matter to you that the time it takes the counter personnel to key in your information has been cut from 10 minutes to five minutes. Nor would you be impressed if they were able to cut it further to two minutes – you are still irritated by the long wait in line. The gonzo success criterion comes from looking at something that the airline doesn’t nominally control and may find difficult to measure: the amount of time spent waiting in line. Once you change your point of view to the customer’s, however, further improvement in the pieces of the process that you control may be wasted investment, compared to extending your control to other, more difficult to manage and measure portions of the process.

Scenario 2.

Software companies don’t want to give away support for their products so they generally require customer companies to pay for a maintenance license. When someone from the customer company calls in for support, the first thing the software company does is determine if that contact and company is entitled to support by checking that company’s “entitlement data”. It makes sense to the software company to make it as easy as possible for the customer companies to keep their entitlement data up to date, so the software company could have developed success criteria about how much time it takes the customer to update entitlement data. From the customer company’s point of view, however, there may be no reason to value entitlement data; the customer company just wants support, now. The customer’s success criterion is for the software company to “automagically” know that they are calling about a legal copy of the software for which maintenance has been paid.

Manual maintenance of entitlement data is just one possible way to meet that need. If the software company came up with another solution that led to the software itself automatically maintaining the entitlement data when it is deployed or updated, the customer would probably be delighted. But as long as the success criteria assumes that entitlement data must be maintained manually, the customers’ real needs are being overlooked. In this case, the gonzo success criteria requires ignoring the solution already in place and getting back to the customers’ underlying need.

As a business analyst, you are used to putting yourself in other people’s shoes to figure out what they want. Use that skill to add the end customer point of view to your requirements and metrics and you will increase your value enormously.

This is the first installment in a three-part series. The next installment will cover

Steps 5 to 8.

Installment 1

Business Analyst Times June 16/09

Step 1. Exploit the Hidden Power in “Menial” Tasks

Step 2. Delegate!

Step 3. Compose in Real Time

Step 4. Define gonzo success criteria

Installment 2

Business Analyst

Times July 14/09

Step 5. Ask the crazy-as-a-fox stupid questions

Step 6. Get their attention

Step 7. Schmooze those stakeholders

Step 8. Rat out those underachievers

Installment 3

Business Analyst

Times Aug 11/09

Step 9. Speak truth to power

Step 10. Put on Your “Facilitator Flak Jacket

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 [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, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].