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.
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

Interaction Design: the Neglected Skill

Your product development organization has a big, gaping hole in it. (Be prepared to feel defensive as you continue reading.) One of the most important roles in product development is the role of interaction designer. An interaction designer designs how the users will interact with the product and conceptualize the tasks they perform. He decides whether, for example, the user interface will be command driven, object oriented (clicking on objects then specifying what to do with them), or wizard based. The interaction designer decides the individual steps in the use cases. Every company has one or more people that play the interaction designer role. Usually, those people have little or no expertise in interaction design. Sadly, they typically don't even realize how unqualified they are. Let's see who typically plays the role at companies. Engineer . An engineer is an expert on building what is designed. Yes, an engineer may know how to design the internal structure of the hardware

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