Gilb's Competitive Engineering

Posted November 27, 2004 in misc

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.

Competitive engineering

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:

  1. Work out the requirements. Most requirements will be of the performance type (they can be described using a scale of measure), but some will be functions of the system and can be expressed as binary: either the system has
    the feature or it hasn’t4.
  2. Come up with a list of design ideas that fullfills each requirement and investigate how each impacts other system qualities.
  3. Use an impact estimation table to compare design ideas and chose which one to implement and in which order.

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.