💥 9 Business Analyst Requirements Documents: Their purpose and who writes them 💥

Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.

Here are the main people involved in their creation:

✔The Customer is ultimately responsible for determining the requirements

✔The Business Analyst is responsible for discovering the problem/requirements

✔The Project Manager is responsible for delivering the solution to a problem

✔The Systems Analyst uses analysis and design to satisfy business requirements using IT

✔The Marketing Manager develops the marketing strategy for the project in line with its requirements

✔The Product Manager is responsible for defining the why, when, and what of the product that the development team will build.

Types Of Requirements Documents:

1. Business Requirements Document
2. Functional Requirements Document
3. Market Requirements Document
4. Product Requirements Document
5. User Interface Requirements Document
6. Technical Requirements Document
7. Quality Requirements Document
8. Software Requirements Document or Software Requirements Specification
9. Customer Requirements Document

1. Business Requirements Document (BRD)

Also known as a Business Needs Specification, a BRD is the first stage in a product life cycle. It details the problems that a product/service/system is trying to solve by logically listing high-level business requirements in relation to customers’ needs. As well as non-negotiables, it also details features the project should provide, which can be interpreted as goals for the development team.

It often includes:

✔An outline of the requirements of the project

✔Objectives of the project

✔A needs statement detailing why the project is needed and how it will meet those needs

✔Financial statements, demonstrating how the project will be funded and its effect on the company’s balance sheet

✔Functional requirements and features

✔A SWOT analysis of the business and how the project fits into it

✔Personnel needs - who do we want to work on the project?

✔Schedule, timeline and deadlines

✔A cost-benefit analysis (if required)

A BRD is normally prepared by the Business Analyst or Project Manager.

2. Functional Requirements Document (FRD)

An FRD defines in logical terms how a system or project will accomplish the requirements laid out in the BRD. It outlines the functionality of the system in detail by capturing the intended behaviour of the system expressed as services, tasks or functions that the developers have agreed to provide. Rather than define the ‘inner-workings’ and specifications, an FRD focuses on what users might observe when interacting with the system.

An example functional requirement might be: “When the user clicks the OK button, the dialog is closed, and the user is returned to the main window in the state it was in before the dialog was displayed”.

An FRD sometimes includes screen mock-ups or wireframes to illustrate the system’s design.

Depending on the complexity, FRDs can vary in length from 10 pages to several hundred.

An FRD is normally written by the Business Analyst or Systems Analyst.

3. Market Requirements Document (MRD)

Sometimes referred to as a Marketing Requirements Document, an MRD focuses on the target market’s needs. It typically explains:

🎯What the product is

🎯Who the target customers are

🎯What products are in competition with it

🎯Why customers are likely to want this product.

An MRD typically includes:

✔A definition of the target market: an imagining of the potential buyer or user

✔A comprehensive list of market requirements the solution will need to satisfy

✔Indicators of success for each requirement

✔A prioritized list of requirements from your market’s point of view

✔A timeframe for the product’s launch

✔An MRD is normally prepared by the Marketing Manager or Product Manager.

4. Product Requirements Document (PRD)

A PRD is used to communicate everything that must be included in a product release for it to be considered complete. It is written from a user’s point-of-view to understand what a product should do.

It usually includes the same content as an FRD, but with ‘non-functional requirements’ added. Although non-functional requirements are not related to the functionality of the product, it’s often important to identify them - they may include such needs as reliability, security and scalability.

A typical PRD might contain:

✔Objectives for the product

✔Features

✔User experience (UX) flow & design notes

✔System and environment requirements

✔Assumptions, constraints & dependencies - What’s expected as well as any limitations or obstacles that may impede the project’s progress

✔A PRD is normally prepared by the Product Manager.

5. User Interface Requirements Document (UIRD)

A UIRD describes the look and feel of the User Interface (UI) of the system.

It often defines:

✔How the content is presented to the user

✔User navigation

✔Colour codes to be used

✔Hints, tips and suggestions to be displayed

✔ ‘Save data’ options

✔Shortcut keys.

A UIRD more often than not includes mock-up screenshots and wireframes to give readers an idea of what the finished system will look like. It’s written by the user interface design team.

6. Technical Requirements Document (TRD)

A TRD contains the software, hardware and platform requirements of the product. It includes requirements like the programming language the system should be developed in, and the processor speed required to run the system.

It might also consider the limitations of the system and its performance.

A good TRD will include the following key items:

✔An executive summary of the project and its background

✔Assumptions, risks, and factors that may affect the project

✔Functional and non-functional requirements

✔References or a list of supporting documents

✔A TRD is written by the Engineering Team.

7. Quality Requirements Document

The Quality Requirements Document outlines the expectations of the customer for the quality of the final product. It consists of various criteria, factors and metrics that must be satisfied.

Quality requirements might revolve around reliability, consistency, availability, usability, maintainability and customer experience.

This document can be written by the Project Manager or Business Analyst.

8. Software Requirements Document / Software Requirements Specification (SRS)

An SRS outlines the features and the intended behaviour of a system. It describes the business’ understanding of the end user’s needs while laying out functional and non-functional requirements.

The contents may include:

✔A product overview

✔A summary of the current system

✔The proposed methods and procedures

✔Design considerations

✔Security considerations

✔An SRS is normally compiled by the Lead Engineer of the project.

9. Customer Requirements Document

This is sometimes referred to as Client Requirement Document and it can refer to a PRD but for a specific customer or client.