5 Common Business Requirements Mistakes and How to Fix

Them
Author: Amanda Bennett
December 2013
In my work as a senior business analyst I am often asked to review business requirements documentation that has been written by someone else
or mentor other individuals as they write business requirements. While a person may be very knowledgeable about the subject matter contained
in a business requirements document, it doesn't necessarily make them an expert in documenting their knowledge to the people who have to
work with that document in a useful and meaningful way.
The effects of a poorly written business requirements document can be disastrous to a project. It can lead to:

inconsistently understood or misunderstood requirements from one stakeholder to the next,

disagreements and tension among stakeholders who have differing expectations for the project deliverables,

requirements that get missed entirely until after the project has been launched,

re-work and re-design for developers, leading to additional stress and frustration, particularly if this re-work and re-design has to take
place after project launch in an emergency situation and

damaged reputation with stakeholders who no longer have faith in your ability to understand their needs.

Fortunately, these pitfalls can be avoided with just a little awareness and effort on the part of the writer of these requirements. A good place to
start on this journey of awareness is with the tool that is being used to write up the requirements. I provide a business requirements template to
those that I have assisted in some way in writing their requirements, and I will meet with them to explain how to use the template and to discuss
any questions they may have. Using a template with the people that I have assisted puts us on a level playing ground, so that I at least know the
intent of all the sections of the document, and it gives a greater consistency to the documentation I have to review.
Assuming this groundwork has been laid and my client has put together a set of requirements using this template, I have a standard list of
mistakes that I see frequently and that I will be on the lookout for when I begin reviewing the requirements. It is this list of mistakes that I would
like to elaborate on here in the hopes that it might help others out there navigate their way through the requirements jungle.

Mistake #1: Forgetting to Consider Your Audience

Once the written requirements are sent to me for review, I start by scouring the document to look for acronyms and business terms that have
been too loosely defined, or even not defined at all. Unfortunately the use of acronyms has become brutally de rigueur in the workplace, and while
it might quicken our speech or writing inadequately explained acronyms can be detrimental to the overall understanding of the topic being
discussed. The writer isn't trying to exclude anyone from understanding their requirements, but they forget to consider the audience for the
document they are writing. That's easy to do when you have become accustomed to working with the same group of people for years, but when a
new project rolls around that group of people you are interacting with will likely change and you can no longer assume that everyone will
understand these terms and acronyms in the same way that you do. Clear and unambiguous definitions of business terms and acronyms are
especially important to the developer as they can have important implications to the architecture the system.
I will give you a real-world example of how an inadequately defined business term caused a developer to have to modify a new system after
project launch. A few years ago I was involved in a project that allowed students at a higher education institution to apply for a co-op placement
online. It was formerly a manual paper process. During requirements gathering a co-op student had been defined as a student who was enrolled
in a co-op program. That definition seemed to satisfy everyone at the time but once the system was moved into the live production environment
calls started coming in saying that some students were not able to access the system. After some investigation it was discovered that the
developer had designed the system under the assumption that the definition for a co-op student referred to the current term only. As it turned out,
the co-op business office was willing to accept applications from students from previous terms as long as they fell within the current academic
year. This seemingly minor detail forced the developer to scramble to modify the system to allow these additional students access to the system.
Fortunately, no money was lost by this oversight, and the problem was rectified within a reasonable amount of time, but it demonstrates the
importance of properly defined business terms.

Mistake #2: Omitting the Alternative Paths and Variations to a Process

A non-automated, manual business process lives in a very different world than an electronic, automated process. When something unusual
happens in a manual process a temporary work-around to resolve the issue can be implemented fairly easily, having only a minor impact on the
business. If an unexpected situation occurs in an electronic system it can result in system failure: a major business impact. To reduce the
likelihood for unexpected situations, I pay close attention to all process diagrams and process narratives because it is a very common mistake to
omit the alternative paths to a process. People often assume that because the process usually happens a certain way they don't need to mention
the other rare scenarios. There is also a tendency to avoid describing all the what-if scenarios because people assume these details can be
worked out later by the developers. To some extent that's true, but at what cost? Trying to build in all the alternative paths in a process after
development is underway can bury your project in months of unanticipated work. Fully fleshing out the process in the planning stage will save

everyone this headache, so it is well worth the effort. Be prepared to have to do some coaxing with your clients to get them to this level of detail.
Once I have spotted some problem areas in the process diagrams I start asking my client some triggering questions such as "What happens if it's
not approved here?" or "What happens if the user cancels the process?" Questions like these often result in the discovery of several forgotten or
ignored steps, and in some cases my client may not know the answer at all. This is ok, it just means we have to go get that information to
complete the process diagram.
After a few iterations of this the client usually gets the idea and can continue on revising the process diagram without me since they now know
what to watch out for. Developing that critical eye may feel awkward at first but once you get it started it's hard to shut it off!
Don't assume all your work is over as soon as you have identified all the alternative paths to a process. Something else to watch out for when
mapping business processes is whether the sampling of clients who are working with you to map out the process can truly speak for all
participants in the process. Is there more than one business area interacting with the process? Do you have a representative from each area? If
not, take the time to speak with each area. You may be surprised at how much variation there is in how the process operates from one area to the
next, and project stakeholders need to be aware of these variations. They will need to decide whether the new system needs to be flexible
enough to accommodate these variations or whether some business processes need to be adapted to fit the new system.

Mistake #3: Requirements Buried in Long, Wordy Paragraphs

When I am ready to dig into the detailed requirements, there are a few things I'm on the lookout for. First of all, what I don't want to see are long,
wordy paragraphs with several requirements buried in them. This is a phenomenon I like to call "requirements soup". It may feel more natural to
write like this, but not only is it difficult to discern requirements written this way it also greatly increases the likelihood that a requirement will be
missed somewhere along the way, most likely during the development or in testing. Moreover, nobody wants to have to read a novel when they
are reviewing requirements. You will lose the attention of your stakeholders quickly when trying to review requirements written in this fashion, and
that introduces the risk that they may not understand or be aware of all the requirements, which makes requirements sign-off a moot point. Lastly,
it's difficult enough securing the time of project stakeholders without spending unnecessary hours sifting through page after page of this
requirements soup. It is wasting their time and yours and your stakeholders will not appreciate it. A much safer practice is to write each individual
requirement separately, give it an identification number, and keep them worded as succinctly as possible. That way, even if a requirement does
get missed during development, it should get picked up in the testing. To ensure that test scripts properly test all requirements, each test script
should clearly indicate what requirements it covers. In addition, a requirements matrix should be constructed to ensure coverage and proper
distribution of the requirements across all test scripts.
For an example of how to take a paragraph of requirements and convert it to individually numbered requirements statements, take a look at this
paragraph combining several written requirements:
"When the user submits a new application, an email gets sent to the user to confirm their application was submitted successfully. In addition, the
status of the application should be changed to "Pending". The approver is also sent an email indicating that a new application is pending their
approval."
If we were to separate this paragraph into distinct requirements and identification, it could be written like this:
1.0 New Applications
Upon successfully submitting a new application, the system shall:
1.1 Send the applicant an email to inform them that their application was submitted successfully.
1.2 Give the new application a status of "Pending".
1.3 Send the approver an email indicating that a new application is pending their approval.
If the new application is not submitted successfully, the system shall:
1.4 Send an email notification to the applicant indicating that their application was not submitted successfully, with instructions for how to contact
technical help.
1.5 Send an email notification to the technical support team to notify them of the problem, with error details, if available.
There is also a business rule buried in the original statement; the rule for what constitutes a successful application submission. This may be
documented in a business rules section of your document, in a format such as the following:
1.0 New applications
A new application that has been submitted successfully must accomplish the following:
1.1 All information entered on the form is saved to the database.
1.2 The applicant has been notified of their successful application submission.
1.3 The next approver has been notified of the pending application.
Separated and numbered in this way, each requirement becomes clear, distinct, and testable, not to mention, much easier to read: an important
factor in the success of the project.

Mistake #4: Losing Track of the Original Goals of the Project

To establish an effective numbering schema for your requirements, structure it so that there is a clear link between the in-scope deliverables or
goals laid out in the project charter, and the detailed business requirements. This is so important, because people can and will forget (perhaps
conveniently sometimes) the original goals of the project, and before you know it, the scope of the project has grown exponentially. Believe me
when I say, this is a crazy train that you do not want to be a passenger on. To create the linkage between the project requirements and the
project charter, I will assign an ID to each of the in-scope deliverables, and use them as the "parent" IDs for the detailed "child" requirements.
That way you know where each requirement is coming from.
Here is a list of in-scope project deliverables from a project I was recently involved in:

ID

Title

General System Deliverables

1.0

Application Processing - Employee interface

1.1

Active Requests

1.2

Application Summary

1.3

Application Details

1.4

View/Upload Supporting Documents

1.5

Postpone Application

1.6

Cancel Application

2.0

Application Processing Administrative interface

2.1

Approvals Dashboard

2.2

Pending Applications

2.3

Application Details

2.4

View Supporting Documents

2.7

User Access

2.8

Application History

For the detailed project requirements, each of these deliverables is used as the parent requirement, with several detailed child requirements, for
example:
1.1 Active Requests -The purpose of this area is to allow the applicant to view all their active applications in a condensed view.
1.1.1 If there is more than one active application for the applicant in the system, the system shall display all applications for which the end date
has not yet passed in a condensed list.
1.1.2 If there is only one application in the system for this applicant, the system shall proceed directly to the application details.
1.1.3 The system shall allow the applicant to view the full details of any application by selecting it from the list.
1.1.4 The system shall provide the means for the applicant to sort by any of the columns appearing in the list.
When you encounter a requirement that you are unable to clearly link back to the project deliverables you can try to seek clarification from your
project stakeholders. If after doing so you are still unable to establish a linkage, report it to the project manager as this could very well be a case
of scope creep, and that is the responsibility of the project manager to resolve. If you are given requirements that you believe to be outside of the
scope of the project, it is important to let the client know that you are unable to confirm whether or not these requirements will be included in the
project. At the same time, capture all the details of the requirement so that you can report it appropriately to the project manager. As a Business
Analyst it is not your job to make the call as to what is in or out of scope of the project. Your job is to capture the details of the requirement and

keep track of the source of that requirement so that scope creep can be monitored effectively by the project manager.
If a formerly out of scope requirement is brought within scope of the project, you will need to append it to the list of in-scope "parent" deliverables
so that new detailed requirements can be linked to it appropriately. Conversely, if it is decided that a requirement is out of scope of the project you
should still keep track of it in an "out of scope" section of your document, along with the reason why it was deemed to be out of scope. Too many
times I have seen stakeholders forget that a requirement was decided to be out of scope, or the reason for it. Keeping track of the history of these
requirements will save you the trouble of having to re-visit the requirement with the project stakeholders. Requirements are in a constant state of
flux with the majority of projects, and that's fine as long as you keep track of the decisions on them, trace them to the project goals, and update
your documentation accordingly.

Mistake #5: Designing the System

It is tempting to start fussing over the design details of a system because it's more fun and easy to talk about the fonts, colours and layout of a
screen than it is to talk about how it's supposed to work. While I am very much a fan of using mock-ups in requirements documentation, I use
them with a high degree of caution. Mock-ups should be rudimentary in appearance. Skip the fancy logos, fonts, or buttons and keep just the
basic data input/output elements of the form. Your goal is only to portray a concept for how the process will work in the new system for the visual
stakeholders who may not fully grasp the written requirements. The problem with making mock-ups that look pretty is that your stakeholders may
be too distracted by the design to focus on the functionality of the screen.
Another caution about mock-ups: avoid implying requirements in your mock-ups that are not described elsewhere in your documentation. What
appears in your mock-ups should also appear in the detailed textual requirements. If it doesn't, the developer will no longer have a reliable source
for the requirements, you will lose your ability to trace your requirements to the project goals, and it will be impossible to ensure that you have the
appropriate requirements coverage in the test scripts. In one set of requirements I reviewed some time ago, I noticed in the mock-up for one of
the screens there was a field that appeared to be a calculated total of some other fields in the form, but no verbal description had accompanied
said field. When I asked the writer about it, his explanation went something like this, "Oh it's just the sum of those other two fields on the form.
Just look at the values. You can see they add up." In this case, the writer had assumed that the purpose of this new field was obvious. The
problem with making assumptions like this is that now you are asking your technical architect not only to read the textual requirements of the
system, but also hunt and peck their way through the mock-ups and compare it back to the textual requirements to see if anything is different that
what was described. It also causes a headache when creating test scripts, since there is no specific requirement associated with these
undocumented fields.
When reviewing requirements documentation I also watch out for textual requirements that delve too deeply into design details without properly
explaining the need behind it. This is a risky thing to do because when describing design details as a part of requirements you limit the technical
architect's ability to design the best system to meet the client's needs. That said there may be cases where a specific design is warranted, but the
reason for that should be explained clearly. There are, in fact, some people who feel that requirements should not contain any design details at
all, and only state the need. Others feel that not only is it ok to include design in the requirements documentation, but they fully expect it. This is a
contentious issue that I will not attempt to resolve here, but suffice it to say you should do your homework before you start writing your
requirements. Find out what the practice has been in past projects, and what is expected of you now.

Conclusion
The five mistakes I described above represent the most common mistakes that I see when reviewing business requirements written by others.
The first mistake I described was forgetting to consider your audience when writing your business requirements. Avoiding the use of acronyms
and taking the time to define business terms in a way that all readers should be able to understand clearly is a worthwhile defense against rework and re-design later in the project.
The second mistake was omitting the alternative paths to a process. While a given process may run a certain way for the majority of time, that
doesn't mean you can ignore all the less-frequent scenarios when you move to an electronic process. In fact, it's these other scenarios that can
bring an electronic process to a grinding halt if the system isn't flexible enough to handle them. To give the developer the opportunity to build in
these other scenarios, you will need to take the time to fully flush out all the alternative paths to each process in your business requirements.
The third mistake was burying multiple requirements in paragraphs of text. For people who are new to writing business requirements, it seems
only natural to write business requirements as if you are writing a story, with long paragraphs describing the behaviour and functionality of the
new system. However the goal of the business requirements document is not to tell a story. To convey the understanding of your requirements,
each requirement must be written distinctly and concisely.
The fourth mistake was losing track of the original goals of the project. The business analyst should always become well acquainted with the
project charter when writing the business requirements document, and in fact, the in-scope items, or deliverables, listed in the project charter
should be incorporated into the business requirement document. My preferred way of doing that is by making each of the in-scope deliverables a
"parent" requirement, with the detailed requirements for that item becoming the "children" to that parent requirement. This method can go a long
ways to preventing scope creep.
The fifth mistake was building too much design detail into your requirements in the form of frilly mock-ups or very specific user-interface
requirements. For many people, it's easier to draw a picture than it is to explain something, and the same goes for business requirements, but
with the many pitfalls that can result from this habit it's important to simplify those mock-ups and ensure that all their elements have been fully
represented in the accompanying textual requirements.
Avoiding these mistakes will save you and your project team much time, effort, and frustration. Of course, mistakes can be a valuable learning
opportunity, but hopefully with this article I can present the learning opportunity to you with no mistake required!

The Review Panel

IIBA and the author would like to thank the review panel for their critiques, insights, and thoughts on the development of this article.
The review panel for this article was:

Teri Stubits,
Xin Li, and
Margaret Fong.