Insights Blog Requirements vs. Design

White Paper

Requirements vs. Design

Some people say that requirements are about what you build, and design is about how you build it. This simplistic statement may sound right, but there are two potential problems with condensing the matter in this way. First, it makes it sound like there should be a sharp boundary between requirements and design, when that’s not really the case. In reality, the region between the two is actually very grey and foggy, not a crisp line at all. I prefer to say that requirements should concentrate on what and design should concentrate on how. It is important to explore possible designs that might satisfy certain requirements; a valuable method for assessing the clarity, correctness, completeness, and feasibility of these is through prototyping. Getting customer feedback on prototypes helps ensure you’re on the right track.

Kelvin Kam

A second problem is that one person’s how is another person’s what.  It’s a matter of abstraction. For instance:

  • Business Objective: Why undertake the project?
  • Use Cases and Scenarios: What can the user do with the product?
  • Functional Requirements and Features: What did the developer build?
  • Product and Interface Architecture: How do the components fit together?
  • Database and Modules Design: How should individual components behave?
  • Algorithms: How does one implement each component?

These abstraction scales go from the motivation for undertaking a software project clear down to 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.

Solution Ideas and Design Constraints

Most important is distinguishing the real customer need from just one way a developer could satisfy that need.  Writing a solution idea into a requirement imposes a design constraint.  The requested solution describes one way to satisfy some requirements but perhaps not the only way, the best way, or even a good way.  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. However, design constraints are perfectly appropriate, and developers need to know about them. Nevertheless, unnecessary design constraints will definitely frustrate developers and can lead to wrong solutions.  Below is a good example from a previous experience:

One of the biggest issues I am having with the designer is that they focus too heavily 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 finding a solution. We have wasted many hours of meetings over one project because the designer proposed a solution and didn’t bother about user requirements from the Business Analyst (BA). This is very inefficient and frustrating for everyone present.

Sometimes including design constraints in requirements is necessary, especially when you are trying to specify enhancements on an existing system.  A current product will impose 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, etc. Such changes must integrate smoothly with the existing reality, so constraints are natural in these situations.

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. Ensure the problem to be solved is carefully considered and the specified solution is a good option before coming up with the final solution.

Solution Clues

The BA should be able to detect when a requirement imposes unnecessary design constraints and a discussion with the customers which can lead to the proposed solution is.  Don’t dismiss any 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 — draw the development team into a constraint corner prematurely.

A BA should ask “why?” whenever a proposed solution comes up. 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 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 design constraint is that the customer requests specific technologies or user interface controls without a clear justification.  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 must 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 specific standard or safety requirement.
  • “If the pressure in the tank exceeds 40 PSI, the system must 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 must 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 prevents 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.  One of our software groups had an interesting experience related to this when implementing a PC-based program to control some laboratory equipment. This was before they had multitasking operating systems.  One of the 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 after a bit of thought and discussion, they realized that then 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 the 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.  Both approaches would meet the customer’s need and that’s the bottom line in software development.