Contribution 6

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Always ask for the value to be provided by a required capability.)
Current revision (17:28, 2 July 2008) (edit) (undo)
 
(15 intermediate revisions not shown.)
Line 1: Line 1:
-
== Always ask for the value to be provided by a required 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.
+
Often customers and end-users state what they think is a viable solution to a problem as a requirement. The classical story on this was 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. At least when the aim is a "cheap" lightweight aircraft. Remember that the force required to overcome drag quadruples when doubling the speed, and what impact that have on aircraft weight.
-
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.
+
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 root problem and provide a working solution. Their solution was an agile aircraft with an high thrust-weight ratio, providing acceleration and maneuverability, 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 the designers are able address the real problem, and hopefully provide a better and cheaper solution compared to addressing the stated need in a head-on approach. Understanding the value behind a requirement makes prioritizing simpler, as a value can be quantified and ranked. The most valued requirements become the driving requirements.
 +
 
 +
So, how to proceed then?
 +
There is probably only one way, arrange workshops and meetings with the customer. The architects focus in such session should be on understanding customer needs, including helping the customer to answer the question "why". 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 discussions away from the customers domain and into the domain of software development.
 +
 
 +
The list of ranked capabilities should be brought back to office and assessed with respect to technical feasibility, and the impacts of the assessment should be discussed with the customer. For a large system such assessment involves development of prototypes or demonstrators.
 +
 
 +
With respect to development process, it should be fairly easy to see that this approach is best served by some sort of iterative process. That said, capabilities should be ranked as part of the initial product planning, helping both customers and developers to maximize customer value as early as practical possible. At the beginning of each iteration should be assessed and ranked, making sure that the value is sustained when requirements are further detailed.
Line 10: Line 19:
This work is licensed under a
This work is licensed under a
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
- 
Back to [[97 Things Every Software Architect Should Know]] home page
Back to [[97 Things Every Software Architect Should Know]] home page

Current revision

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

Often customers and end-users state what they think is a viable solution to a problem as a requirement. The classical story on this was 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. At least when the aim is a "cheap" lightweight aircraft. Remember that the force required to overcome drag quadruples when doubling the speed, and what impact that have on aircraft weight.

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 root problem and provide a working solution. Their solution was an agile aircraft with an high thrust-weight ratio, providing acceleration and maneuverability, 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 the designers are able address the real problem, and hopefully provide a better and cheaper solution compared to addressing the stated need in a head-on approach. Understanding the value behind a requirement makes prioritizing simpler, as a value can be quantified and ranked. The most valued requirements become the driving requirements.

So, how to proceed then? There is probably only one way, arrange workshops and meetings with the customer. The architects focus in such session should be on understanding customer needs, including helping the customer to answer the question "why". 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 discussions away from the customers domain and into the domain of software development.

The list of ranked capabilities should be brought back to office and assessed with respect to technical feasibility, and the impacts of the assessment should be discussed with the customer. For a large system such assessment involves development of prototypes or demonstrators.

With respect to development process, it should be fairly easy to see that this approach is best served by some sort of iterative process. That said, capabilities should be ranked as part of the initial product planning, helping both customers and developers to maximize customer value as early as practical possible. At the beginning of each iteration should be assessed and ranked, making sure that the value is sustained when requirements are further detailed.


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