The Fuzzy Line between Requirements and Design

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.

First, this makes it sound as though 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’s often valuable to take some tentative steps into the solution space and explore possible designs that might satisfy some requirements you have in mind. This exploration lets you assess the clarity, correctness, completeness, and feasibility of those requirements. Prototyping is a good way to make some preliminary probes into design. Customer feedback on user interface prototypes can confirm that your requirements 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 the sequence of moving from some business motivation for launching a project down to the nuts and bolts of the software implementation. You can think of each pair of adjacent steps in this scale as representing a kind of “what “information at the higher abstraction level and a kind of “how” information at the lower level.

Look at the second box from the top in Figure 1. If we asked, “What will the user be able to do with this product?” we might come up with several use cases, scenarios, or stories that describe user interactions that lead to some useful outcomes. If we then asked, “How will we let the user achieve those outcomes?” we might think of specific features, functional requirements, and product characteristics, as shown in the next box down. This information answers the question, “What should the developer build?” This sequence of what and how relationships continues down the chain.

Solution Ideas and Design Constraints

When it comes to requirements specification and design, we need to distinguish the real customer need from a possible way a clever developer might satisfy that need. Incorporating a solution idea into a requirement imposes a design constraint. The requested solution describes one way to satisfy some requirement—but perhaps not the only way, the best way, or even a good way. Focusing on solutions often masks the underlying requirement, making it hard for a developer to understand what the customer is really trying to accomplish.

Developers do need to know about legitimate design constraints. Including the rationale behind imposed constraints along with the requirement can preempt questions that might otherwise arise when developers wonder if they have any design latitude. Specific solutions that the customer or BA thought of can impose unnecessary constraints, though. This is frustrating for the developers and often it leads to a suboptimal outcome. One of my consulting clients described her experience:

One of the biggest issues I am having with the client support staff is that they focus on the solution. They work closely with the customer and, instead of understanding the business problem or need of the customer, they focus immediately on a solution. We just wasted 30 hours of the company’s time in meetings over one custom project because the client support person proposed a solution and didn’t share pertinent user requirements with the business analyst. This is very inefficient and frustrating for meeting participants.

I’m more comfortable embedding design constraints in requirements when I’m specifying enhancements for an existing system. For instance, designers must respect the architecture and external interface conventions of the current product. The requirements for an enhancement or modification might involve changing a screen layout, adding some new input fields, modifying a database, or revising a report. Such changes must integrate smoothly with the existing reality, so constraints are natural in this situation. For both new development and enhancement, just beware of a premature emphasis on solutions that doesn’t carefully consider the problem so you can ensure that the specified solution is a good option.

Solution Clues

The BA needs to detect when a requirement imposes unnecessary design constraints. This should lead to a discussion with the customer representatives about the underlying need that led to that proposed solution. Don’t summarily dismiss a customer’s solution idea; important information is hiding in there somewhere. Use that input to drill down to a deeper understanding of what the customer is really trying to accomplish. Asking “why?” several times is a good way to reach this understanding. The analyst must determine which of the following situations applies when he hears a proposed solution:

• Was that solution just one that popped into the speaker’s mind?
• Is it the only possible solution?
• Is the speaker more interested in exploring solutions (which is fun) than in understanding the problem (which is hard)?
• Is this a poor solution because the problem isn't properly defined or the solution addresses the wrong problem?
• Does someone think this is the right solution for the wrong reason, such as an erroneous assumption or unnecessarily repeating the way work was done in the past?
• Is the solution idea worth passing along to developers as a suggestion but not as a mandated requirement?

One clue that the discussion has moved into solution space is that the customer requests specific technologies or user interface controls. If there is indeed a good reason to impose the design constraint, including that explanation in a “rationale” requirement attribute will help the readers. Following are some examples of requirements that contain solutions.

• “The Defect Calculator should be written in Microsoft Excel.” The BA should ask, “Why Excel?” Perhaps there’s an excellent reason, in which case it’s fine to include the technology constraint in the requirement along with an explanation. However, maybe there’s nothing magic or essential about using Excel and the developers should be free to explore other approaches.
• “A master power on/off button shall be installed on the front panel.” Further discussion might reveal why this precise design approach is necessary. Perhaps it’s required for compatibility with an existing product, or maybe it will conform to a pertinent standard or a safety requirement. It could reflect an unstated ease-of-use requirement.
• “The user clicks on OK to submit the request.” If the UI has already been implemented and we’re adding an enhancement, then including the precise user action that will submit the request makes good sense. Otherwise, avoid constraining the UI options at an early stage like this. A more general version of this requirement would say, “The user shall be able to submit the request,” which leaves to the designer the specifics of how to perform that action.
• “The Background Task Manager shall display error messages in the status bar.” This is fine if the application already contains a status bar where users know to look for messages. But what if the decision hasn’t already been made to include a status bar in the UI? This requirement imposes a design constraint by demanding a status bar. It also precludes a creative developer from conceiving better ways to present error messages.

Taking the time to drill down to the underlying requirement behind a presented solution can pay off. And meeting the real customer needs is the bottom line in software development.

Karl Wiegers is Principal Consultant at Process Impact. His interests include requirements, project management, peer reviews, and process improvement. This article is adapted from his book More About Software Requirements (Microsoft Press, 2006).