Contribution 6

From WikiContent

Revision as of 15:52, 15 May 2008 by Elandre (Talk | contribs)
Jump to: navigation, search

Always ask for the value to be provided by a requested capability.

Very often customers and end-users state what they think is a viable solution on a problem as a requirement. The classical story on this was first told by Harry Hillaker, the lead designer of the F-16 Falcon. His team was requested to design a Mac 2 - 2.5 aircraft, which was then, and probably still is, a non trivial task to do.

When the design team asked the air force why they needed Mac 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 problem and provide a working solution. Their solution was an agile aircraft with an high thrust-weight ratio, providing acceleration, not maximum speed.

This lesson should be brought into software development as well. By asking for the value to be provided by a requested feature or requirement. By understanding the value and real need the designers are able address the real problem, and hopefully in the end provide a more elegant, better and hopefully cheaper solution compared to addressing the stated need in a head on approach. By understanding the value behind a requirements also makes prioritizing simpler, as a value can be quantified.

So, how to proceed then? My experience is to have workshops or meetings with the customer, where the architects focus should be on understanding customer needs, including helping the customer to state the value from a stated need, not on how to provide an implementation.

This approach fits well with SCRUM sprint planning sessions, for those practicing agile methods. For those stuck in their water fall processes, this type of meeting need to be an integral part of their requirements elicitation process.

By Einar Landre

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Software Architect Should Know home page

Personal tools