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.
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 relationships continues to the lowest abstraction level.
Solution Ideas and Design Constraints
The issue with requirements specification and design is not what versus how. It’s a matter of distinguishing the real user need from just one possible description of how 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. Maybe that’s, not the only way, the best way, or even a good way. Focusing on solutions masks the underlying requirement. This can make it difficult for a developer to understand what the user is really trying to do so he can devise the best way to meet that expectation.
Legitimate design constraints are perfectly appropriate. Developers need to know about them. Including the rationale behind imposed constraints along with the requirement can preempt questions that might arise as developers wonder if they have any design latitude. The risk is that requirements discussions will focus on solutions that the customer or business analyst thought of and will impose unnecessary constraints. This is frustrating for the developer and often leads to a suboptimal outcome. One of my consulting clients described her experience with this sort of situation:
“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 business requirements with the business analyst. This is very inefficient and frustrating for meeting participants.”
I’m more comfortable with design constraints embedded in requirements when specifying enhancements to be made in an existing system. The existing reality of the current product necessarily imposes many constraints. New development products are also subject to constraints, as when the new product is part of an existing product family or is being built from a common product platform.
Designers must respect the architecture and external interface conventions that are built into the current product. You don’t want designers coming up with user interface displays that are racially different from those with which the users are already familiar.
Rather than getting hung up on whether this information constitutes requirements or design, remember the key objective of requirements development: clear and effective communication. Beware of a premature emphasis on the solution that doesn’t carefully consider the problem to be solved and ensure that the specified solution is appropriate.
The BA needs to detect when a solution is being discussed instead of a requirement. This should lead to a discussion about the underlying need that led to the customer proposing that specific solution. Instead, use the solution idea as a starting point to drill down to a deeper understanding of what the customer is really trying to accomplish. Maybe solution idea is great, but don’t get painted into a constraint corner prematurely.
Asking “why?” several times is often a good way to arrive at this understanding. The BA must determine which of the following situations applies when he detects a proposed solution.
- Was that solution just one that popped into the speaker’s mind?
- Is that the only possible solution (a true constraint)?
- Is the speaker more interested in exploring solutions (which is fun) than in understanding the problem (which is hard)?
- Could this solution be solving the wrong problem?
- Does someone think this is the necessary solution for some inappropriate reason, such as an erroneous assumption or obsolete business process?
- Is the solution idea worth passing 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 that specific technologies or UI controls be used without a clear justification. Following are some examples, most drawn from actual projects.
- “The Defect Calculator should be written in Excel.” Whenever a BA hears a requirement like this, she should ask “Why?” Why Excel? Maybe there’s an excellent reason, in which case it might be perfectly appropriate to include the technology constraint in the requirement (along with an explanation). But maybe there’s nothing magic or essential about using Excel, and the developers should be free to explore other possible solutions.
- “A master power on/off button shall be installed on the front panel.” Further discussion might surface an explanation of why this precise design approach is needed. Perhaps it’s required for compatibility with an existing product, or maybe it will conform to a pertinent standard or safety requirement.
- “If the pressure in the tank exceeds 40.0 PSI, the system shall illuminate the amber pressure warning light.” The BA could ask if this requirement should be made more general, so as to permit the designer to consider various ways to alert the operator about the high tank pressure. But the customer might say, “No, the operator console has an amber pressure warning light for exactly this purpose, and it had better come on if the pressure exceeds the limit.” This is a good reason to include a design constraint as part of the requirement.
- “The user clicks on OK to submit the request.” This requirement assumes the existence of an “OK” button. Perhaps it would be clearer if the button said “Submit Request.” If you’re adding an enhancement to an existing UI, it’s fine for a requirement to include the precise user action. But if you’re specifying a new product, avoid constraining the UI options like this. Maybe it would make more sense to use a touch interaction or speech recognition. A more general requirement could say, “The user shall be able to submit the request.” This leaves the specifics of that action to the designer.
- “The Background Task Manager shall display error messages in the status bar.” If the application already contains a status bar for messages, this is exactly the right requirement. But what if the decision hasn’t already been made to include a status bar in the UI? This requirement imposes a design constraint that precludes other ways a developer might imagine to present error messages.
Taking the time to drill down to the underlying requirement behind a presented solution can pay off. In the early 1980s my software group wrote a program to control some laboratory equipment. One user asked us to write a pop-up calculator program to go along with this control software. The developer on that project thought, “Cool! I’d love to write a pop-up calculator program.”
But then we thought about it some more. The user needed to perform calculations while the computer was busy running the lab equipment (this was before PCs were multitasking). We concluded that it would be cheaper to buy each of our 150 users an actual calculator. This solution wasn’t nearly as entertaining as writing a pop-up calculator program but it was a lot less expensive.
Either approach would have met the customer’s need. And that’s the bottom line in software development.
If you’re interested in requirements and business analysis, Process Impact provides numerous useful publications and other resources.