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.