Contribution 6

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Always question the customers intent with a requirement.)
(Always question the value to be provided by a required capability.)
Line 1: Line 1:
== Always question the value to be provided by a required capability. ==
== Always question the value to be provided by a required capability. ==
-
Very often customers 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 provide an Mac 2 - 2.5 aircraft. When they asked the question why, the answer provided by the air force was to be able to escape from combat, a capability supported by agility in the design, 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 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.
-
This lesson should be brought into software development as well. By asking for the value to be provided by a feature or requirement, its possible to provide a more elegant, better and probably cheaper solution.
+
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:01, 10 May 2008

Always question the value to be provided by a required 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.

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.

Personal tools