Features and Functions in a Business Requirements Document

Must read

This is a guest post by one of a number of contributors working in the project management field. We welcome high quality news items, blog posts and articles about project management. All content will be moderated before approval. Find out more about submitting your content at https://www.projectmanagementworks.co.uk/write-for-us/


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.


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.

- Advertisement -spot_img

More articles


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.

- Advertisement -spot_img

Project management has developed into a fully-fledged chartered profession since the granting of the Royal Charter in the UK to The Association for Project Management (APM) in 2017. Training courses for project managers were already available and highly popular to help people gain professional project management accreditation, but with this wider recognition of the profession it is now seen as a desirable career path for many. Whilst the APM has the coveted Royal Charter and continues to develop its APM PMQ (formerly the APMP) programmes, there are also other internationally recognised qualifications that continue to be highly regarded such as PMP and PRINCE2.

Organisations have become increasingly project-focused in this era of rapidly emerging new technologies and they value the expertise that comes with experienced and fully qualified project teams and managers. By investing in their project management capability businesses can be confident of delivering their new projects in time and on budget more often and more successfully. Many major corporation are now training their people to have the right project management qualifications as well as relevant experience, through internal Learning & Development (L&D) programmes; or by using external project management training providers.

Latest articles