|classic engineering||A designer or engineer is called upon to design or engineer a solution to a client or market demand. For example, the design of a hospital for a given team of medical staff by an architect, or the design of a new technical product or service to fill a perceived market niche|
|planning||A planning framework (often labelled ‘strategic’) is required for an administrative unit, such as a town or region or corporation.|
|executive or policy||An administrative or legislative solution is required to a social or political demand. For example, the drafting of tax legislation to raise a given amount of tax from a given range of tax-payers according to a given set of socio-economic principles.|
A requirements model is therefore a model of reality. We call this the naive realist account.
There are three main challenges to this account.
|One of the practicalities of requirements engineering is the fact that
stakeholders rarely agree.
If two or more stakeholders have difficulty in agreeing what ‘the’ requirements are, to what extent can this be regarded as a clash of ‘realities’?
A naive realist could hardly explain this by postulating multiple realities, and would perhaps have to argue that some of the stakeholders were mistaken.
|What about implied requirements? Quality management insists that it
is not good enough merely to satisfy the stated needs, you also have to
satisfy the implied needs [ISO 8402]. This is an excellent principle, because
it places some responsibility on the supplier for the adequacy of the statement
of requirements. This prevents the supplier falling back on the lame bureaucratic
excuse that "It wasn’t in the contract, so we didn’t do it.".
On the traditional account, this would have to mean that the implied needs are located in some hidden (unconscious or preconscious) space, awaiting discovery.
|When the requirements change, the realist is forced to regard this
as a change to some reality described by the requirement.
When a new requirement emerges, is it always due to a change in reality? Alternatively, was it there hidden all along, similar to the implied requirements? Or was it merely due to a shift in the value system of one or more stakeholders? One frequent (and important) cause of requirements change is shifts in the balance of power between stakeholders. Do such shifts change reality? (That of course depends what counts as ‘reality’.)
The realist can then try to explain differences in requirements from the fact that different stakeholders have different value systems (or shifting values over time); there is only one reality. (Stakeholders may of course perceive this reality differently; but the realist blames cognitive error or self-deception for such differences.)
However, this explanation does not appear to cover all the modes of conflict between different requirements viewpoints, and fails to address the question of implied requirements.
Before answering this question, let us consider some alternative definitions of the word ‘requirement’.
As we saw above, ISO 8402 defines quality in terms of the satisfaction of stated and implied needs. Perhaps ‘requirement’ is synonymous with ‘need’. In practice, of course, there is pressure to convert implied needs into stated needs.
Vitruvius defines quality as commodity, firmness and delight. Typically, commodity refers to what the customer asks for (stated need), firmness refers to what the customer takes for granted (implied need), and delight refers to what the customer does not expect. Thus, in parallel with the stated needs, we have implied needs (also derived from the vision or fantasy) and something else (which perhaps goes back to the original lack).
|i||First-order requirements engineering concentrates on the ‘This’. In other words, attention on the (evolving) solution, rather than on the process or the client.|
|ii||Second-order requirements engineering concentrates on the ‘Require This’. In other words, attention on the solution and on the (evolving) procurement process/contract, but still not on the identity of the client.|
|iii||Third-order requirements engineering concentrates on the whole ‘We Require This’. Only now is attention explicitly directed at the (evolving) identity of the client.|
We therefore need to explore the evolution of the process and the evolution of the client, if we expect to have an adequate account of changing requirements.
The traditional account of requirements engineering then supposes a distinction between requirements analysis and solution design. An engineer (or engineering team) come up with a set of requirements, which is then input to a design and construction process, through the mediation of a procurement process.
This structure is (probably) also implied by ISO 9000.
But although this may be the starting point for requirements engineering, much of the time is often spent working out what is lacking in the solution. The specification is itself always incomplete or incoherent or inadequate. This may be discovered when the product or service is being designed, or when it is delivered. This leads to the following iterative process.
Copyright © 1999 Veryard Projects Ltd