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 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.
+
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. At least when the aim is a "cheap" lightweight aircraft.
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.
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.
+
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 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 and ranked.
-
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 answer the question why, not on how to provide a technical solution.
+
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 talk about tacit knowledge. Discussions on how to provide a technical solution should be avoided.
-
The meeting should be part of the release planning process, helping both the customer and producer to create a list of ranked capabilities to be provided by the solution. The process should be repeated when high level features are detailed into more specific requirements. Its probably more important here, to help sort the important stuff from the less important stuff.
+
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 us to maximize value for the customers as early as practical possible. It should also be part of the iteration planning, making sure that the value is sustained when requirements are further detailed.
-
The approach fits well into agile methods, as it should be an integral part of the iteration planning process. For those practicing water-fall this need to be part of their requirement elicitation practice. Walking through hundreds of requirements up-front and ask why is a daunting task.
 
By [[Einar Landre]]
By [[Einar Landre]]

Revision as of 07:10, 16 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 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.

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 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 and ranked.

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 talk about tacit knowledge. Discussions on how to provide a technical solution should be avoided.

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 us to maximize value for the customers as early as practical possible. It should also be part of the iteration planning, 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