Business Requirements

Documents
A typical IT project-level BRD document expresses the requirements of the
business customers and stakeholders of a new project. It summarizes the
business reasons for undertaking the project, answers the question "What
problems do the Business customers want to solve?" or "What job does the
business customer want to accomplish?" , and describes the constraints on any
proposed solution from a business perspective. It is used to communicate to
internal and/or external technology providers what the ultimate solution will
need to do to satisfy the customer and business needs.
• When people first begin writing Business
Requirements Documents they have problems
because they feel they are repeating them
selves but that is exactly what you are
expected to do!!!
• The secret is to repeat yourself but from a
different angle specific to the section you are
writing
 Also when documenting requirements you should ensure that your
requirements document exhibits the following characteristics
Characteristic Explanation
Unitary
The requirement addresses one and only one thing.
(Cohesive)
The requirement is fully stated in one place with no missing
Complete
information.
The requirement does not contradict any other requirement
Consistent and is fully consistent with all authoritative external
documentation.
The requirement is atomic, i.e., it does not contain
conjunctions. E.g., "The postal code field must validate
Non-Conjugated American and Canadian postal codes" should be written as
(Atomic) two separate requirements: (1) "The postal code field must
validate American postal codes" and (2) "The postal code
field must validate Canadian postal codes".
The implementation of the requirement can be determined
Verifiable through one of four possible methods: inspection,
demonstration, test or analysis.
 Problem Definition
• Business Need
• This is a broad over view of what is required
or what is the problem to be solved eg
– to display product information for the web site
– to sell products from start to finish
– to order products or materials from suppliers
– Customer service processes
 Stakeholders and their roles
• In theory: Anyone who impacted by decision
or able to prevent decisive action from
occurring.
• In practice: Those with “vested interest” in
either the issue &/or their relationship with
those making the decision(s).
 Scope
• 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. This
section details what the project is going to
deliver. Essentially it is the "big picture" view of
the project. A clear well defined “Scope” will
enable:
• Supplier and client to 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 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.
 Business Objectives
• Start with a “Parent” requirement. The easiest
way to think of this is to ask yourself, “What is
the objective of this web site/project?” or
“What are the goals we have for this web site/
project?”
 Available Resources
• What is available to help furfil the
projects/website requirements
• Existing software, hardware, content,
templates
 Constraints
• What are the limiting factors for the website/
project
• Almost always there are 3 constraints time,
budget & skills but there maybe more but
these 3 are a good point to begin with
 List of assumption
• What have you assumed when writing this
Business Requirements Document?
• Assumption should also be validated because
assumptions are risks. Any assumption
identified is a risk identified.
 Specific Requirements

• Specific requirements are the business/project

objectives broken down into specific tasks
• A requirement is a singular documented need of
what a particular product or service should be or
do. It is a statement that identifies a necessary
attribute, capability, characteristic, or quality of a
system in order for it to have value and utility to
a user.
• You may have gone down too far in your business
objectives in which case you could copy and
paste
 Functional requirements
• describe the functionality that the system is to
execute; for example, formatting some text or
modulating a signal. They are sometimes
known as capabilities.
 Non-functional requirements
• describe characteristics of the system that the
user cannot affect or (immediately) perceive.
Nonfunctional requirements are sometimes
known as quality requirements.
 Conclusion
• Basically your introduction but from another
angle
Glossary
• definitions of terms that readers may not be
familiar with
Bibliography
• Sources of information referenced