The Details Needed in A Business Requirements Document

A Business Requirements Document is typically used for complex projects so that everyone involved understands what the aim of the project is and how that will be achieved. It also documents what features and functions will be included in the project as well as sections on risk, assumptions and quality control.

It also documents how an end-user will use the final deliverable to achieve the business aims. For that reason it will contain information about the features and functions of the new product, process or software.

One of the important aspects of a BRD is to understand that it will be read by people with no technical knowledge and has to be understood by those people (as they will be approving the document). For that reason it should not be full of technical jargon (there are other technical documents that can fulfill that purpose) – it should be easily readable and as short as possible but, at the same time, it must explain in some detail how an end-user will use the project deliverable.

Functional Requirements

This section defines how exactly an end user will complete a particular task or fulfill a particular function. It states how any business information entered is processed – what sort of data an end user enters into the system and what is produced (typically a report).

Non-Functional Requirements

Non-functional requirements describe how the end-user will comply with business standards, statutory regulations or other laws that need to be adhered to.

Features

These are elements of a project deliverable that assist the end user in completing their tasks in an easier or more efficient way. A feature of a software application could, for example, organise information in an easily readable manner on the screen, present data graphically, automated the production of reports or allow easy collaboration between departments. Features do not change the end result but they improve the experience of users performing their day-to-day job.

Reporting Requirements

For many people affected by the implementation of a changed process as the result of a project, the only thing they see that is different is a report. It is, therefore, an essential part of any project that the reports produced accurately present the data in a clear, easily readable format. Often the quality of the whole project is decided based on the quality of the reports output so a BRD should document the reporting requirements of those involved.

Archiving

A project may start with the requirement to convert old data to be stored in a new system and it is a;so likely to require an archive process for new data that is built up over time in the new system. Pulling old data into the new system can be fundamental to the success of the whole project so the process must be described in the BRD.

So certain types of technical information are essential in a good business requirements document but a good project manager should ensure that there is a balance between enough detail without compromising the length and readability of a document which is, after all, intended to be read by end users and stakeholders.

This entry was posted in Uncategorized. Bookmark the permalink.