Perhaps a rather harsh title for this posting. It is tame compared to my working title for "business requirements" which would involve flogging.

Anyway, it is worth mentioning up front that I am not against "market-driven requirements" only "market requirements".

Let me explain the difference. A market-driven requirement is a requirement that has an external source (hopefully many sources) like a customer request, win/loss analysis or a call report as reference. This is good. Where the process breaks down for people is that the translation from the original external source results in a market requirement. I am not sure even what a market requirement is. Actually, now I do. Check this website out: Babylon.com - Market requirement. This makes some sense. Doesn't change my thinking. The first problem lies in the fact that people are writing market requirements as a record and calling it "being market-driven." The second problem is that people are using "market requirements" as a record and using it to organize "technical" or "sub-" or "product" or "other" requirements. If you are looking for a hierarchy, then write a problem statement. Articulate the problem to be solved and then write product requirements. A problem statement is a more focused and effective document. The third problem is that people are passing these "market requirements" directly to development. It is actually this fact that I have a problem with. Unless your "market requirement" is describing a condition that is required to solve a problem is it not a requirement.

Your goal is to write market-driven requirements and if you have market data behind the requirement you will have market-driven requirements. But they are still not "market requirements" they are "product requirements" (i.e. requirements for your product) that are market-driven.

To summarize... market-driven product requirements good... market requirements bad.