First, this statement sounds as though there’s a sharp boundary between requirements and design. There’s not. In reality, between requirements and design lies a fuzzy gray region, not a crisp 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 certain requirements. This exploration can assess the clarity, correctness, completeness, and feasibility of those requirements. Prototyping is a good way to make preliminary probes into design. Getting customer feedback on user interface prototypes or assessing the viability of technical prototypes helps ensure you’re on the right track.
A second problem is that one person’s how is another person’s what. It’s really a matter of abstraction, as shown in Figure 1. This abstraction scale goes from the motivation for undertaking a software project clear down to the nuts and bolts of exactly how the team builds the product. Each pair of adjacent steps in this scale represents a kind of what information at the higher abstraction level and a kind of how information at the lower abstraction level.
Look at the second box from the top. If we asked, “What will the user be able to do with the product?” we might identify several use cases, scenarios, or stories that describe user interactions with the product that lead to some valuable outcomes. If we then asked, “How will we let the user perform those use cases?” we might produce a list 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?” The sequence of what and how relationships continue down the abstraction scale.
Solution Ideas and Design Constraints
The essential issue is distinguishing the real customer need from just one possible way a 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 masks the underlying requirement. This can make it difficult for a developer to understand what the customer is really trying to do, thereby making it hard to choose the most appropriate approach.
Legitimate design constraints are perfectly appropriate, and developers need to know about them. Including the rationale behind imposed constraints along with the requirement can preempt questions the developers might have as they wonder if they have any design latitude. Unnecessary design constraints frustrate developers and can lead to a suboptimal outcome. One of my consulting clients described her experience with this:
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 (BA). This is very inefficient and frustrating for meeting participants.
I’m more comfortable with requirements that contain design constraints when you’re specifying enhancements for an existing system than with new product development. A current product necessarily imposes many constraints. Designers must respect the reality of the architecture and external interface conventions. The requirements for an enhancement might involve changing a screen layout, adding a new input field or two, modifying the database to accommodate the new data elements, revising a report, and the like. Such changes must integrate smoothly with the existing reality, so constraints are natural in these situations.
Rather than getting hung up on whether the specs for these modifications constitute requirements or design, remember the key objective of requirements development: clear and effective communication. The business analyst should document whatever information is necessary to make sure the correct changes are implemented. Beware of a premature emphasis on the solution that doesn’t carefully consider the problem to be solved and that doesn’t 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 customers about the underlying need that led to that proposed solution. Don’t summarily dismiss the customer’s solution idea; important information is hiding in there somewhere. It’s possible that the customer’s solution idea is appropriate, but don’t let the customer—or any other stakeholder— paint the development team into a constraint corner prematurely.
A good technique when a BA hears a proposed solution is to ask “why,” perhaps several times. Then he can determine which situation applies:
- Did the solution just pop into the speaker’s mind as a possible option to
consider? - Is it the only possible solution (that is, a true constraint)?
- Is the speaker more interested in exploring solutions (which is fun) than in
understanding the problem (which is hard)? - Is the solution inappropriate for some reason? It might be based on erroneous
assumption or a continuation of the way the business operated 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 that specific technologies or user interface controls be used without a clear justification. If there is indeed a good reason to impose the design constraint, including that rationale will help the readers. Here are some examples of requirements that contain solutions:
- “The Defect Calculator should be written in Microsoft Excel.” The BA should ask, “Why Excel?” If there’s an excellent reason, include the technology constraint in the requirement along with an explanation. However, maybe there’s nothing magical about Excel here, and the developers should be free to explore other approaches.
- “A master power button shall be installed on the front panel.” Further discussion might reveal why this design is necessary. Perhaps it’s required for compatibility with an existing product, or maybe it will conform to a pertinent standard or safety requirement. Or it could imply an unstated ease-of-use requirement.
- “If the pressure in the tank exceeds 40 PSI, the system shall illuminate the amber pressure warning light.” Could this requirement be made more abstract so the designer can consider various ways to alert the operator about the high tank pressure? If the customer says, “No, the operator console has an amber warning light for exactly this purpose, and it had better come on if the pressure exceeds the limit,” that’s an appropriate design constraint.
- “The Background Task Manager shall display error messages in the status bar.” If the application already contains a status bar where users look for messages, this is the right requirement. But what if the decision hasn’t already been made to include a status bar in the user interface? This requirement imposes a design constraint that precludes a creative developer from exploring alternative, and perhaps better, ways to present error messages.
Drilling down to the underlying requirement behind a presented solution can pay off. Long ago, my software group at Kodak was implementing a PC-based program to control some laboratory equipment. This was before we had multitasking operating systems. One of our users requested a pop-up calculator program to go along with this control software. The developer’s reaction was, “Cool! I’d love to write a pop-up calculator program.” But then we thought about it some more.
The real need was for the user to be able to perform calculations while the computer was busy running the lab equipment. We concluded that it would be cheaper to buy each of our 150 users a handheld calculator, put a piece of Velcro on the back, and mount it on the side of the computer monitor. This solution wasn’t nearly as entertaining as writing a pop-up calculator program, but it was far cheaper. Either approach would meet the customer’s need. And that’s the bottom line in software development.
About the Author
Karl Wiegers Karl Wiegers, is Principal Consultant with Process Impact, a software process consulting and education company in Portland, Oregon. Karl holds a Ph.D. in organic chemistry. Karl’s most recent book is a memoir of life lessons called Pearls from Sand: How Small Encounters Lead to Powerful Lessons (PearlsFromSand.com). You can reach Karl at Processimpact.com.