Skip to main content

MRDs, PRDs, FRSes, and SRSes

Another manifestation of this high and low level requirements business is the proliferation of different kinds of requirements documents. Let's review:

MRD - market requirements document (a.k.a. "marketing requirements document")
PRD - product requirements document
FRS - functional requirements specification (a.k.a. "feature requirements specification")
SRS - software requirements specification

Some organizations incorporate several of these kinds of documents in their product development process. But what are the differences among them?

Some people argue that MRDs are at a "higher level" than the other documents. I have argued that this high versus low level distinction makes little sense. But if you examine the terminology of these different kinds of documents, it reinforces the notion that there is a lot of confusion when it comes to requirements.

First of all, a requirement is a requirement; why would you have different documents describing the same thing?

Second, what is a "functional requirements specification"? Does it strip the nonfunctional requirements from the full requirements? Or does it somehow translate nonfunctional requirements into functional requirements, in which case it's really decomposing the requirements into design specifications? If so, why call it a "requirements" document?

Third, what could possibly be the difference between a market requirements document and a product requirements document? Shouldn't products be driven by market needs? Okay, sometimes the needs and constraints of stakeholders outside the market (e.g. internal stakeholders) should play a part. But shouldn't a single document capture the balance of needs, rather than two separate documents written by separate people?

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 - particularly the distinction between requirements and design.


Michael said…
Dude, you hit the nail on the head with this one. To me, these documents serve two purposes:

(1.) An application of Conway's Law (I get unlimited milage out of that Law). You can usually map each of those documents 1-1 to an org-chart.

(2.) A hide-out for people who aren't technical enough (they don't need to be programmers, but they should know the product and what's technologically possible) to share the authoring of a single document. That is, by stripping away "functional" things, authors/owners of the MRD and other non-programmer *RDs don't have to bother with "low level" stuff. Those pesky coders can do that in their *RD.

Also along those lines, I'd be curious about your thoughts on what I'm starting to call Rallygile, Rally Software Development's emerging extend-and-embrace of Scrum. They have user stories, but then they tree them out from themes->features->requirements.

I like their general approach, but that hiarchy is in danger of creating the problems you and I (in this comment) are talking about.
Roger L. Cauvin said…
Nice point about the application of Conway's Law.

I don't know enough about the difference between "Rallygile" and other agile approaches to be able to comment much about how they deal with requirements. Based on a cursory examination of their web site, however, it appears they have some of the same confusion about the requirements as I've mentioned time and time again in this blog. Hopefully, in their case, it's mostly just semantic confusion.

Going from requirements to architecture to design to implementation is obviously essential, regardless of what terminology you use to describe the activities. The problems mainly arise when there is confusion about what the activities and distinctions are, and when teams don't perform them in a flexible and collaborative way.
Roger L. Cauvin said…
A clarification: when I state, "Going from requirements to architecture to design to implementation is obviously essential," I certainly don't mean that teams should perform these activities in a waterfall fashion.
Scott Sehlhorst said…
Roger - great conversation you've started with Cote'. Thanks!

We've extended it over at Tyner Blain and would love you to join in over there. The post is titled Requirements document proliferation.

See you there...
Rupinder Parmar said…
Hi folks

In my organization we use a Business Requirements Spec (BRS)

and a Functional Requirements Spec (FRS) for each project.

BRS is used mainly agree upon what the problem and the scope. its audience are the project owner (mostly execs)
When we reach the FRS stage we start talking about how the BRs specified in BRS will be fulfilled complete with a traceability matrix.
Earlier we would jump straight to FRSes and result was more problems on the project go live day and afterwards.
Now we (BA's and PM's) are able to better control the scope of the project.
There have been virtually no (big) problems at the time of project launch since we started using the proper procedure for requirement specs. We do better estimations, the execs dont just rock up next to a developer to get something developed

If you dont understand the problem (Business Need) good enough how will you solve it (Functional Spec)

Roger L. Cauvin said…
But rupinder, isn't it a little strange that "how you will solve it" is in a functional requirements document?

And where do the nonfunctional requirements go?

Popular posts from this blog

Why Spreadsheets Suck for Prioritizing

The Goal As a company executive, you want confidence that your product team (which includes all the people, from all departments, responsible for product success) has a sound basis for deciding which items are on the product roadmap. You also want confidence the team is prioritizing the items in a smart way. What Should We Prioritize? The items the team prioritizes could be features, user stories, epics, market problems, themes, or experiments. Melissa Perri  makes an excellent case for a " problem roadmap ", and, in general, I recommend focusing on the latter types of items. However, the topic of what types of items you should prioritize - and in what situations - is interesting and important but beyond the scope of this blog entry. A Sad but Familiar Story If there is significant controversy about priorities, then almost inevitably, a product manager or other member of the team decides to put together The Spreadsheet. I've done it. Some of the mos

Henry Ford's "Faster Horse" Quote

You may have heard the ( apocryphal ) Henry Ford quote: If I'd asked customers what they wanted, they would have said "a faster horse". Over at the On Product Management blog , Saeed gives his take on this infamous quote. He "hates" it, and gives some compelling reasons. Saeed is spot on in his explanations. Personally, I think the quote is great, but it's a matter of interpretation. The valid point of the quote is not that it's a bad idea to facilitate a conversation with your market to better understand it. The valid points are: You must ask the right questions to get valuable answers. You must interpret the answers thoughtfully - often outside their direct meaning - to glean reliable information. Asking questions is not always the best way to "listen" to your market. (E.g., sometimes pure observational studies are more reliable.) Nonetheless, I find the quote is helpful to combat "armchair product management" in the

Stop Validating and Start Falsifying

The product management and startup worlds are buzzing about the importance of "validation". In this entry, I'll explain how this idea originated and why it's leading organizations astray. Why Validate? In lean startup circles, you constantly hear about "validated learning" and "validating" product ideas: The assumption is that you have a great product idea and seek validation from customers before expending vast resources to build and bring it to market. Indeed, it makes sense to transcend conventional approaches to making product decisions . Intuition, sales anecdotes, feature requests from customers, backward industry thinking, and spreadsheets don't form the basis for sound product decisions. Incorporating lean startup concepts , and a more scientific approach to learning markets, is undoubtedly a sounder approach. Moreover, in larger organizations, sometimes further in the product life-cycle, everyone seems to have an opinio