Requirement Definition

A requirement is something the customer mandates. If you do not meet the requirements then there will be penalties. Penalties can be things like a cancellation of the contract, a large monetary transfer, pain of death, or nothing at all.

[Actually, this verges on a definition for "Constraint", rather than "Requirement". See below.]

This covers a lot of areas that can not be expressed in code. For example:

you must be ISO 9000 compliant.
your bug tracking system is accessible by us.
you shall use language X.
you shall use database X.
you shall have X people in field support.
the interface must look good.

Of course, that last "requirement" means nothing. PutaNumberOnIt.

Constraint (definition from PlanguageConceptGlossary by TomGilb)

: "A constraint is a requirement that explicitly and intentionally tries to directly restrict any system or process.
: "A key property of a constraint is that a penalty or loss of some kind applies if the constraint is not respected.
: "Constraints include limitations on the engineering process, a system’s operation, or its lifecycle."

I am currently debating with Tom his definition of "Requirement", but it seems clear enough to me that a requirement for a system is "something of value to some stakeholder" of that system. That is, it is some real or intended property of the system that matters to some extent to some stakeholder.

Any real system has

function properties, which are what the system does
performance properties, which are how well the system performs its functions
resource properties, which are what is consumed by the system

Any intended system (including an improvement to a real system) could likewise be characterized in terms of its future properties (or "Attributes", as Gilb terms them, "...an observable characteristic of a system..."). Specifying the intended future properties for a system is specifying the requirements for the system.

Note that, for Gilb, systems are supposed to evolve in response to the pressure exerted on them by their requirements [he says nothing so fatuous, but it's a fair indication of his view, I hope]. A single EvoStep? plans to make maximum progress towards meeting stakeholder requirements with the allotted resources (typically 2% of the total budgets, including elapsed time, man-hours and cash). Therefore, requirements are defined in terms of a range that would typically include "Survival", "Fail", and "Goal" levels, and may also include "Stretch" and "Wish" levels. (All of these can be qualified with, for example, Time, Place and Event conditions, so today's "Fail" level may be tomorrow's "Survival" level. The trick is to keep moving towards the "Goal" levels of all requirements while keeping ahead of the "Survival" and "Fail" levels!) With this view, RequirementDefinition is clearly a (strategic) business management activity, not a SoftwareEngineering task. The engineer's responsibility is to come up with good ideas for making the desired progress, make them happen at the appointed time and, where appropriate (which depends on the nature of the measure), demonstrate what progress has actually been made (as opposed to intended).

CategoryRequirements