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.

Comments

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)

Cheers
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

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

What Product Managers Can Learn from the Apple iPod

The Story When Apple unveiled its iPod digital music player back in October 2001, I dismissed it as a  parity product . I already owned the Cowon iAUDIO CW100 MP3 player, loaded with my favorite tunes. There was Apple, generating great hype over the iPod as if it were a breakthrough product. The idea of a portable digital music player was nothing new. The first mass-produced MP3 players came out in 1998. In late 2001, the concept may have been new to a lot of Apple customers, but it wasn't new to me. I proudly showed my MP3 player to friends when they gushed about the iPod. Thus Apple's iPod was not an innovative product in and of itself. Years later, however, I realized the significance of ecosystem of which the iPod was a part. Apple had released iTunes (with technology purchased from  SoundJam MP ) and created the iTunes Store for finding and downloading music. Unlike Napster , it was a safe and legal way of distributing and acquiring music. The prior way of playing