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 ExplanationUnitary (Cohesive) The requirement addresses one and only one thing.

Complete The requirement is fully stated in one place with no missing information.

ConsistentThe requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

Non-Conjugated (Atomic)

The requirement is atomic, i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes".

VerifiableThe implementation of the requirement can be determined 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

angleGlossary

• definitions of terms that readers may not be familiar with

Bibliography• Sources of information referenced