The Fuzzy Line Between Requirements and Design
It’s often said that requirements are about what and design is about how. There are two problems with this simplistic demarcation.
It’s often said that requirements are about what and design is about how. There are two problems with this simplistic demarcation.
First, this makes it sound like there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize what and design should emphasize how.
It is often valuable to take some tentative steps into the solution space and explore possible designs that might satisfy some requirements you have in hand. This exploration helps to assess the clarity, correctness, completeness, and feasibility of those requirements. Prototyping is a valuable technique for making preliminary probes into design. Getting feedback on user interface prototypes is an excellent way to confirm that your requirements explorations are on the right track.
A second problem is that one observer’s how is another person’s what. It’s really a matter of abstraction. Figure 1 illustrates an abstraction scale for the sequence of going…
