Friday, June 29, 2007

Roger Cauvin's Requirement Definition

I have never subscribed to the IEEE "definition" of requirement, and I'm not convinced that Roger's adaptation makes it acceptable. It certainly makes it more acceptable, so "well done, Roger!"

Where do we go from here?

First, can we equate "least stringent condition" to Tom Gilb's "Fail" concept (*098), "the leading edge of a Failure Range"?

If so, what do we do with the other interesting points on Gilb's continuum, reproduced (slightly modified) below?


•• is a catastrophe range.
[ is a lower survival level.
!!!!! is a Failure Range.
==== is an acceptable range.
> is a Goal level.
_____ is a success range.

My view would be that the requirement, if not more fully characterized in some way similar to Gilb's, is for "success", as opposed to the avoidance of "failure" or "catastrophe". It is the latter that Roger's "least stringent condition" suggests (to me).

Of course, I find even Gilb's exposition simplistic, but we have to run before we can walk! For practical purposes, it is useful to reduce the requirement concept to "measurable, valued outcomes". Observing or hypothesizing how much, and how differently, changes to outcomes are valued by diverse stakeholders is a powerful technique for establishing what might constitute success, but it is still one-dimensional. Leaving the whole multi-dimensional trade-off between benefits (including but not limited to avoided costs) to one side, what emerges from such an exploration is (hopefully) agreement about the level of outcomes to pursue. I would call this an objective rather than a requirement but, to me, objectives are a type of requirement.

What, though, of "raw" function? Here it is crucial to be very precise about the context. It is, in practice, always possible to move backwards and forwards along a cause-and-effect chain, dragging the "system boundary" one way or another (hypothetically, at least). Determining the "border zone" is, in my view, a requirements activity. This is what constructing use-cases is all about. The problem, it seems to me, is that use-cases implicitly assume an immovable boundary. The reality is that some boundaries are clearer than others; some more the result of design, some more a matter of policy or practical constraints. Defining a range of required function is key.

In this view, we recognise a distinction between "core" function, the absence of which is unacceptable, and "contingent" function, which must be present in some form in the universe, but not necessarily in the system being specified. Performance characteristics are unavoidable for all function. The valued performance characteristics are what drive the distinction between "core" and "contingent", I think, and, more relevantly, inform the ultimate decision about what "contingent" function is a necessary, desirable, unnecessary or undesirable inclusion in the final system.


Roger L. Cauvin said...

I like your discussion of system boundaries. If we are really trying to solve (and avoid) problems, we have to view the product holistically. I have written about how documentation, training, and support are in a sense part of the product. Collectively, they solve stakeholder problems.

As for "least stringent condition", I certainly didn't intend for the phrase to imply mere "acceptability" or avoidance of catastrophe. The reason that requirements - expressed as conditions - should be the "least stringent" ones, is that specifying anything more stringent ventures into design.

For example, if the problem is that it takes too long for the user to achieve some functional task, then the requirement is

Usability: It shall take no more than x minutes for a user with profile y to achieve z.

Feel free to make x as low as needed for the product to have remarkable usability instead of mere acceptable usability.

But if we instead specify a particular user interface, we are specifying a much more stringent condition (or set of conditions), and thus venturing into design.

AlanAJ said...

I have responded to Holistic Requirements. on Roger's blog.

It's reassuring to see that we are more in agreement than I thought, even though I don't subscribe to the single dimensionality "least stringent condition" implies.

Here I need to pick up on the "Usability" requirement. Leaving aside that it is only one aspect of usability, I wonder when a simple maximum would ever really be the requirement. So don't we need to say, for example: "mean < x mins", "90% < w mins", "99.5% < v mins" etc? Basically, draw a graph!

Roger L. Cauvin said...

> So don't we need to say, for example:
> "mean < x mins", "90% < w mins", "99.5% < v mins" etc?


The conjunction of those three conditions is itself a condition. If the conjunctive condition represents the least stringent one that must hold for us to say the product is as usable as it needs to be, then it is a requirement.