Puta Number On It

[Note: we need to combine the concerns expressed here and on DontPutaNumberOnIt and ClearRequirements to get some community consensus on this stuff. Help, anybody?]

What, you want it to be fast? How fast? Give us a measurement.

What, you want it to be small? How small? Tell us the maximum size it can be, all dimensions.

What, you want it to be light? How light? Tell us the maximum weight.

What, you want it to be flexible? How flexible? Give us some reasonable approximate limits on the load variation and other demands we can expect.

If you want to write a specification on how a product is to perform you need to do so in terms of measurable quanta, not vague qualitative assertions.

[Copied from NonFunctionalRequirements]

It is true that all requirements can be specified in measurable terms. The rub lies in measuring. For instance, a client may ask for something that is "higher quality than the previous product" without really specifying how that quality is to be measured. We then ask leading questions about mean time between failures, rate of repair calls, hours of tech time to fix field failures, cost of maintenance, etc. Perhaps the client says he wants the new product to be "smarter" than the old one. We then ask about decisions the user had to make with the old product and compare that to inputs the new product has and the decision capability we can now put into the new product. The client will probably ask for it to be "easier to use" than the old one. A toughie, but how about setting up measurements with off-the-street testers to see if they can use the new box more easily or get work done in less time than the old product?

All requirements that seem to be qualitative instead of quantitative can still be expressed as hard numbers if the client and developers are willing to work together to establish measurements.

This is not quite true. You can provide measurements as surrogates for the quality you are trying to improve, but do not forget that the measurement is only a very small piece of the desired quality. It is too easy to destroy the system while improving the measure.

Then how about making sure that the client's requirements incorporate everything he thinks is a characteristic of value? In this way we avoid having measurement as "a very small piece of the desired quality." If the "desired quality" is stated as some objective characteristic that can be quantified then we can assign measurements to that quality. Otherwise, how are we ever going to know what we're talking about?

The most important number in commercial software development: How much do you want to spend? [Warning, Will Robinson! Satire! Caution! Approaching cynicism!]

QualityWithoutaName seems to defy objective measurement. Sometimes you must make do with measurements of things that seem causally related to the property you are really trying to achieve... but perhaps QualityWithoutaName is too fluffy to be a requirement. It may be true that anything that can be expressed as a requirement can be expressed concretely enough to be measured.

Precisely. The whole point of measurement is to determine a goal everyone can agree on and then know when that goal has been met. "Qualities" without names or measurements are an invitation to continuous argument and unattainable goals.

The problem with relying on numbers is that measurement is replacing understanding. A number forced upon people in order to have "agreement" does not ensure needs are met. Futhermore, unless the measurement process and system are fully defined, the agreed upon number is still subjective. It is no wonder that written specifications involving numbers have so many caveats and assumptions that no one understands what is being discussed.

Right. This is where you gotta establish the quantity being measured and how it is being measured. Once you've established the nature of the quanta and the reason for measuring it then you can detect changes and track causality. If you can't do this stuff then you are just floundering, with no hope of ever achieving anything.

You can do both, once you have numbers attached to everything then you can figure out their relative importance to the requirements, and record how important each requirement is relative to the others. This brings understanding back into the picture, because relative importance is a form of Information.

See: AsPossible, DontPutaNumberOnIt, ClearRequirements, GoodMetricsUseNumbers

CategoryRequirements CategoryInformation