A Business Requirements Document is the document used in complex projects to define what needs to be done or altered in order to meet some business objective. It also documents what will, or will not, be included in the project and a certain amount of detail about risks, assumptions, training and quality measures.
But it must also detail what the user needs to do to fulfil their role and deliver the business objective and how they will perform their tasks. So it is necessary to include details in the Business Requirements Document about the features and functions that are required to deliver the project successfully.
This is a document that has to be read, understood and approved by business users who may have no technical knowledge so it is important not to let too much technical detail creep into the Business Requirements Document. There will be additional functional and technical specifications that cover in detail any changes to software or machinery or product composition. However, it is necessary that the end-users know what the new system will do, how they will use it and how it will look and feel to a certain extent. This is why the functional and non-functional requirement sections of the Business Requirements Document are necessary.
But this is a requirements document not a specification so don’t confuse the two and don’t overwhelm the audience with more detail than they want or need. This will simply deter the people who should be reading it from actually reading it fully.
So what exactly are functional and non-functional requirements?
Functional Requirements
What will the product or process actually do? What actions will a user have to take to complete a task? These are the questions you must answer in order to document the functional requirements of a project.
Functional requirements refer to how the business information or product is processed – what data the user enters (or raw material they start with) and what is output. It could be a physical product or information in the form of a report.
Functional requirements describe the actions that are done in order to complete a piece of work.
Non-Functional Requirements
Non-functional requirements, on the other hand, relate to how the end-user works within the business environment and to the business standards or laws that need to be adhered to.
They describe the properties of a product (physical or otherwise) and the user’s experience while doing the work.
Features
These are often elements of a project that make the user’s task easier in some way – it may be that a feature assists in organising data more clearly, managing workflow, or providing graphics to help visualise processes or products. Features do not (or should not) affect the end result but they do positively affect the experience of the user whilst performing some task.
Reporting Requirements
Ultimately many people in an organisation may only see the end result of a new product or process as a statistical report. The quality of these reports will be perceived as a measure of the quality of the product or process. Therefore, the business requirements document should also cover in detail the reporting requirements. And, more importantly, reporting requirements may fundamentally affect how data and images are stored, which will have an influence on the technical specifications.
Data Retention/Archiving
It is rare that a project starts with no data – it is far more likely that there is some history of data or information that needs to be retained either in an archive system or within the new system as legacy data. It is also common that the existing data needs to be converted to work with the new system, particularly when the project is a software enhancement or replacement where there already exists a database of information that needs to be used going forward in the business.
So some measure of technical information is needed in a business requirements document and effective project management should ensure that there is sufficient detail without there being an overload.
