Charles Rowe dot com

As an essential requirement to your web development project, the business requirements document acts as a communication conduit between the developers and the project owner (customer). A well written BRD can protect the developers and the customers from miscommunication, inefficiency, and missed deadlines.

Put Simply: the BRD is a carefully worded, non-technical document that lists the features, requirements, and basic operations of an application. It is important to write the document so that your customer can clearly understand it. If applicable, use any of the customer’s specialized terminology to demonstrate clear lines of communication and an understanding of their needs.

If you have yet to use a BRD the important thing is to do your research and get your customer’s requirements on paper. The BRD is your shield against the consistent redesign of an application while it is in the process of development (known as feature creep). The consequences of consistent unplanned redesign are missed deadlines or budgets, and in the worst case, project failure.

Remember, the developer’s job is to serve the customer. The customer has the right, and sometimes the need, to change the scope of the project by modifying their requirements. This is fine. Nothing the developer does can ever be set in stone. If the customer is willing to pay the cost of a scope change, then it is something that has to be done. The BRD is not a wall intended to separate customer from developer, It is a means of bringing the two parties closer together so that they can accomplish the project as a team.

You will often have to go through many versions of a BRD until you are ready for development. Usually there are areas which are unclear and will require prototypes or interviews with a subject matter expert. This is perfectly normal. The goal of the business requirements document is to act as the back bone of the project. Make it clear to the customer that the business requirements document drives the project plan, which in turn sets the deadlines and cost of the project. When the customer understands that a modification of the business plan could push the project boundaries, then the developer has the best chance of avoiding impossible deadlines.

Click here for a rough example of a Business Requirements Document

For those who have never seen a BRD, the above document is an extremely basic example to give you a rough idea. Numbering a BRD in outline format is typical for large Business requirements. When making revisions, or using the business requirements for acceptance tests. It is much easier to say “item 8.4.2.1 needs modification” than trying to explain that a modification is required on pg. 9, 15^th line.