BRD, PRD, TRD

BRD, PRD, TRD – THE CASE OF THE CONFUSING REQUIREMENTS..

Posted on 6 Mar 2019 by Dip Bagchi

There are a lot of questions that always surround requirements documents: “Who are they for?”, “How do these fit into the bigger picture?”…etc. Although not all product managers tend to use the documents in the exact same manner, their purpose is clear and well-defined across the industry. Although many other documents exist for hardware, I have focused on the core documents used in software development.

一、BRD — BUSINESS REQUIREMENTS DOCUMENT

Also known as: Business Needs Specification, Business Requirements

Usage: To define the business needs of any given project. The business requirements document is always the first step of any product lifecycle. Its goal is to get all stakeholders on the same page, and ensure there are no surprises coming from the business units. A properly done BRD will prevent surprises and wasted effort on elements that do not answer the business objectives.

Traditionally written by: Product Managers; Project Manager; Business Analyst; or Business Executive; Product Marketing Managers.

Contents:

• Executive summary
• Background
• Business goals/objectives with benefits/rationale
• Stakeholders
• Assumptions/Limitations/Risks
• High-level Project scope/Requirements scope

二、MRD — MARKET REQUIREMENTS DOCUMENT

Usage: Used to more accurately define the customer needs rather than the business needs. This document is often combined with the PRD into one document, and should not be confused with the marketing demands of a project.

Written by: Product Managers

Contents:

• Executive summary
• Purpose
• Goals/objectives
• Target Market & Customer
• Overall position
• Competition
• Use cases/use model
• Customer needs & Corresponding Features
• Systems & Technical Requirements

三、PRD — PRODUCT REQUIREMENTS DOCUMENT

Also known as: “Requirements”

Usage: Used to identify the product requirements. This is the document that is central to the whole undertaking with the product in question.

What is the “thing” being created to capture the opportunity specified in the BRD? How does it look? What can it do/not do? What boundaries does it have to live within? This document answers the “what”, while the technical specs answer the “how”.

Contents:

• Purpose
• Stakeholders
• Project scope/Requirements scope
• Market overview
• Product overview
• Use cases/use models
• Functional requirements
• Data requirements
• Interface/Design requirements
• Support requirements
• Usability requirements
• Non Functional requirements
• Needed functionality vs. wanted.

四、FSD — FUNCTIONAL SPECIFICATIONS DOCUMENT/PSD — PRODUCT SPECIFICATIONS DOCUMENT/SRS — SOFTWARE REQUIREMENTS SPECIFICATION

Also known as: Functional spec, Specs, Software specs

Usage: Used to identify the detailed requirements to aid in designing and developing the software

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. The order of document importance is: PRD, BRD, MRD, FSD/PSD/SRS.

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

Lastly, in complex or overlapping products, there should be only one BRD; but can be many PRDs. It is the role of the product manager owning the BRD (and overall features), to ensure all the different product requirements (PRDs) are aligned.