神马文学网Michael on Product Management & Marketing: Re...
来源：百度文库 编辑：神马文学网 时间：2024/04/29 17:24:40
Requirements Document Alphabet Soup - Explained
3 Comments Latest comment by: Josh Thomson
reddit | 
digg it! | 
del.icio.usEarlier 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?
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:
- BRD
- MRD
- PRD
- FSD
- PSD
- SRS
- 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
- Who have the pains
- MRD - Market Requirements Document
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 problems
- Market and competitive analysis
- Functional and non-functional requirements
- Prioritization of features/requirements
- Use cases
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.
- 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.
Like This Article?Why not share it with friends and colleagues?
Just click here...
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.
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.
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.
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.
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 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.