BUILDING QUALITY INTO BUSINESS REQUIREMENTS:
COMMON MISCONCEPTIONS AND THE TOOLS TO OVERCOME THEM
Tammy Adams, CPF, CQM
Chaosity LLC
8611 S. Kachina Dr.
Tempe, AZ 85284
480-775-8756
www.chaosity.com
tadams@chaosity.com
Janet Means, CPF
Resource Advantage, Inc.
284 Ford Road
Melrose, NY 12121
518-663-5232
www.resourceadvantageinc.com
jan@resourceadvantageinc.com
SUMMARY
Building quality business requirements does not come naturally. This paper addresses common misconceptions
regarding the building of good business requirements and provides recommended tools and techniques for assuring quality is
built-in. We will identify six common assumptions that contribute to poor quality business requirements. Guidelines are
presented for good business requirements, and several tools and techniques are recommended. We also include tips from
companies successfully using these techniques.
INTRODUCTION
Your project has started off with a bang! You’ve formed a team, you have a plan, you know your charter and now
you’re ready to build the business requirements for your project. But wait…what are good business requirements? How do
you know if you’re capturing the right information? And what do we mean by “building quality into business requirements”?
Business requirements capture the shared vision of what the solution needs to do in order to satisfy the customer and
business needs. In other words, it describes the “what”, not the “how” of the solution and reflects agreement between
sponsor(s), operations, project team, and key stakeholders. These requirements will serve as the foundation for the next steps
in the project lifecycle - designing the solution and building the test scenarios – and should contain (or at least reference) all
the information the engineers, developers and/or designers will need to understand what needs to be designed and what is
different from that which exists today.
In our experience with companies across the globe, we’ve seen the good, the bad and the ugly. We’ve seen business
requirements that are too general, too explicit, and totally ill-defined. So, obviously, writing good business requirements in
not an innate skill. Let’s look at some misassumptions around building requirements, guidelines for good requirements, and
a few tools to help you get there. While our experience has centered on projects requiring Information Technology
development or support, these concepts just as easily apply to other less technology-related types of projects such as
construction and product projects.
COMMON ASSUMPTIONS THAT LEAD TO POOR QUALITY
#1 – The Business Partner (or Customer) Knows What They Want. Are you kidding? Like most people, they
know what they don’t want better than what they do want. Your business partners or customers may have a vision, but they
typically may not know how to articulate the details of that vision in order to bring it to reality. So assuming that your role is
simply to gather requirements from various impacted parties and consolidate them into a “requirements document” is flawed
and may produce unintended results like that shown in the follow tire swing illustration (Figure 1).
Figure 1 – Tire Swing
#2 – Requirements are just a High-Level Wish List, so it Shouldn’t Take Much Time. There are two
misconceptions here that need to be addressed. First, comparing business requirements to a high-level wish list is like saying
all you need to know to build a house is that you want 3 bathrooms, 3 bedrooms, a kitchen and living room. Are all
bathrooms fully equipped with bathtub, shower, sink and toilet? Are the bathrooms adjacent to each bedroom or is one a
stand-alone guest bath? Are the kitchen and living room shared space or separate rooms? Did you forget the dining room or
was it intentionally left out? And this is just the beginning of the questions! Good business requirements should start with
the high-level list and drive it to the detail needed to design and build the solution.
Second, is the assumption that building requirements should be a quick effort. Just give me a list and we’re done.
Recently Best Practices, LLC conducted a benchmarking survey to be a directional indicator of project management trends1.
Their study was designed to understand the project performance of companies that are renowned for their project
management operations. Most of the companies surveyed tend to conduct more than 100 IT-related projects a year, with
21% conducting more that 150 business projects per year requiring IT components. Findings regarding what were the most
significant causes in project delays included “incomplete business requirements”. Inadequate input from technology
resources during early phases was noted 26% of the time. In life we’ve found that planning for an event takes more time than
the event itself - if the planning was done well. Requirements are no different. If you spend the time here, downstream
rework, waste and change controls will be minimized and the resulting product or service will actually be what was planned.
#3 – Gathering Requirements via Email is an Efficient Use of Time. If you’ve been a Project Manager for any
length of time in this electronic-world, you already know this to be a myth. First, most environments are so overwhelmed
with high priority tasks that your request may be put in the “to do” in-basket with numerous others. Getting information in a
timely manner can be challenging. And, second, when you do get it, it may not be the quality of the information you needed.
You often wind up with more questions than answers. Plus you’ve created the potential for conflicting requirements across
respondents with no easy way to resolve the conflict.
#4 – We Don’t Need to Talk About It, We Know What That Means. No good developer would create a product or
service without clearly understanding its intended function and use. And neither should we assume that one person can fully
provide that knowledge. Whether you’re developing a new technology application, created a new product or building a retail
store, a shared understanding between owners, users and those creating the end product or service is necessary to achieve
success.
We’ve occasionally encountered resistance when proposing a “team approach” to requirements development. But
usually a simple illustration makes the point for us. We simply ask one team member to describe how they see the new
process, product or service working. Before they’re done usually one or two others have jumped in to disagree or alter the
description. Your perception of what’s needed and mine may be two different things – but we’ll never discover that until we
get together and discuss the need and the solution.
#5 – If We Know the Solution, We Don’t Need to Document Requirements. Have you ever heard these justifications
for skipping the requirements building process?
“We’re going to purchase a vendor package, so we don’t need requirements”.
“We’re not changing how it works, just what it does”.
“We’ve done this numerous times before so the requirements should already be there”.
“We’ve already told them what we want”.
We all love to solve problems. In fact, give us a problem and we’ll come up with multiple ways to fix it. But identifying
possible solutions doesn’t describe what’s needed. They are two different things. In order to determine if the solution meets
your needs, you still must define what you need (a.k.a. your requirements).
#6 – All Requirements Have the Same Importance. If you live in Maine, it may be more important to you that your
home has a high efficiency heating system than whether it has air conditioning. If you live in Arizona, that view of what is
important may change. It is essential that all requirements be prioritized to allow businesses the opportunity to make
decisions regarding the solution. Prioritization of requirements helps the business sponsors make appropriate cost / benefit /
time trade-off decisions. Prioritization of requirements also enables intelligent choices with respect to multi-generation
implementation of the comprehensive solution.
GUIDELINES FOR BUILDING QUALITY BUSINESS REQUIREMENTS
As we stated before, building good business requirements is not innate. It takes education and practice. First, you must
understand the purpose of business requirements. No, they are not an exercise in tedium intended to make your project team
break out in a cold sweat. They are a way of clarifying the project vision and scope. They make it tangible. As you develop
requirements, you confront issues and make decisions around what the resulting product or service will be. You are, in fact,
building the blueprint that will guide the design.
Business requirements are called “business” requirements for a reason. They should reflect the perspective of the
business- what the business needs the solution to do or provide. They are not the intended to indicate how the solution will
be implemented or the technology that should be used.
Second, choose your role in the requirements process. Project Managers have often viewed themselves as coordinators,
managers and overseers. But in the requirements process a new role comes into play – the role of Facilitator. If the Project
Manager chooses to play this role, they become an enabler. The Facilitator does not drive the team nor set business direction.
Rather he or she works closely with both the team and Project Sponsor to craft requirements work session objectives and lead
a set of activities that will pull together the right experts to dialogue, decision, and create the requirements that are critical to
project success.
This type of facilitation requires some specialized skills which the Project Manager may or may not possess. But
ultimately the decision about whether the Project Manager (or someone else) should facilitate comes down to an assessment
of objectivity, skill set, and freedom.
During the work session, can the Project Manager be objective enough to:
Set aside their manager hat and serve as a neutral process guide?
Allow the team to discuss, discover and decide without deciding for them?
Let the outcomes be owned by the team rather than themselves?
Does the Project Manager have the skills to be able to:
Manage the group dynamics?
Build the appropriate deliverables required by the work session?
If so, then the hurdles of objectivity and skill set have been cleared and we’re ready to tackle the issue of freedom. Some
Project Managers have appreciated the ability to step out of the spotlight, observe the team, inject their own insights and
opinions, and allow the team to gel during work sessions. If this is your desire, then get someone else to be the facilitator.
Third, there are some standard guidelines you can use to ensure the requirements you capture are of high quality. Every
requirement should be:
Understandable – Everyone in the room should understand clearly what it means. If there are any questions or
discussion about meaning, get the group to clarify the requirement so they all know what it means two weeks
from now. Be very specific in your wording of the requirement to ensure that everyone understands it in the
same manner. Vague phrases like “user friendly” or “easily accessible” should be avoided.
Common Language - Don’t use workplace jargon or acronyms unless you capture their definition in a Glossary.
Others who are less familiar with the term will need to have a reference so they can clearly understand your
intention.
Singular – As a general rule, each requirement should be a one sentence statement of thought that does not
include “and” or “or”. Use of these conjunctions usually indicates that two thoughts are being connected into
one sentence. It can also indicate that the requirement is conditional. If it’s two separate thoughts, make it two
requirements. If it is conditional, make certain that the specific conditions guiding the requirement are clear.
This clarity and singular nature of requirements set the stage for “requirements traceability” – the ability to trace
elements of our design or implemented solution back to the business requirements that are supported and the
customer needs that are fulfilled.
Testable – Each functional requirement should be able to be tested to see if it works or not. As you’re building
your requirements, ask the group if each one could be tested. It will help them think more granularly.
Focused on “What” – We all like to solve the problem, so keeping people focused on “what they need” rather
than “how to do it” is a challenge. Each requirement should describe what must be in place to support the new
or enhanced product or service. Avoid using system names or making undocumented assumptions about
technology implications.
Ability or Capability – Often we see requirement statements phrased as tasks – do this, follow up on that. A
good requirement is not a task; it is a statement of the ability or capability needed to achieve the business goal.
In fact, many good requirements are actually worded as “the ability to…”
Figure 2 shows some examples of good business requirements:
Figure 2 – Examples of Good Business Requirements
TOOLS FOR BUILDING QUALITY BUSINESS REQUIREMENTS
There are tools you can use to overcome the assumptions previously described and improve your experience at the same
time. As Project Managers, these tools will help you:
get your business partners to articulate the details of their vision while avoiding the desire the skip to the fun
part (the solution),
bring all views to the table,
ensure we’re all talking about the same thing,
avoid the email black hole,
understand the relative importance of the requirements and
ultimately, build quality business requirements
Facilitated Cross-Organizational Work Sessions. What is a facilitated work session and how can it be used as a tool
to improve the quality of requirements? A facilitated work session is an event (usually ranging between 1 to 3 days) that
brings a cross-functional project team together to build a specific project deliverable or achieve specific project goals. These
work sessions have the following core characteristics:
They Have a Purpose that is Aligned to Project Objectives. The facilitated work session must have a set of clear
objectives that fit within the work and outputs required by the project.
They are Systematic. The work session has a well-defined approach and structure. Preparation, work session
delivery, and follow-up activities are all part of the work session process, with clear roles and responsibilities.
They are Collaborative. This is not a visit to a doctor’s office, or a trip to see an attorney. The participants do not
show up so that an expert can tell them what to do. The participants are the experts, and are led by a neutral
facilitator who seeks the input and full involvement of all participants to achieve the objectives of the work session.
They Encourage Discovery. The work session does not introduce “the answer” then drive for acceptance. It is a
place of discovery where the ideas and opinions of the participants contribute to exploring and embracing the best
outcome for the business situation.
They Create Substantive Outputs. Work sessions must create high quality outputs that are specific to the needs of
the project. This is not an encounter group. This is not a discussion group. This is a work group. Group dialogue
and interaction lead to creative decisioning, which in turn is captured into appropriate deliverables as required by the
project.
They Promote Accountability. Decisions within project work sessions are made by consensus. This does not mean
unanimity; rather it means that all participants are willing to support the decision 100% within and outside of the
work session setting. They are accountable for the decisions they make and their resulting impacts to the business.
So how will this improve requirements quality? In the mid-1970’s, Chuck Morris of IBM embraced an innovative way
to get groups of people together to design and implement distributed systems. This application of facilitation techniques
birthed the JAD-era – Joint Application Design work sessions where business and technology professionals came together to
jointly define requirements for design of computer systems. Use of facilitated group techniques (JADs) reduced time by 40%
while improving the quality of design results. Fewer coding errors were made and testing cycles improved accordingly.
These findings were again confirmed by Capers Jones in his 2000 study of “Patterns of Software Systems Failure and
Success 2”. He found that bringing all impacted members of a project team together with a structured agenda, objective and
skilled facilitator provided the following project tangible and intangible benefits:
Reduction of the risk of scope creep from 80% down to 10%
Acceleration in the early project lifecycle phases (including Scope Initiation, Planning, Definition) by 30 – 40%
Reduction of the overall project elapsed time and workforce effort by 5 – 15%
Ownership of results
Improved quality
Improved working relationships
Shared decisioning yielding informed decisions, and support of these decisions.
Are we proposing that every project, no matter its complexity or purpose, should utilize facilitated work sessions? No.
Then, how do you know when a facilitated work session would be beneficial? .
We’ve analyzed the projects we have worked on with our clients to determine which ones gained the most value from
facilitated work sessions and found some common characteristics. If you can answer yes to any of the following questions, a
facilitated work session will be a valuable contributor to the success of your project.
Does your project effort cross multiple lines of business, or multiple departments within the business?
Is your project tied to a critical timeline that allows little or no slippage?
Is your project one of the top ten strategic initiatives of the company or division?
Is your project attempting to accomplish something that is new to your company?
Is your project resurrecting something that was tried before and was unsuccessful?
Does your project require input of experts who are unavailable to participate full-time (or on a regular basis)
with your project team?
Will your project result in changes that require broad socialization or group consensus?
Are you experiencing scope creep or having difficulty getting a clear definition of requirements from the team?
Are you operating in a geographically-dispersed project environment?
Conversely, if your project scope is small and requirements are relatively uncomplicated in nature, or the project is not
following a critical timeline, is less visible from a strategic viewpoint, or is something you’ve done over and over again, and
you have a relatively small team who are co-located, then facilitated work sessions may not be of great benefit to your
project.
Scoping. We’ve already scoped the project during kick-off and charter. Why do we need to do anything else? The
same benchmarking study mentioned earlier (Best Practices, LLC1) also found that scope creep was a significant cause in
project delays. Often times this is because the scope is never clearly established or not defined to the level of detail necessary
to understand when ‘creep’ is occurring. Clearly understanding the scope of your project brings focus to your requirements.
Why worry about what’s needed to allow customers to earn reward points by paying for the new product on your website if
website development is outside the scope of your project?
But one principle is often overlooked. That is the importance of stating clearly not only what is in scope, but what is out
of scope. It’s funny how the mind works. We see words on a page, but we interpret them according to our own set of biases
and filters. Time and time again we’ve seen project teams and their extended stakeholder community misinterpret scope.
What one person thought it meant was different than its intended meaning or what others thought it meant. Stating both what
is in scope and what is not in scope clarifies the boundaries in a way that stating only what is in scope cannot do.
Thorough scoping provides a checklist for requirements completeness. As a final test of your requirements, you can
walk back through your scope table to ensure that all items identified as ‘in scope’ have been addressed and ‘out of scope’
items were not.
There are several recommended options for representing project scope and, equally, there are some you want to avoid. Let’s talk
about what to avoid first. Do not attempt to describe project scope by writing a monolithic set of paragraphs regarding the boundaries
of the project. A long textual description of scope is what typically gets projects in trouble. There is a direct correlation between the
length of the narrative and the potential to misunderstand it! Leave the paragraphs of text behind and try one of the following options
for clearly representing project scope.
Instead, let’s talk about two tools you can use to clarify scope – the Scope Table and the Context Diagram. The Scope
Table helps teams clearly identify which components or topics are included and which are excluded from the discussion,
project or task; thus allowing them to manage limited time wisely by addressing only relevant topics. It can also be used to
identify political or organizational boundary issues and provide a first-cut at stakeholder / team identification. Here’s what a
Scope Table looks like (Figure 3). The categories are changeable and should reflect topics that are relevant to the project.
Figure 3 – Scope Table
Best Practices around Creating a Scope Table:
Use bullets rather than narrative text
Have a predefined list of categories to stimulate thinking.
Feel free to allow the group to jump from “Out” to “In” to “Pending” as needed.
Always assign a follow task (with owner & due date) to resolve the “Pending” items.
Don’t allow discussion to ramble. Timebox discussion and “pend” items that can’t be resolved.
Don’t forget “why” items were marked “Out of Scope”. Capture the rationale associated with making items
“out of scope” so that the same conversations won’t happen again and again and again.
Don’t allow discussion of topics that were identified as “out of scope” during the meeting.
The second scoping tool is the Context Diagram. This tool is most commonly used in technology-related projects, but
can also be helpful in understanding the scope of non-technical projects with cross-organizational impacts. According to
Webster’s3, “context” is “the interrelated conditions in which something exists or occurs”. So a Context Diagram is a
graphic way of depicting the project scope within the “context” of its environment (Figure 4). In addition to communicating
scope, this tool can be used to address boundary issues, define “interfaces” or bridges that must be in place to successfully
implement the project and assist in resource planning.
Figure 4 – Context Diagram
Best Practices around Creating a Context Diagram:
Don’t start detailing the Context Diagram until you have a substantive understanding of project purpose and
project scope. Although the Context Diagram can assist in solidifying and communicating scope, it helps to
understand the basics of what lays within our project boundaries before starting the Context Diagram.
Don’t expect the creation of the Context Diagram to be linear. It is a very iterative activity.
Be careful not to model what is within the project scope on the Context Diagram. This diagram depicts the core
project initiative as a “black box” and is intended to show how this “black box” connects within the
environment in which it will live.
Use the final diagram to provide a guideline or checklist for future project deliverables such as:
o Business requirements (including interface requirements, vendor requirements)
o Technology design
o Interface specification
o Test plans
o Communication plans
o Implementation plans
Use the Context Diagram as a validation that the right stakeholders and project team members have been
identified and engaged.
Use Context Diagrams to compare existing and future environments and interactions. When building more than
one Context Diagram, clearly label the Context Diagram to denote whether it is representing the current
environment or the target environment.
Process Maps. Process mapping is one of the most common techniques used in process analysis. It has been used for
years, but has gained notoriety more recently as a substantive tool within many quality-based methodologies. It is
indispensable for understanding the detail of how a process works and can be easily annotated to include information
regarding who does the work or where the work gets done.
A Process Map or Flow is a visual picture of “how” a process works - the sequence of activities from the start to the end
(Figure 5). Process Maps are most useful when:
the way people do their work is changing (i.e., adding automation)
organizational entities are being merged or reorganized and you want to create a standard “blueprint” of how
the work will get done
you are introducing new or revising old products or services and need to understand the resulting impacts to
people, tasks, and technologies
attempting to reduce waste, improve efficiency or reduce costs (i.e. quality initiatives)
Requirements are a natural by-product of creating process maps. As you discuss the steps involved in setting up a new
customer, you’re also identifying the functionality and information you need to do the job. You are also creating the basis for
Use Case Scenarios which can be used during testing. For these reasons, we highly recommend the creation of process maps
for the ‘to be’ environment.
However, there are situations where process maps just don’t apply. If you’re building a new product or service or you’re
enhancing features of an existing product or service, you may utilize existing processes which require no process changes.
The only requirements may be related to the product or service itself, supporting documents, information interfaces,
reporting, training and communication. In these cases, we recommend that you use categories to drive your requirementsbuilding rather than the process maps.
Figure 5 – “Swimlaned” Process Map (showing process steps and roles)
Best Practices around Creating Process Maps:
Ensure that the group has agreed to process purpose and boundaries before starting to map the process.
Let the team know that reaching a comfort level with completeness may take multiple iterations.
Don’t get “hung up” on exact sequence of steps too early in the discussion.
Map at the level of detail needed to control variability.
Review and get feedback “segment by segment” as the map is being built.
Don’t change team members mid-mapping or you will be re-mapping the process.
Don’t leave “maps” as sticky notes on a wall. Transcribe it into tools that are readily available to document
processes (e.g., Visio, iGrafx) so it can be easily updated when needed.
Know who will “own” the process maps and store them in an accessible repository.
Business Requirements Table. A requirements table (Figure 6) provides a helpful way to organize information
regarding what the business needs in order to satisfy project objectives and targets. It can be used to capture the business
requirements and their associated business rules in one place, get team consensus on requirement prioritization, correlate
requirements to process steps, group requirements into relevant categories and allow requirements traceability in later phases
of the project.
Figure 6 – Requirements Table
Best Practices around Building the Business Requirements Table:
Post or hand-out the rules for a “good” requirement so you can refer to them as needed.
Keep requirements at a consistent level of detail throughout the document.
Refrain from using system and application program names, if possible.
Identify the requirement, business rules, requirement type and priority as you go.
Don’t repeat requirements in multiple places throughout the document.
Define requirements for the solutions comprehensively – those needed for technology support are only one type
of requirement. You may also capture requirements regarding business process changes, policy requirements,
security requirements, training requirements, skill requirements, etc.
Agree on requirements type categories, and stay consistent with these throughout the table.
Agree on the meaning of the priority designations, and don’t allow every requirement to be a High Priority.
Don’t get caught up in formatting the Requirements Table during the work session. You can make the
Requirements Table visually appealing after the work session is over.
Don’t let the discussion travel into “how the solution will be done”. That’s the work of Design. Focus on
“what the solution needs to do”.
CONCLUSION
Developing requirements is a critical and necessary part of the project lifecycle – regardless of the type of project you’re
working on. So don’t make the common mistake and assume that:
The Business Partner (or Customer) Knows What They Want.
Requirements are just a High-Level Wish List, so it Shouldn’t Take Much Time.
Gathering Requirements via Email is an Efficient Use of Time.
We Don’t Need to Talk About It, We Know What That Means.
If We Know the Solution, We Don’t Need to Document Requirements.
All Requirements Have the Same Importance.
Instead, you must first understand that the purpose of business requirements is to clarify the project vision and scope.
They make it tangible by building the blueprint that will guide the design. Second, choose your role in the requirements
process. If facilitated work sessions will be used to gather requirements, then determine who will be the facilitator. If the
Project Manager will play the role of facilitator, then ensure that the conditions of facilitation (such as neutrality) can occur.
Third, follow the standard guidelines to ensure the requirements you capture are of high quality. And last, use tools like the
facilitated work session, Scope Table, Context Diagram, Process Maps and the Requirements Table to effectively capture and
communicate comprehensive, quality business requirements.
REFERENCES
1
Best Practices, LLC, Benchmarking Project Management: Performance, Measurement, Processes and Tools, 2000
2
Jones, Capers. Patterns of Software Systems Failure and Success. (Thomsen Computer Press, 1996).
3
Webster’s New Collegiate Dictionary, G & C Merriam Co., 1973. Page 245.
Facilitating the Project Lifecycle: Skills and Tools to Accelerate Progress for Project Managers, Facilitators, and Six Sigma
Project Teams, J. Means and T. Adams, 2005, Jossey-Bass.