9 Types Of Requirements Documents: What They Mean 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.

When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD.

But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it’s a product, service or system, and the particular requirements it has.

The key players

Before we jump into the 10 types of requirements documents, let's talk about the main people involved in their creation.

• The Customer is ultimately responsible for determining the requirements. The customers’ needs are the origin of the project.

• The Business Analyst is responsible for discovering the problem/requirements and determining the solution.

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

• The Systems Analyst uses analysis and design to satisfy business requirements using information technology.

• 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.

​

Here are 9 different types of requirements documents

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

It’s normally a single page with a bullet-type list.

A BRD is normally prepared by the project manager or business analyst.

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 mockups 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 and 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:

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 mockup 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 or Software Requirements Specification (SRS)

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

An SRS is related to the FRD and PRD but written with a specific IT project in mind.

Its 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.

Author: Nicholas Rubright

Nicholas Rubright is the digital marketing specialist for QRA - a company that builds software to assist with writing requirements documents. This is accomplished through automated language analysis and reporting that helps project managers, engineers, and business analysts reduce the risks involved in the writing of requirements documents.