Contribution 6

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(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 F16 Falcon. His team was requested to design a Mac 2 - 2.5 aircraft, a capability that is real hard to meet. When the design team asked the air force why, they was told that max speed in the magnitude of Mac 2 - 2.5 was required to escape from combat. When the real need was articulated the design team was able to provide a good solution, basically aircraft agility combined with an high thrust weight ratio, providing high acceleration, not maximum speed.
+
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

Personal tools