product management & marketing: requirements document alphabet soup explained

1. On product management, marketing & the high-tech business - by Michael Shrivathsan, a product management &
marketing expert in Silicon Valley, USA. No agenda, nothing to sell - just a shared journey for knowledge. Hop on!
« Create Successful Products by 'Getting in the Van' | Main | The Soul of Your Product - Know What It Is? »
Requirements Document Alphabet Soup - Explained
3 Comments Latest comment by: Josh Thomson
reddit | digg it! | del.icio.us
Earlier this week I got a friendly email from a reader. She asked me whether I could write an article comparing
the different requirements document formats used in the software industry. You know - BRD, MRD, PRD, FSD,
PSD, SRS, IRS, etc.
I'm frequently asked many variations of this question - so I'll try and explain all of these briefly in this article.
Well, all except that last one!
Alphabet Soup
If you're like me, you grew up with a variety of alphabet snacks - alphabet cereals, alphabet biscuits, alphabet
soup, and many other snacks shaped like alphabets. I guess most of us must have really liked them - or were
really tormented by them! I don't know which one for sure - but the net effect is they seem to have had a
deep influence on most of us.
Now we're all grown up and rarely eat those alphabet snacks any more - but in nearly every profession, the
industry jargon is an alphabet soup overrun by TLA's (three letter acronyms). FBW (for better or worse)!
Product management and product marketing is no different - especially when it comes to requirements
documents. We have BRD, MRD and PRD; we also have FSD, PSD and SRS; and many different variations of
these.
As if that is not enough, all organizations do not use these terms in the same way. What one organization calls
MRD, another may call PRD. Sometimes I can't help but LOL (laugh out loud) when I see yet another new TLA.
That said, let us try and get our hands around these.
Useless Trivia Question: Using only the uppercase alphabets in English, how many different TLA's
can you create?
P.S. If you got this far and don't know what TLA stands for, shame on you! Please reread from the
start, will ya?
Subscribe via RSS Feed | Subscribe via Your Email Address:
Subscribe me
GET *FREE* UPDATES ON ALL FUTURE ARTICLES!
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
1 of 7 3/31/12 10:54 AM

2. All The News That's Fit to Print - About Requirements Document Acronyms
Let us take a quick look at the most common acronyms used while referring to requirements documents:
BRD1.
MRD2.
PRD3.
FSD4.
PSD5.
SRS6.
BRD - Business Requirements Document
A Business Requirements Document (BRD) focuses on defining the business needs of a project.
The BRD identifies one or more business problems faced by customers that can be solved by the
company's product. It then proposes a solution - usually a new product or enhancement to an
existing product to address these problems.
It may also include a high-level business case -- such as revenue forecast, market & competitive
analysis, and sales/marketing strategy.
It is usually written by someone with the title of Product Manager, Product Marketing Manager or
Business Analyst. In small companies, it may be written by senior execs or even founders.
It is usually a Word document running 1-3 pages, or a PowerPoint document running no more
than 10 slides.
Example:
Let us assume your company is developing a customer relationship management (CRM)
software.
The BRD may focus on problems faced by sales managers in keeping track of all ongoing deals
and being able to create reliable forecasts. It may identify:
Who have the pains
Sales Managers at Fortune-500 companies
What the pains are
No real-time visibility into deal status
Inability to create reliable forecasts
Proposed solution
Create web-based software to track deals and create forecasts
1.
MRD - Market Requirements Document2.
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
2 of 7 3/31/12 10:54 AM

3. Like This Article?
Why not share it with
friends and colleagues?
Just click here...
A Market Requirements Document (MRD) focuses on defining the market requirements for a
proposed new product or enhancement to an existing product.
Whereas the BRD identifies business problems and solutions to those problems - the MRD delves
deeper into the details of the proposed solution. It may include some or all of these details:
Features required to solve the business problemsa.
Market and competitive analysisb.
Functional and non-functional requirementsc.
Prioritization of features/requirementsd.
Use casese.
It is usually written by someone with the title of Product Manager, Product Marketing Manager or
Business Analyst.
It is usually a Word document running 5-25 pages, or even longer in some organizations as
described later.
Example:
Let us continue with the above example of a company developing a customer relationship
management (CRM) software.
The MRD may focus on identifying and prioritizing requirements, as well as describing use cases.
Requirements include functional and non-functional requirements such as:
Functional Requirements
Must work in Internet Explorer (version 6.0 and above) and Firefox (versions 1.5
and above)
Must use SSL to ensure security
...
User should be able to enter data through browser interface for: customers,
companies, contacts, opportunities, deal size, etc.
Non-Functional Requirements
Must be able to support up to 100,000 simultaneous users
Must have uptime of greater than 99.9%
...
Need comprehensive user guide in English, German and Japanese
Please check out this article on writing MRDs for further details.
Alert: Some organizations combine MRD and PRD as described here into one document,
and call the resulting document MRD. In this case, the MRD will include what is described
in this section as well as what is described in the PRD section below - and may run more
than 50 pages.
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
3 of 7 3/31/12 10:54 AM

4. PRD - Product Requirements Document
A Product Requirements Document (PRD) focuses on defining the product requirements for a
proposed new product or enhancement to an existing product.
Whereas the MRD focuses on requirements from the perspective of market needs, PRD focuses
on requirements from the perspective of the product itself. It usually delves into more details on
features and functional requirements, and may also include screen shots and user interface
flows.
In organizations where the MRD doesn't include detailed requirements and use cases, the PRD
covers those details.
It is usually written by someone with the title of Product Manager, Business Analyst or Product
Analyst.
It is usually a Word document running 20-50 pages, or even longer for complex products.
Example:
Let us continue with the above example of a company developing a customer relationship
management (CRM) software.
The PRD may focus on detailed requirements such as:
Login screen should include username and password fields. It should also include a 'Forgot
Password' link.
'Contacts' screen should include fields for first name, last name, phone, email,...
...
'Forecast' screen should have a 5-step wizard that walks user through the steps required
to create annual forecasts. Each step should be as described below...
The PRD may also include detailed use cases.
Alert: Some organizations combine PRD and MRD as described here into one document,
and call the resulting document PRD. In this case, the PRD will include what is described
in this section as well as what is described in the MRD section above.
3.
FSD - Functional Specifications Document4.
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
4 of 7 3/31/12 10:54 AM

5. A Functional Specifications Document (FSD) defines the complete details of a product's
functional requirements with a focus on implementation. FSD may define the product
specifications screen by screen and feature by feature. This is a document that can be directly
used by engineers to create the product.
Whereas the MRD and PRD focus on requirements from the perspective of market needs and
product, FSD focuses on defining the product details in a form that can be implemented by
engineers. FSD may also include complete screen shots and UI design details.
It is usually written by someone with the title of Product Analyst, Engineering Lead, or Program
Manager - the author(s) usually belong to the engineering department.
It is usually a Word or similar document running several dozen pages.
PSD - Product Specifications Document
Product Specifications Document (PSD) is a less popular acronym, but in organizations that have
such a document, it is by and large the same as the Functional Specifications Document (FSD)
described above.
5.
SRS - Software Requirements Specification
A Software Requirements Specification (SRS) is another less popular acronym. In organizations
that create an SRS, it has contents and details somewhere close to what is described above for
PRD or FSD.
6.
Okay, there you have it - 6 requirement document acronyms deconstructed and explained. Just want to alert
you again - all organizations do not use these terms in the same way. Think of these documents as points on a
spectrum. Each organization defines which documents to create and where in the spectrum those documents
fall - depending on what best fits their unique needs.
Useless Trivia Answer: Using only the uppercase alphabets in English, the total number of TLA's
(three letter acronyms) you can create equals:
26³ = 17,576.
You know what this means, right? Be mentally prepared to learn another 17,570 TLA's related to
requirements documents.
Alrighty then - our tour through the wonderful land of requirements document acronyms is over. As Tigger
would say, TFN (ta-ta for now)!
Like this article? Then you will love my FREE monthly email newsletter - loaded with useful
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
5 of 7 3/31/12 10:54 AM

6. information for Product Management & Product Marketing professionals. It is FREE - get it now!
About the Author: I'm your author, Michael Shrivathsan, an expert in product management and product
marketing with successful experience spanning two decades. I live in Silicon Valley, USA. For my day job, I
manage the product management & marketing teams at Accompa, makers of requirements management
software and product management tools.
Posted by michael on August 19, 2006 05:30 PM | Permalink | 3 Comments | Post Comment | Email Friend
Michael, this is excellent timing. In my new company, we are in the process of defining requirement
documents and responsibilities in our product management and engineering teams, so this is very valuable
input.
I agree 200% with your point: "all organizations do not use these terms in the same way. Think of these
documents as points on a spectrum. Each organization defines which documents to create and where in the
spectrum those documents fall - depending on what best fits their unique needs."
Sometimes people think that there is one right way. But there is not, it depends on company size, product life
cycle, plus other factors. Nice post.
Posted by: Kevin | August 19, 2006 11:15 PM
Early this year, I wrote about how requirements document proliferation is an indication of just how much
confusion there is about requirements.
Hi Roger,
Thanks for the link!
I highly recommend Roger's post, check it out.
I see the point in his sentiment "In the final analysis, there may be some merit in some cases to
producing different requirements documents. But I think that it mostly exemplifies the confusions
about requirements...".
This is partly why I personally recommend writing just one document called MRD which can cover
everything described above in BRD, MRD and PRD. Of course, this is only possible in smaller
organizations.
In larger organizations, different people (with different job titles) write each document - so it may not
be possible to combine into one document.
- Michael
Posted by: Roger L. Cauvin | August 20, 2006 08:57 AM
In your response to Roger, you said:
---quote---
(December 17, 2006) Seven Traits of Successful Product Managers
(November 13, 2006) Five Tips for Creating Products With Kick-Butt Design
(October 25, 2006) The Soul of Your Product - Know What It Is?
(August 19, 2006) Requirements Document Alphabet Soup - Explained
(August 06, 2006) Create Successful Products by 'Getting in the Van'
Go to archives of all articles >
CHECK OUT THESE RECENT ARTICLES
COMMENTS
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
6 of 7 3/31/12 10:54 AM

7. This is partly why I personally recommend writing just one document called MRD which can cover everything
described above in BRD, MRD and PRD. Of course, this is only possible in smaller organizations.
---quote---
What do you see as the "cons" of having multiple requirements documents in smaller organizations such as
my company?
Hi Josh,
That is a very good question.
The main reason is:
In smaller companies it is likely that the same person writes all these documents.
If that is the case, it is much easier to write, read and maintain if requirements are contained in one
document.
- Michael
Posted by: Josh Thomson | August 21, 2006 09:15 PM
essay writer wrote: It is always better at first o write and then to talk about the subjec... [more]
On: 10 Tips for Writing Better MRDs - Part 1
Robert wrote: You should compare software available for product managers and product... [more]
On: Product Management & Product Marketing - A Definition
Dilawar wrote: Michael, Nice article. I totally agree with you that User, and User I... [more]
On: Five Tips for Creating Products With Kick-Butt Design
Mickey Mixon wrote: Great design is about sweating all the details - so that when our user... [more]
On: The Soul of Your Product - Know What It Is?
Florian wrote: Hi, I found your blog via google by accident and have to admit that y... [more]
On: Sun Tzu on Product Strategy - Part 1
Go to archives of all articles >
RECENTLY COMMENTED-ON ARTICLES
Subscribe via RSS Feed | Subscribe via Your Email Address:
Subscribe me
GET *FREE* UPDATES ON ALL FUTURE ARTICLES!
Michael on Product Management & Marketing: Requirements Docume... http://michael.hightechproductmanagement.com/2006/08/requirement...
7 of 7 3/31/12 10:54 AM