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.

The Fuzzy Line between Requirements and Design

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.

Author: Karl Wiegers, Process Impact

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).

Like this article:
  41 members liked this article


Joe posted on Wednesday, April 15, 2015 10:41 AM
Karl, I like your distinction between the Requirements and Design issues. We run into this daily here at work. I find it has become the "Order Taker" syndrome, where they are all now Diner Waiters and Waitresses. I can hear Alice asking - "What can I get ya honey?"

OK, we laugh, but it is true. The analysts on my team come back with a definition of what the business wants, not what the need. Your list of examples hits close to home, are you sure you weren't here where I work?? I see requirements that say, "Create in Excel" or "Report from Business Objects" or "Put data in this field and on that screen" regularly.

The Business ALWAYS has a solution in mind, it is up to the ANALYST to hear it and challenge it, then document the NEED behind it. In addition, the BA's cannot lose the context of the description from the Business.
Janis posted on Sunday, April 19, 2015 8:19 AM
I have been saying this for years and yet it still an issue. It is also what I tell other analyst that I work with but some how I am finding that many lack .... to accomplish this.
Tony Heap posted on Sunday, April 19, 2015 7:04 PM
Hi Karl, nice article.

I take an extreme view on this topic. I find that trying to draw a distinction *at all* between requirements and design is unhelpful and causes confusion.

In my view, Business Analysts are *designers of business change*. We design business processes, we design IT system functionality and we get involved in UX design, although sometimes we rely on UX design specialists to help us. We don't do IT system technical design but our functional designs and business process designs are informed/constrained by technical constraints.

I get really tired of being told to "stay out of solution space". Given that we are designing business change, it's *all* solution space! People tall me to "just capture the requirements", when really they mean, "just design the to-be business processes and define (design) the to-be IT system behaviour as use cases, user stories, or BDD scenarios".

A key point for me is that BAs need to have (product/functional) design skills - the ability to understand the objective and (collaboratively) create a business change design (or, indeed, multiple options) to achieve the objective. When we recognise ourselves as designers, and adopt a "designer mindset", I think we achieve better outcomes.

Much more on my blog at
Ryan Milligan posted on Tuesday, April 21, 2015 3:51 PM
When I first started as a BA, I was working for a client where the users demanded that specific design points be included in the requirements. While the solution did fit their needs, I know the solution could've been so much better had we not constrained ourselves. In this particular case, the users wanted things like long lists of radio buttons (which took up a lot of screen real estate) instead of dropdowns because, go figure, it's what they were used to. They never got a chance to see what it would've looked like using different UI components, layouts, etc. because the developers went by the requirements. Lesson learned. Since then, I document the requirements free of design (unless, as the article states, the consensus of people whose opinions should truly matter is that a design aspect should be stated explicitly), and document design ideas separately, linking them back to the requirements. It's can be challenge convincing stakeholders to do it this way, but certainly leaves the door open for improvement.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC