Requirements Without Measurement Are Nothing More Than Utterances

Every system that you should ever build should at least begin with some requirements. In an ideal context a complete set of requirements would be used for the development of a system's functionality. Robert Filman in his paper “Achieving Ilities” created a list of the possible kinds of requirements. He classified requirements as Functional, Aesthetic, Systematic and Combinatorial.

Functional requirements are the requirements that we are usually most familiar with. It covers the capabilities of an system that's visible externally. So if you could treat a system as a black box, how we use a system without going in to its internal details is usually captured by functional requirements. Use cases for example tend to drive the development of these functional requirements.

Aesthetic requirements are more subjective and involve the look and feel of the system. The look and feel be perceived from different points of view. An end user would be concerned about the color scheme, marketing would be concerned with branding, coders would be concerned with code formating. Filman says that its requirements that “satisfies the eye of the beholder”. I would go much deeper than that and say that its requirements that satisfies the Usability consultant.

Systematic requirements are behavior that cuts across the entire system. For example, logging, memory management, auditing, security tend to be systemic requirements. It tends to be most effective if its applied consistently throughout the entire system. The difficulty with systemic requirements is that it sometimes difficult to enforce withing large development organizations.

Combinatoric requirements are requirements that have no absolute way of determining if its been satisfied. That is the system is complex enough that certain absolute statements cannot be proved with absolute certainty. Filman suggests the requirement that “all request respond within 5 seconds” as an example of a combinatoric requirement. Such a requirement isn't unusual in computing circles, however the only way it is met is through sampling. That is, if we've tested enough times with enough cases, then just maybe the requirement is satisfied. Of course we never know with absolute certainty. But that doesn't mean we shouldn't try.

The key idea here is that requirements are only as good as your ability to measure them. If I have no mechanism for determining if a requirement is satisfied or not, then that requirement for all intents and purpose is completely useless. Requirements exist to be satisfied, in the absence of that it just an utterance and is devoid of any actionable consequences. We'll get into this later when we tackle Speech Acts.