Articles Archives - Page 368 of 417 - Business Analyst Articles, Webinars, Templates, Jobs

Connect the Dots; Five Tips on Requirements Traceability

Written by John Simpson on November 17, 2009. Posted in Articles.

As a business analyst do you ever feel like you are Russell Crow’s character in the movie A Beautiful Mind where it takes a genius to track and relate all the information you’re managing within your projects?

Welcome to the World of Requirements Traceability and Impact Analysis

In this article, our goals are to demystify traceability and its related concepts, and provide insights and examples for five tips to help you take control of requirements and keep everyone in sync. Traceability is a hearty topic, so along the way, we’ll try like heck to keep things educational and entertaining, such as other movie references to The Matrix and Quicksilver.

Have we piqued your interest? Read on my business analyst friends…

What the Heck is Traceability?

It sounds so clinical and complicated. Why do teams do it? It sounds like a lot of work. Is traceability really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important in one word: Change.

If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If change is managed skillfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the history, keep everyone in sync and (deep breath) consistently improve the quality of the products they’re building – every project, every release. Sign me up.

In some industries, traceability isn’t an option, it’s mandated. I’d recommend that regardless of the industry you’re in or the process you use – whether you’re building components for commercial airplanes using Waterfall or designing the next killer iPhone app using an Agile method – traceability is an industry best practice that will benefit your team greatly. But, like everything it comes with its challenges.

CHALLENGES

Swimming Upstream or Downstream without a Trace is Risky Business

You can probably relate to these scenarios. You get a great new insight from your best customer mid-project, and a high-level business requirement needs to change. How will this change impact the functional requirements your developers are working on right now? Your QA team just found a deal breaker of a bug in your most popular feature and you’re two weeks away from launch. Do you ship with the known bug or delay the launch? Who is working on that feature? Who else needs to be notified and weigh in on the decision? What else does it affect? These scenarios occur daily for development teams. So, how do you deal with them? How do you minimize risks and manage change effectively? One of the tools in your arsenal is traceability.

One common challenge that teams face in implementing traceability is the incremental time and costs involved. There’s no question that in order to do traceability well, there is a time investment that’s needed upfront to set up the trace relationships and configure coverage reports. However, the incremental costs incurred with using traceability are significantly outweighed by how much time and money you will save further along in the development process, due to the benefits that traceability provides.

BENEFITS

Traceability is Your Ticket to Greater Project Success – On Time, On Budget and Within Scope

For most organizations, the benefits outweigh the time required to set-up traceability by at least 2X. With a consistent process, structured templates and the help of a modern requirements management tool, much of the process can be automated and streamlined. Even if you opt to manage it manually, traceability offers several valuable benefits to your organization:

Minimize Risk. Assess risks and the overall impact of a change before it’s made
Control Scope Changes. Manage change throughout the process and avoid scope creep
Improve Quality. Ensure quality standards are met or exceeded to achieve industry compliance
Reduce Development Costs. Avoid gold plating and costly engineering rework
Increase Productivity. Keep the team in sync and reduce administrative overhead
Complete Test Coverage. Ensure all requirements are properly tested before a release
Greater Visibility. Gain end-to-end visibility into the process for the entire team and stakeholders
Accelerate Innovation. Cut product planning and developments cycles in half

TERMINOLOGY

Before we dive into the five tips, let’s take a moment to define a few terms.

Terminology	Definition
Traceability	Traceability is a sub-discipline of requirements management. Traceability documents the life of a requirement, tracks every change and links its relationships with other items within a project.
Trace Relationship	A link between items within the scope of a project, used to help assess impact on other items when a change occurs.
Upstream	Upstream relationships, a.k.a. backward traceability, look at the links between detailed functional requirements back up to the original customer need and high-level requirements captured. It’s used to ensure that the evolving product remains on track in regards to the goals of the product and what customers need. Helps to avoid scope creep and gold plating.
Downstream	Downstream relationships, a.k.a. forward traceability, look at the links between a high-level requirement and the functional requirements, test cases, tasks, defects and other items that support it. It’s used to ensure that you’re building the right product.
Traceability Matrix	A traceability matrix is created by associating requirements with the work products that satisfy them. Often it’s used to track tests associated with the requirements on which they are based and the product tested to meet the requirement.
Impact Analysis	Using impact analysis, traceability links between requirements, specifications, design elements, and tests are captured, and these relationships can be analyzed to determine the scope of an initiating change.
Version History	Used for change control, a detailed history of each version of a requirement, or other types of items, is documented and stored in a system of record, enabling complete audit trails used for change management over the lifecycle of the requirement.
Suspect Links	Suspect links help to manage the impact of requirement changes. A trace relationship (or link) becomes suspect after a requirement in the relationship changes. A suspect links report is often used along with Impact Analysis for assessing impact before making a change.
CMMI	Created by the Software Engineering Institute, CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. As it relates to traceability and requirements management maturity, see Levels 2-3.

TIP #1. It’s like the Six Degrees of Separation from Your Business Objectives (instead of Kevin Bacon)

Look at that, we managed to slip in a Kevin Bacon reference. It isn’t just because we’re fans of the movie Quicksilver, it actually has relevance here. As in many aspects of life, your product development success is highly dependent on relationships. All of the details such as user requirements, functional requirements, test cases and other items that define the scope of what you’re building are related in some fashion, either directly or indirectly. Here’s an example of a common process flow.

Using trace relationships you can connect everything together to map out the interdependencies between the different items. These relationships are the foundation for doing traceability effectively. As another example, here’s a screenshot of a Visual Traceability Layout showing both upstream and downstream items related to this requirement.

In addition, trace relationships are as much about connecting the people involved as about connecting all the items. Each requirement in the system has customers, stakeholders and members of your team associated with it. There are analysts who own defining it. There are developers building it. There is the QA team testing it. And, there are stakeholders and customers who care about its status.

When one item changes it has a ripple effect on other related items and the people associated with it. Keeping track of this ripple effect is crucial to the success of your projects. That’s one of key reasons to do traceability.

TIP #2. Mr. Anderson – Welcome to the Traceability Matrix.

Wow! And now a reference to The Matrix movie; we’re on fire. In all seriousness, a Traceability Matrix isn’t science fiction. It’s very real, and can be a valuable report for helping you ensure complete test coverage. For a manual example of a Traceability Matrix, you can build one in Excel such as this one courtesy of Joyce Ludwig.

ID	User Requirements	Forward Traceability
U2	Users shall process retirement claims.	S10, S11, S12
U3	Users shall process survivor claims.	S13

ID	System Requirements	Backward Traceability
S10	The system shall accept requirement data.	U2
S11	The system shall calculate the amount of retirement.	U2
S12	The system shall calculate point-to-point travel time.	U3
S13	The system shall calculate the amount of survivor annuity.	U3

This simple insurance claims system example shows both forward and backward tracing between user and system requirements. User requirement identifiers begin with “U” and system requirements with “S.” Tracing S12 to its source shows this requirement is problematic, and should be rewritten to support the processing of survivor claims or the traceability link corrected.

Here is an example of an automated Traceability Matrix generated from Contour. In this example, the matrix is reporting on the relationships between Features and Test Cases. This is useful to identify gaps in test coverage, which is a popular use of a trace matrix to ensure each feature is properly tested.

TIP #3. Impact Analysis – Your Virtual Crystal Ball into the Future.

What if you could anticipate the impact a change would have on your project and the entire team before it occurred? Would this potential change send the development team over the edge or would they have bandwidth to squeeze it into the next release? These insights are possible and the tool to get them doesn’t require a Weegie board or any magical pixie dust, just Impact Analysis. Impact analysis relies on the trace relationships you’ve set-up prior and reports on the complete picture of all the items that are affected – both directly and indirectly.

Here’s an example of an automated impact analysis report for a high-level business requirement. If it were to change, four directly related system requirements would be affected and one indirect use case would also be impacted.

Now if only we could apply impact analysis to other aspects of our lives, like the decision to have that second helping of pumpkin pie on Thanksgiving. What’s the impact on “project reduce fat tire”? Oops, better expand the scope on that one and push out the release date until New Year’s.

TIP #4. Version History – Your Complete Audit Trail in Rich, Glorious Detail. Whoohoo!

If you prefer things at a high-level and don’t like to dive into the details, look away. This tip isn’t for you. This tip on version history is for those among us that like to roll-up their sleeves and get deep into the glorious details of every little change. It’s also been humorously referred to as the “CYA tip”, for coverage of a different kind.

Personal motives aside, capturing a complete and detailed record of all changes is a critical element for reaching higher levels of requirements maturity within your process, such as CMMI. It’s also helps companies meet industry compliance standards in specific fields, such as aerospace and medical devices. One of the benefits of doing traceability is having a comprehensive audit trail of changes, so you can analyze who, what, when and why a change occurred. At the same time, you can easily roll-back to an earlier version if needed because it’s all stored in the unified system of record.

Here’s an example of seeing a side-by-side comparison of two versions, using an automated process within Contour. For efficiency gains, the specific field that changed is highlighted in yellow, so you don’t have to spend time hunting around the full requirements specification document to pinpoint and understand precisely what changed. Viva la details!

As with the other aspects of traceability, you can track version history manually through static documents using versioning. It’s just more cumbersome and time consuming to manage complex projects that way.

TIP #5. Avoid Noise. Communicate Changes Quickly, Intelligently and to Those Who Care

How often have you been involved in a project where “change notice paralysis” sets in after about two to three weeks of inbox overload? Usually it occurs when the entire team is on a project-wide distribution list and the project manager is on the hook to send out an email with the complete 200-page Software Requirements Specification document attached for every little change that occurs. Right intention, wrong solution. What happens next? People waste time hunting around in the requirements spec, trying to determine if the latest change is relevant to them, which is costly. Or, they tune out the email barrage as noise and become vulnerable to missing a change that is important to what they’re working on, which is also costly.

There are smarter ways to keep everyone on the same page. You need to ensure that everyone impacted by a change is in the loop. At the same time, you don’t want to flood the entire organization with emails. What do you do?

In this example using Contour, when a change occurs, you can instantly send a direct link to the specific requirement that changed with version notes to just the relevant groups or individual users that are affected by it. The notification step is then part of the overall change management workflow. Stay in the loop. Avoid noise.

Let’s Automate!

You can manage traceability manually using Microsoft Word or Excel documents. That’s a real option. For small teams and simple projects, that’s probably all you need. We’ve provided links to a few free templates courtesy of industry experts that you can use to manage traceability manually:

Traceability Matrix Template (.xls) from the CDC.gov, requirements management templates
Impact Analysis Checklist (.doc) from Karl Wiegers, Process Impact

The challenge with a manual process is it can be extremely time consuming and cumbersome if your projects have any level of complexity – meaning you have many requirements, frequent scope changes or if members of your team are remote working from different locations. In these scenarios, automation can provide a huge boost to productivity, saving you valuable time and money. Automation also minimizes the risks of human error.

What’s the ROI?

The return on investment is different for every company, but through our experience, we’ve seen as high as a 42:1 benefit-to-cost ratio for a global entertainment company. For most organizations, as a conservative benchmark, you can expect to speed development cycles by 50% and improve quality by 2X or more within the first six months, using a requirements management application.

Take Action!

Concepts are nice, but actions are what matter most. Take action today to become a traceability master.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 14 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware

Secret Public BA Shames. Part 2.

Written by Marcos Ferrer on November 17, 2009. Posted in Articles. 1 Comment on Secret Public BA Shames. Part 2.

Last month’s column generated a huge response – a nerve has been struck!

Responses to the “database check data poking” controversy ranged from (I paraphrase here) “the project manager may know something you don’t” to “even without hard evidence, you should try to make the auditors aware”.

The solution, I think, is for the auditor to receive an anonymous invitation to talk to the project manager, so the project manager can share what they know, since they won’t share it with the BA. How the BA keeps their job (or gets any future job) by doing this publicly is not clear. For it to work, there has to be an anonymous way of reporting concerns. Let’s be frank – whistleblowers are punished, not rewarded, even when they are reporting serious offenses.

FREE IDEA from the “Ideas are cheap” department. A web page could invite people to send letters (yes, snail mail) expressing concerns. These letters could remain completely private, and be destroyed after receipt. The concerns expressed would be posted anonymously on the web page by hand, and forwarded to appropriate agencies. The “poster” would have no liability, and no responsibility for content, and the whistleblower would have a chance to do the right thing while escaping punishment. And the offender would have a chance of seeing themselves online, just like when Ann Landers published anonymous letters.

OK, deep breath – “Situation #2”. The case of “who cares about inventory?”

A large institution manages a huge portfolio of physical assets – buildings, tunnels, underground assets, vehicles, etc. They do not have an accurate inventory of these assets, and have not felt able to apply the resources to resolve the issue. They ARE aware that the situation is undesirable, but have never quantified the costs, nor have they estimated the benefits of correcting the situation.

Enter the BA, who is asked to make a business case for managing these assets.

In the early stages of elicitation, it was discovered that contractors hired by the institution were expected to perform “exploratory engineering” (to determine what assets are really in place) before they begin actual work. This “exploratory engineering” was performed after the contract was awarded, and often resulted in change orders, which tended to be more costly than if the work had been bid properly.

When asked about the financial benefits of having an accurate inventory of assets, and the possibility of saving money on “exploratory” work and expensive change orders, the manager in charge said (I paraphrase) “It’s just part of doing business, they all know they have to do it (exploratory work)”. When asked if contracts would be less expensive with proper asset management, the manager replied (again, I paraphrase) “That doesn’t affect me”.

Just to make sure, I followed up a few days later with some more questions, but got the same sort of avoidance.

This took place in the context that asset management had been identified as a strategic objective of the agency. This manager did not, could not, or would not care about the possibility of using resources better.

OK, brilliant readers – three questions:

What could possibly have been on this manager’s mind?
Is there an ethical concern?
Why or why not – what factors would affect your decision?

NEXT MONTH – another situation – send yours, if you know of one!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

Think “I” instead of “We” when Talking about Your Business Analyst Career

Written by Laura Brandenburg on November 10, 2009. Posted in Articles.

Picture yourself in an interview for your dream business analyst job. You are confident in your qualifications. You have prepared for the interview by researching the company, the hiring manager, and anyone else with whom you are meeting.

The manager asks you a few questions about your experience with a focus on business analysis. You answer confidently about how your team accomplished exactly what they were asked to do. You give an example. But the manager still looks at you a bit puzzled and probes for more information. She or he doesn’t seem to fully trust your answer.

One possible cause of this situation is that you are using “we” in your answers instead of “I”. You are a team player. You know that as a business analyst you help teams achieve great results. You focus your answers on what the team accomplished. This is a great way to look at your day-to-day work. But in an interview situation, the hiring manager is interviewing you not your team. Answers talking about “we” seem vague, are ambiguous, and can leave the impression that you are avoiding the questions.

From my own personal experience as a hiring manager for business analysts, one particular candidate among the many I interviewed with the “we” tendency, stands out among the rest. I share his story to help the other candidates out there who may unknowingly be facing his same challenges.

The candidate’s answers to my questions revealed a strong team orientation and other professional qualities that I respected and desired, but when it came to his BA qualifications, I couldn’t quite nail him down. In answer to every question about every project, he started the answer with “we”. We created a requirements document. We came up with an elegant solution. We implemented a successful project. We, we, we.

Truly liking the individual, I started probing and prodding then finally asked, “I understand what your team accomplished and that’s great. It’s important for me to understand what you contributed. What did you do, specifically, to help the team accomplish that success?” Unfortunately the candidate failed to come up with an answer and defended his “we” stance: “My contributions were only part of the team. That success was impossible without the whole team.” Although my gut said he was a good candidate for the position, I couldn’t validate his BA qualifications with any hard evidence. He was not hired.

I want to help you avoid this same shortfall. The difficulty is that his answer is true and valid. We accomplish more as part of a team. No matter how we think about it, we are not solely responsible for the outcomes we achieve as part of a group. But the career-defining questions remain unanswered: What did you do? Why should I hire you? Why should I believe that you will make a contribution on one of the teams in this organization?

In preparing to speak about what your team accomplished and what you contributed to help your team succeed, it can be helpful to keep a catalog of your projects and accomplishments. For example, let’s consider a requirements document. There is no doubt that significant project documents, such as a business requirements document or functional specifications, are the result of contributions from many individuals. When evaluating this experience for your contribution, think about the following activities:

Did you author the document? Alternatively, did you edit a document started by someone else?
Did you solicit feedback on the document and collate comments and reviews?
Did you elicit the requirements and ask the questions that ensured the document was complete?
Did you facilitate the meetings, pointing out disparate input or conflicting requirements?
What else did you do?

While the document you produced is the collective output of the team, it’s likely you had a very distinct role in that accomplishment. Catalog your specific contributions and be prepared to speak about them in detail.

Alternatively, if you were part of a BA team, you might consider quantifying your part in that team. For example, if the team collectively produced 50 use cases, maybe you drafted 20 of those use cases and provided critical feedback on the other 30. Can you think of an example where your feedback addressed a problem no one else had considered? Maybe you owned a part of the review or approval process. Maybe you owned the use case list and model.

Another way to think about this concept is to answer the following question: What hole would have been left if you had been plucked from the team? Looking at the team trying to achieve its objective without your efforts, analysis, and influence can help you see the situation with a fresh set of eyes. It can help you identify your slice in the team’s overall effort.

It’s also possible to use this approach to explaining your experiences while still showing you are a team player. One of the line items on my resume talks about a career experience from my early days as a QA engineer. I entered into a situation where developers across two different locations were often at odds with each other about the root cause of defects and who should fix them. I partnered with the developers from the other location, began testing their output directly, and helped drive more effective communication between the groups.

In my resume, I speak about breaking down communication barriers to reduce the length of time it took to resolve a particular category of defects. Of course, I did not single-handedly fix the issues, nor was I the only contributor to the improved success of this group of people. Every member of the team had a critical role in that improvement. But I am confident in calling myself out as the catalyst and talking about my role in bridging the communication gap, an accomplishment that helped carve my path into the business analysis profession.

So I ask you. What do you have to say for yourself and your career? Are you a career casualty to the ambiguity of “we”? If so, I challenge you to start a catalog of your recent projects and think long and hard about your contributions. This is a great step to take to advance your business analyst career.

Don’t forget to leave your comments below

What?! You Don’t Want to Be a Project Manager?

Written by Kupe Kupersmith on November 10, 2009. Posted in Articles. 1 Comment on What?! You Don’t Want to Be a Project Manager?

In my last blog post, Mr. Business Analyst, You’re Not a Good Fit!, I discussed three characteristics you should look for in a business analyst. It sparked great conversation and some of the comments inspired this blog post. I stated one of the characteristics hiring managers should look for in a BA is passion for the BA profession. A reader commented, in so many words, that if they feel a candidate is looking for a BA role to get their foot in the door so they can get a PM role later, they shy away from them. Another reader has a manager that wants her to take the PMP exam because it is more popular.

These comments reminded me of what I was up against earlier in my career. A company I worked for had a career path where a Sr. BA “grew up” to be a Junior PM. Many companies still have this approach, and I stand here today saying “this needs to change!” This is a clear indicator of the lack of understanding of the role and/or value an organization puts on the importance of business analysis. In this post I want to highlight the impact on an organization with this career path.

BAs Stop Being BAs

Once a BA is promoted to a senior level all the good stuff starts to happen. It’s like a properly aged wine. At this point, the BA has had enough experience to feel comfortable on most projects and can be a valuable mentor to junior BAs. Unfortunately the BA does not age as anticipated when their next promotion is to a project management role.

What do people do shortly after they get promoted? They look at the next level and see what they need to do in order to prove that they can do that job. If a Sr. BA’s next step is project manager, they will tend to focus more on PM related activities and not as much on the business analysis side. An impact is that organizations always have more junior level staff performing most of the business analysis work. This leads to less than stellar analysis, customers are not satisfied and projects are less successful. The impact is huge in terms of customer satisfaction. I have seen this happen, it’s ugly.

All BAs Do Not Want to Be PMs

Some BAs want to be PMs and I think that is wonderful. Personally, I love when my PM has business analysis experience. So, a target for BAs should be a PM role, just not the only one. If it is the only one, organizations end up only with people in that role that do not want to be PMs. By nature, people want to move up that ladder. They’ll do what is necessary to convince management that they want to be a PM, but they’ll be miserable.

This leads to less than stellar project management; customers are not satisfied and projects are less successful. Do you see the pattern? I did an informal survey two years ago and asked BAs with a PM only career path if they wanted to be a PM. Of the 30 I asked, six said yes. That’s just 20%…yikes! But, almost all of them would take the promotion because it meant more money and a notch up the ladder.

Other Options

That the PM route should not be the only career path, it is only fair I share my thoughts on otherr options. They’re not straight forward and, unfortunately, may give HR professionals heartburn. A big factor is the desires of the individual BA. With a BA skill set (problem solving, analytical thinking, facilitation, consensus building, focus on business value, relationship and team building, etc.) individuals can take one of multiple paths. For those that want to be in the IT space, a potential path can be Jr. BA, Sr. BA, BA Lead, BA Manager, Director, VP, CIO. Additionally within IT, BAs can move into a business architect position and/or strategic business analysis role where they look across the company to help determine the best projects to pursue to maximize business value. BAs can also move into the lines of business. As a BA you gain valuable information about the business goals, operations, and areas for improvement.

In the end, individuals with a BA skill set have more to offer than just becoming project managers. I also believe BAs with project management skills are better analysts. A future post will address that concept. Organizations need to offer BAs a variety of growth options to maximize their skills. Having a single path can lead to a less productive workforce and attrition. BAs who don’t want to be PMs will eventually leave.

To our continued growth,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

Bad Ass BA; Peer Review. Part 3.

Written by Cecilie Hoffman on November 10, 2009. 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:

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check (In this issue)
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 3^rd 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

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check
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].