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.

Comments (3)

  1. Machiel Groeneveld - Reply

    January 20, 2008 at 12:28 pm

    I agree the distinction between what and how is arbitrary. I think the 'what vs. how' debate is a symptom of a deeper issue. I think the issue is that your stakeholder has his/her own view of reality and what they need from your project. The tricky part is that these needs and views might not be what the organisation really needs. If the requirement is too precise and not part of the stakeholders expertise, that could be a sign that they are giving you the 'efficient' requirement: leaving out the why and alternatives, so the project will just 'fix' their problem. Of course, you can't prevent that from happening, so it would be great if you can work with your stakeholders during the project to discover what the organisation really needs. If you can agree that no one is 'right' and responsibility for the end product is shared, you can be truly effective.

  2. Sander Hautvast - Reply

    January 21, 2008 at 10:24 am

    You said:
    >>“The system should bring me from A to B” can be a valid “how”

    Is that so? Exactly how are you going to get there? This statement leaves open if it's going to be a plane, train or automobile, etc.

    >>“A requirement is an externally observable characteristic of a desired system”.

    Yes, and there's functional and non-functional requirements. Both can be equally important to a customer (group of different stakeholders). But documenting them serves different purposes.
    A functional requirements document should be readable to any stakeholder interested in the functionality, be it a developer, tester, project manager, or end user.
    Other stuff like design guidelines and code quality requirements is not primarily interesting for (for example) testers and should therefore be documented elsewhere. This is merely a way of creating readable and maintainable documentation.

    So I think your final conclusion is valid, but the picture you draw is not entirely adequate.
    Yes, and there's functional and non-functional requirements. Both can be equally important to a customer. But documenting them serves different purposes. A requirements document should be readable to any project member interested in the functionality,

  3. Erwin Bolwidt - Reply

    January 23, 2008 at 9:38 pm

    Sander, you're thinking too literally. Hows and whats exist on different levels. "The system should consist of a car" is also a how, but it still doesn't tell you which car, what the insurance should be, if it should have a chauffeur, etc. It's still a how. Likewise, “The system should bring me from A to B” can be a valid “how”.

    The second part of your comment, I don't really understand. If something is a requirement, it should be documented as a requirement; if something is a guideline, it should be documented as a guideline.
    In my example, it is a requirement, so it should be documented as such.

    Both functional and non-functional requirements are requirements. Perhaps your question is a more basic question about requirements management, but it is not the subject of this blog posting.

    Your last statement "A requirements document should be readable to any project member interested in the functionality" is not valid, so maybe you misunderstand the purpose of a requirements specification. If that's the case, let's take it up by e-mail because it diverges too far from the topic of this post.

Add a Comment