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.

A random blog: Seilevel Presentation

A random blog: Seilevel Presentation

I've made a few contributions to the Seilevel forum, though I'm not convinced we're on the same wavelength.

...about checking rates

...about Tom Gilb, Agile and INCOSE 2007

...about Maslow's Hierarchy of Needs, mobile phones, trading off performance

...about decision-making processes

Three Cheers for the Worry-Stack (prioritization)

Let the Market Decide (prioritization)

...how worse can be better

...the final word on Goals vs. Businesss Objectives

...to copy or link: maintainability vs. usability