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.
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
(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.
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.
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
And where do the nonfunctional requirements go?