Business Requirements Document: a High-level Review Page 1 of 6

Friday, 26 February 2010 17:45

Business Requirements
Document: a High-level Review
Written by J. DeLayne Stroud

font size Print 1 Comment

Rate this item (0 votes)

A business requirements document (BRD) details the business solution for a project including the
documentation of customer needs and expectations. The BRD process can be incorporated within
a Six Sigma DMAIC culture.

By J. DeLayne Stroud

Many businesses have a process in place to assist with project management and implementation.
One opportunity for improvement involves making reasonable estimates of how big a project is and
how much it is going to cost. There are many different names for tools used with this process:
business needs specification, requirements specification or, simply, business requirements.
Business requirements are the critical activities of an enterprise that must be performed to meet the
organizational objective(s) while remaining solution independent.

A business requirements document (BRD) details the business solution for a project including the
documentation of customer needs and expectations. If an initiative intends to modify existing (or
introduce new) hardware/software, a new BRD should be created. The BRD process can be
incorporated within a Six Sigma DMAIC (define, measure, analyze, improve, control) culture.

The most common objectives of the BRD are:

To gain agreement with stakeholders

To provide a foundation to communicate to a technology service provider what the solution
needs to do to satisfy the customer's and business’ needs
To provide input into the next phase for this project
To describe what not how the customer/business needs will be met by the solution

The BRD is important because it is the foundation for all subsequent project deliverables,
describing what inputs and outputs are associated with each process function. The process
function delivers CTQs (critical to quality). CTQs deliver the voice of customer (VOC). The BRD
describes what the system would look like from a business perspective.

The BRD distinguishes between the business solution and the technical solution. When examining
the business solution the BRD should answer the question, “What does the business want to do?”

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010
Business Requirements Document: a High-level Review Page 2 of 6

For example, the business wants to serve 100 bottles of red wine each night during a three-day
conference and the wine must be 57 degrees Fahrenheit when poured. The technical solution
should support the business solution. For example, the company would need a wine grotto or
refrigeration storage unit capable of holding 300+ bottles operating between 48 and 52 degrees
Fahrenheit.

Who should be involved in the creation of the BRD?

A number of teams and partners should create the BRD:

Project core team

Business partner(s)
Process Owner(s) or representatives
Subject matter experts
Change/project/product management, quality department and/or IT management as needed
or available

Prerequisites for BRD

Prerequisite one for a BRD is the project charter, created during the define phase of a DMAIC
project. The BRD provides the opportunity to review the project charter to ensure that the objective,
goals, scope, project team, and approvers are accurately reflected.

Prerequisite two is a current environment assessment created during the measure phase. This
includes a detailed process map of the current environment highlighting areas that will be changed
during the project. Detailed “as is” process maps should include:

Clearly defined start and end points of the process

Level two and three process functions
Defined areas of rework and non-value added steps
Cycle time, capacity and rework information for each process step as available
Baseline for each CTQ for the current environment

Prerequisite three is CTQs, identified in either the define or measure phases, and validated with
baseline measurements, targets and specifications.

Current measures: Data that defines and describes current performance – sigma level of the
CTQ includes a definition of how the product/service's characteristic is to be quantified.
Target/nominal value: What is the aim of the product/service? If there was never any variation
in the product/service, this would be the constant value.
Specification limits: How much variation is the customer willing to tolerate in the delivery of the
product or service? Define upper and lower specification limits as required by the customer
needs.
Allowable defect rate: How often are the producers willing to produce a product/service
outside the specification limits?

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010
Business Requirements Document: a High-level Review Page 3 of 6

Prerequisite four is the target environment assessment, created in the measure phase, and
includes a detailed process map of the target environment including level two functions. When
distinguishing between level two or three functions, group the process functions into the following
categories:

People: People are processing information and making decisions [core team designs high-
level design/low-level design (HLD/LLD)]
Systems: Systems is processing information and making decisions
Systems/people: System is processing information and people are making the decisions

Distinguish between employee and customer

Distinguish leadership requirement for associate in case decision making authority has to
be moved up

Fishbone: For each process function for impact assessment

Overall Project Details and Best Practices

The BRD appendix can be used to list a number of project details – constraints, assumptions and
dependencies, business rules, scope, measurements reporting and other topics critical to the
project. Consider the following issues when looking at the overall project:

Are there any regulatory or geographic constraints (i.e., State law) to consider? If so, these
constraints need to be clearly documented in the process detail table of the BRD or in the
overall project details section of the appendix.
What assumptions or dependencies apply?
What business rules apply?
Are there any measurements or reporting requirements that apply to the project?

Best Practices

1. Validate scope: review and refine the scope as needed based on a process detail table,
identifying any changes to what is in or out of scope now that the requirements have been
developed. Complete this prior to obtaining the business partner(s) sign-off and lock down the
scope of the project. Any changes to the project after this phase will be handled through a
change control process.
2. Create systems impacted document: Create a design-elements diagram for each level two or
three process function for impact assessment for:

People
Process
Technology
Materials and supplies

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010
Business Requirements Document: a High-level Review Page 4 of 6

Facilities
Product
Machinery and equipment
Others as necessary (depending on the organization)

3. Definitions and acronyms: Define any terms not clearly understood by all.

Packaging the BRD

Package the BRD so it has a logical flow and is easy to follow. An example of a high-level list of
sections follows:

Project overview including project charter information, scope, and objectives

Current environment assessment and systems overview (see additional details below)
Future process map
Process detail table
Overall project business rules and constraints
Impact assessment (fishbone for process functions)
Functional requirements (additional details below)
Data to be held (additional detail available below)
Schedule and budget
Terms and definitions
Approver information
Team information

Business Partner Sign-off

Business partners should be active participants in the development of the BRD, but a final review
and sign-off is also essential.

Additional Details

There are a number of items included in the BRD that require detailed documentation to ensure
successful implementation. Following is a high-level overview of the types of detail to consider:

Sample questions for the current environment assessment and systems overview:

Who is the intended user?

How many users are there? Are they the same type of user or different?
What level of computer experience will the users have (or is needed)?
What is the required security?
Are there hardware constraints – networked or stand-alone?
What are the approximate numbers of records required initially plus the anticipated growth?
What technical support is necessary and available in-house?

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010
Business Requirements Document: a High-level Review Page 5 of 6

What other systems need to integrate/communicate?

Backup. Describe the current back-up regime (e.g., tape back-up one/day). How will the new
system fit with this? If this is not currently defined then think how much data could be
inadvertently lost. For example would it be a major disaster if the last 30 minutes of work was
lost, or could yesterday's/last week's data be retained?
Deliverables. What are the expectations – system, help files, documentation, full source code,
training, support, etc.? Detail what is essential versus nice. Do not automatically ask for
everything unless necessary. If the project manager is to maintain the system make sure he
states that he requires the full source code – alternatively if the developer is to maintain the
system consider settling for an escrow agreement (where the source is held by an
independent third party). Be specific about tools necessary to help. If the developer is
unwilling to provide the support necessary find someone else who will.

The functional requirements section should describe “what” the system is to accomplish rather than
the “how.” Develop a prioritized list similar to the following:

A detailed description of the requirement including goals, e.g., produce a report of

spend/department/year on demand with the user selecting the department and the financial
year required – it is necessary to know how the company defines the financial year.
How important is this requirement (essential, preferred, nice to have, not essential, etc.)?
Any known design/implementation issues relating to this requirement?
Does this requirement interact with other requirements?

Data to be Held: Sample Advice

Describe expected data tables. Examples include customer records, contact details, machine
records, etc. Provide as much detail as possible – a customer record might consist of a name,
address, telephone number, fax, mobile number, region, business type, number of employees etc.
Indicate any unique fields (such as a job number) and show how different tables relate to each
other (very important). For example projects are related to customers through a customer number.
Each customer can have none, one or many associated projects. Each project relates to one or
more jobs. A job can exist independently of a project but will still be associated with a customer. A
project will always have only one customer.

It is not usually necessary to define the tables in database terms (e.g., customer number is a long
integer) but examples of the data to be held in the fields is useful (e.g., a typical job number might
be FH/1234 where FH indicates the department undertaking the job and 1234 is a unique number.
In practice a good database designer would then recognize that the “real” job number is actually
the 1234 part and the FH is just an associated field). If the maximum size of any field is known – for
example, a "Company Name" field is 100 characters – then include this. If there are any table
definitions from existing systems then provide these indicating any required changes.

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010
Business Requirements Document: a High-level Review Page 6 of 6

Summary

As with any tool, the BRD can have both benefits and failure modes. Benefits derived from a good
BRD include reduced changes during the improve and control phases of DMAIC and reduced time
to deployment. Failure modes from a poor BRD means the system developed will not meet
business requirements. Creating a successful BRD requires planning and coordination. There are a
few best practices that should be followed in this process. The team should hold a dedicated off-
site session to complete the BRD with all required resources 100% available. Scheduling is the key
to success here. As each tool/deliverable is completed within the methodology build the BRD. Allow
a one-week deadline to finish action items from the off-site session and hold a final review session
two to three hours after completion of action items.

About the Author: J. DeLayne Stroud is a Six Sigma Master Black Belt project manager with
DeLeeuw Associates, a division of Conversion Services International. He retired from Bank of
America in 2005 with more than 20 years of experience as an executive in project and change
management in the banking industry. He has led multiple Six Sigma initiatives including Design for
Six Sigma and Lean initiatives. During his career, Mr. Stroud was a senior project manager in some
of the largest mergers and change initiatives in the history of the financial services industry,
including former banks such as General Bancshares, Boatmen's Bank, Centerre Bank, Barnett
Bank and BankAmerica. He can be reached at jstroud@deleeuwinc.com .

Additional Info
CID: 925

Read 596 times |

Published in Project Selection & Identification

Social sharing

back to top

http://www.isixsigma.com/index.php?option=com_k2&view=item&id=1076:&Itemid=15... 18/03/2010