Types of Requirements Documents
From Requirements Management School
There are many types of requirements documents.
Most organizations use their own adapted templates that cover a variety of document types. Sometimes the names or acronyms referring to the requirements documents are also used interchangeably. This can be a little confusing to say the least.
In this article we attempt to try and bring some clarity to the subject. We are going to take a look at the most common types of requirements document. We will define what they are used for; who uses them; and what they generally contain.
Contents |
BRD – Business Requirements Document
Also known as: Business Needs Specification, Business Requirements
Usage: To define the business needs of any given project.
Written by: Product Marketing Managers; Product Managers; Project Manager; Business Analyst; or Business Executive
Contents:
- Introduction - purpose; audience; background; business goals/objectives; benefits/rationale; stakeholders; existing systems; references; assumptions
- Project scope/Requirements scope
- Functional requirements
- Data requirements
- Interface requirements
- Non Functional requirements
MRD – Market Requirements Document
Also known as: Sometimes combined with the PRD into one document
Usage: Used to more accurately define the customer needs rather than the business needs
Written by: Product Marketing Managers; Product Managers; Project Manager; Business Analyst; or Business Executive
Contents:
- Executive summary
- Purpose
- Goals/objectives
- Target Market & Customer
- Overall position
- Competition
- Use cases/use model
- Customer needs & Corresponding Features
- Systems & Technical Requirements
- Quality Assurance & Testing
PRD – Product Requirements Document
Also known as: Sometimes combined with the MRD into one document
Usage: Used to identify the product requirements
Written by: Product Managers; Project Manager; Business Analyst
Contents:
- Purpose
- Stakeholders
- Project scope/Requirements scope
- Market overview
- Product overview
- Use cases/use models
- Functional requirements
- Data requirements
- Interface requirements
- Support requirements
- Usability requirements
- Non Functional requirements
The final three documents are pretty much fully interchangeable. They are all documents that are used to provide a clear and accurate description of the technical specification and functionality of the system being developed.
FSD – Functional Specifications Document; PSD - Product Specifications Document; SRS - Software Requirements Specification
Also known as: Functional spec, Specs, Software specification
Usage: Used to identify the detailed requirements to aid in designing and developing the software
Written by: Engineering Lead; Product Analyst; Program Manager
Contents:
- Introduction - purpose; product overview; scope; references;
- Current system Summary
- Proposed methods and procedures
- Detailed characteristics
- Use cases
- Design considerations
- Environment
- Security
When to Use These Requirements Documents
The various requirements documents outlined above contain a great deal of information in common - as a result, putting them together is not as time consuming as it may initially seem.
Furthermore, for less complex or smaller projects some of the documentation can be safely ignored.
When all of the documents are used, there is a workflow to the use of these documents which tends to follow the following order of release in the project cycle:
- BRD
- MRD
- PRD
- FSD/PSD/SRS
