|Ernesto Guisado's Website » Miscellanea » Gilb's Competitive Engineering||Articles | Miscellanea ||
In February I attended a short course on Design by Tom Gilb
In February I attended a short course on Design by Tom Gilb1. Most people (including me) expected him to tell us about some new UML notation or perhaps about some heuristics that could be used to come up with good designs. Nope. His main thrust was a method he has developed that helps you choose between competing designs based on quantitative criteria2.
One of his main ideas is that, after a while, competing products tend to have the same features and that the competitive edge comes from what he calls “performance attributes” of the system. To use his example, you wouldn’t buy a car just because it takes you from A to B. You choose a car based your requirements on the performance3 of the car: is it cheap? low maintenance? good looking? fast? comfortable? easy to drive?
His approach to requirements engineering can be sumarised as follows:
I haven’t used his method in anger, but I’ve found that attempting to quantify impact of designs on system qualities is a good way of exploring the limits of your knowledge and documenting your conclusions. A bit like Parnas’ with his insistence on “faking” a rational process.
1 Tom Gilb is quite influential because of his work on software inspections and is also a strong early advocate of incremental development models (what he calls evolutionary project planning).
2 Gilb gives the following disclaimer ”...I expect this information to only be used as a rough indicator to help designers spot potential problems or select design ideas. Any real estimation of the impact of many design ideas needs to be made by real tests; ideally, by measuring the results of early evolutionary steps in the field.”
3 Other authors tend to call them “non-functional requirements” instead. Gilb doesn’t like this negative formulation and refers to requirements affecting system qualities, resource constraints and costs by caling them “performance requirements”.
4 In my interpretation of Gilb’s work there are 2 reasons behind prefering scalar requirements: they are quantifiable and they lend themselves to incremental planning and delivery.