Contribution 6
From WikiContent
(→Always ask for the value to be provided by a requested capability.) |
(→Always ask for the value to be provided by a requested capability.) |
||
Line 1: | Line 1: | ||
== Always ask for the value to be provided by a requested capability. == | == 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 designer of the | + | 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 designer of the F-16 Falcon. His team was requested to design a Mac 2 - 2.5 aircraft,which was a non trivial requirement to meet. |
+ | |||
+ | When the design team asked the air force why they needed Mac 2, they was told that Mac 2 was required to escape from combat. When the real need was articulated the design team was able to provide a good solution, by combining aircraft agility with an high thrust-weight ratio, providing high 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. | 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. |
Revision as of 22:46, 10 May 2008
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 designer of the F-16 Falcon. His team was requested to design a Mac 2 - 2.5 aircraft,which was a non trivial requirement to meet.
When the design team asked the air force why they needed Mac 2, they was told that Mac 2 was required to escape from combat. When the real need was articulated the design team was able to provide a good solution, by combining aircraft agility with an high thrust-weight ratio, providing high 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 Einar Landre
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page