OFTEN CUSTOMERS AND END USERS state what they think is a viable solution to a problem as a requirement. The classic story on this was told by Harry Hillaker, the lead designer of the F-16 Falcon. His team was asked to design a Mach 2–2.5 aircraft, which was then, and probably still is, a nontrivial task—especially when the objective is to create a “cheap” lightweight aircraft. Consider that the force required to overcome drag quadruples when doubling the speed, and what impact that has on aircraft weight.

When the design team asked the Air Force why it needed Mach 2–2.5, the answer was “to be able to escape from combat.” With the real need on the table, the design team was able to address the root problem and provide a working solution: an agile aircraft with a high thrust-to-weight ratio, providing acceleration and maneuverability, not maximum speed.

This lesson should be brought into software development as well. By asking for the intended value of a requested feature or requirement, architects are able to address the real problem, and hopefully provide a better and cheaper solution than that suggested by the client. The focus on value also simplifies prioritization: the most valuable requirements become the driving requirements.

So, how to proceed then? In many ways the required approach is found in the agile manifesto: “Collaboration over contract.” Practically speaking, this implies arranging workshops and meetings where the architects’ focus is on customer needs—helping the customers to answer the “why” question. Be aware that answering the “why” question can be difficult because we very often talk about tacit knowledge. Discussions on how to provide a technical solution should be avoided in these workshops, because they move the focus away from the customer’s domain and into the domain of software development.