The Perfect Business Requirements Document

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 3

3/7/2014 The Perfect Business Requirements Document

http://community.businessballs.com/blogs/printblog?index_php?view=article&id=2341&tmpl=component&print=1 1/3
The Perfect Business Requirements Document
Posted by: SCArt in Blogs on Feb 11, 2011
Tagged in: Untagged
A Business Requirements Document is a formal document that effectively provides a contract
between a "supplier" and a "client". The "client" is typically a business department and the
"supplier" is the company or other business department that will create and deliver the new product,
system or process. The document describes in detail every business need and is written in response
to a known business problem or shortcoming. The Business Requirements Document is not expected
to describe in detail the solution to the business needs but to describe what the business wants and
needs. For technical products, such as new or modified software systems, further technical
specifications will be prepared.
Various techniques, such as brainstorming, story boarding, use cases and interviews, will have been
used to gather the requirements during a business requirements analysis process. That information
needs to be written down in a clear, concise format in language familiar to the business users. The
process of documenting and refining the business requirements helps to identify conflicting
requirements and potential issues early on in the project lifecycle. It is the key document in the
effective project management of any type of project.
The business requirements document effectively defines the Scope of a project. This is the
description of what will be included in the project and also what is specifically excluded from the
project.

Scope is a definition of the limits or boundaries of a project and the reason it is so important is
because poor management of the project scope is one of the major causes of project failure. Good
management of the project scope by the project manager involves 3 key factors:

devote adequate time to fully defining the requirements
reach a formal agreement on the scope with the stakeholders
avoid scope creep


Scope Creep
Scope creep is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the
documented requirements during the course of the project. The business requirements document
3/7/2014 The Perfect Business Requirements Document
http://community.businessballs.com/blogs/printblog?index_php?view=article&id=2341&tmpl=component&print=1 2/3
should address the possibility of requests for additional tasks in a project and state how they will
be dealt with. This usually involves a formal Change Request Procedure that requires the
agreement of all stakeholders to any changes of specification, budget or delivery time. The fact
that the business requirements document is a formally approved document assists the project
manager in implementing and sticking to a Change Request Procedure.

There is, of course, a tendency for changes to be requested during the life of a project. As projects
progress, the end-users inevitably see areas where additional features could provide increased
benefits. And the purpose of scope management is not to prevent such changes either being
requested or implemented, but to ensure that all changes bring substantial, well-defined benefits.
And that the budget will be increased accordingly and that the extended duration of the project is
acceptable to all parties involved. Failure on the part of the project manager to manage scope
adequately undermines the viability of the whole project as approved in the Business
Requirements Document.

All changes to the requirements, budget and schedule must be approved by all stakeholders. In
large projects it is common for end-users to see their opportunity to have all the "nice-to-have"
elements added while major changes are underway to some extent this is understandable but
only if the new features add real business value such as efficiency or accountability and do not
require the project to change in such a way as to lose sight of the original business needs that
instigated the project in the first place

Document Iterations
A business requirements document is likely to need several iterations before it is close to reaching a
document acceptable to all stakeholders. Writing such a document can be a complex and intricate
process and will probably need many more iterations before approval is actually achieved. This is no
reflection on the thoroughness of the analysis process but rather on the simple human difficulty in
translating thoughts and speech into clear, unambiguous and thorough wording on the page. Whilst
adequate detail is required to fully define the requirements, conversely, too much detail prevents
the readers from absorbing the key points. Writing a document that achieves this balance is a skill
in itself.

Fortunately, there are a number of best practice approaches and industry standards that can be used
to good effect when writing a business requirements document. These will assist in defining the
project scope and managing scope creep once the project is underway.

Key Document Elements
3/7/2014 The Perfect Business Requirements Document
http://community.businessballs.com/blogs/printblog?index_php?view=article&id=2341&tmpl=component&print=1 3/3
Whether the author of the business requirements is the business analyst or the project manager,
they should have an understanding of the different levels of requirements and the different
elements within the requirements. They must be able to state the business needs clearly,
understand the current business process and the key business objectives driving the project.
The following list, whilst not exhaustive, covers the main areas that should be documented in a
business requirements document. All of these elements are covered in detail on professional project
management training courses.

Business Problem Statement
Current Business Process
Scope Statement(s)
Key Business Objectives
Project Completion Criteria
Limitations
Risks
Assumptions
Functional Requirements
Non-Functional Requirements
Features and Functions
Reporting Requirements
Delivery Method
New/Modified Business Process
Data Retention/Archiving
Training
Stakeholder List
Quality Measures
Checklists (Process and Requirements)

Ensuring each of these elements is incorporated in to the document with sufficient detail and
clarity is the first step to creating a perfect business requirements document. Techniques for
writing effective business requirements are covered on both general project management
courses and on specific business requirements courses.

You might also like