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.

Karl Wiegers
Analyst’s corner
Published in
7 min readJul 30, 2019

--

An abstract image with gray on top, white on the bottom, and a dark gray, fuzzy line in between.
Graphic by author

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 from some motivation for executing a software project down to the nuts and bolts of exactly how the software is implemented. You can think of each pair of adjacent steps in this scale as representing a type of what information at the higher abstraction level and a type of how information at the lower level.

A diagram showing a stack of software development artifacts with decreasing abstraction from top to bottom: Business objectives, use cases, functional requirements, architecture, detailed design, code.
Figure 1. Levels of abstraction in software development.

Look at the second box from the top. If we asked, “What will the user be able to do with this product?” we might come up with several use cases for the product that yield valuable outcomes. If we then asked, “How will we let the user perform those use cases?” we might come up with a list of specific product features, functional requirements, and characteristics, as shown in the third box down. This information answers the question, “What should the developer build?” This sequence of what/how…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com