A second problem is that one person’s how is another person’s what. It’s a matter of abstraction. For instance:
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.
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.
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:
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:
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.
