Business requirements documents

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 (Cohesive) The requirement addresses one and only one thing. Complete The requirement is fully stated in one place with no missing information. Consistent The 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". Verifiable The 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 angle
Glossary
definitions of terms that readers may not be familiar with
Bibliography
Sources of information referenced

Business requirements documents

by hapy on Feb 23, 2011

Accessibility

Upload Details

Usage Rights

1 Embed 56

Statistics

Business requirements documents — Presentation Transcript