Is it a Requirement or is it Design?

Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. The “how” can become the “what” and vice versa.
For example,
What: “The system should bring me from A to B”
How: “The system should consist of a car”
Now consider:
What: “I need to be able to have meetings with people at different locations”
In this case, “The system should bring me from A to B” can be a valid “how”, as can “The system should provide teleconferencing capabilities”. Which one of those would be best depends on other needs of the stakeholders, not on “how” or “what”.
In his book “Just Enough Requirements Management”, Alan M. Davis defines two aspects of a requirement that I find very useful.
He states: “A requirement is an externally observable characteristic of a desired system”.
In other words, it must be possible to check that the requirement is fulfilled from outside of the system. The second aspect of a requirement is that it should fulfill some need of a stakeholder.
A requirement like “The car should be produced in the colors red, yellow and blue” can be valid. It is surely externally observable. If it turns out that these are the most popular colors among the buyers of the car, and that the painting installation can only handle three different colors, then it also satisfies the needs of more than one stakeholder.
Almost any aspect of a system can be externally observable (in the right context, from the perspective of a particular stakeholder). Take an extreme one, “no method in the Java programming language shall exceed 1200 characters in length (excluding spaces)”. This can be valid, from the viewpoint of maintainability of the code. Perhaps a tool is used that doesn’t support that many characters or the stakeholder has good reason to believe that this will make it easier to maintain the code. In that case it is a requirement. It should still be balanced against the needs of other stakeholders, of course.
So to determine if a requirement is good, you don’t focus on the simple mantra “is it a design, then it is not a good requirement”. What matters is how far it satisfies a need of a stakeholder, and a better requirement satisfies more needs, or more important needs, than a worse requirement.