veryard projects - innovation for demanding change

changing requirements

on this page

> scope
> realist account:
requirements reflect reality
> modified realist account:
requirements reflect reality plus intentions
> legalist account
requirements reflect contract
> non-realist account:
requirements reflect demand
> bureaucratic account:
procurement process stands for quality
> requirements cycle

on other pages

> change
> flexibility
> requirements
> scope creep

home page contact us

supply-side perspective

Changing Requirements is widely perceived by engineers of all kinds to be a problem.

	changing requirements	This is a problem particularly experienced by engineers on long design and development projects, who must rework designs to keep them in step with changes in the specification, or in the expectations of the clients and/or markets.
	flexible requirements	A similar problem is experienced with the design and operation of technical systems that are intended to be ‘flexible’, in other words they should satisfy not only the original requirements, but also some range of new or additional requirements.
	requirements engineering	There is also a perceived need for tools and methods for requirements engineering. Note that the specification of such tools and methods is itself an exercise in requirements engineering. We might call this requirements engineering engineering.

demand-side perspective

Changing Requirements is also perceived to be a problem from the users' perspective.

Scope

What is the range of situation where we might talk about requirements?

	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.

What is the nature of requirements?

Realist account of requirements

Many people suppose there to be a requirements engineering process that explores the reality of a situation, and comes up with the requirements that ‘reflect’ this reality.

requirements reflect reality

A requirements model is therefore a model of reality. We call this the naive realist account.

There are three main challenges to this account.

multiple
stakeholders
conflicting
requirements
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.

implied
requirements 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.

changes to
requirements
over time When the requirements change, the realist is forced to regard this as a change to some reality described by the requirement.
a change in requirements reflects a change in reality

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’.)

Modified realist account of requirements

The "problem" of multiple stakeholders and conflicting/changing requirements leads us to a modified realist account, where the requirements are derived from reality plus something else (such as the stakeholder’s value system).

requirements reflect reality plus values

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.

Legalist account of requirements

Instead of seeing requirements as referring to some reality, an alternative is to see requirements as referring to themselves. The key concept here is the specification, which is a documented statement of requirements, which can be stored in a computerized design repository, or embedded in a legally binding contract. Are all requirements of this form? Can this be used as a definition of what we mean by a requirement?

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).

Constructivist account of requirements

A requirement is a demand statement that can be expressed in the form ‘We Require This’, a statement that contains three components. However, requirements engineering usually focuses on only one or two of the three components.

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.

What is the nature of the requirements engineering process?

Bureaucratic account of requirements process

The realist account of requirements is often accompanied by a bureaucratic account of the requirements process.

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.

Procurement mediates between requirements and design

This structure is (probably) also implied by ISO 9000.

Developmental account of requirements process

The requirements engineering process can be regarded as a progression: starting with a sense of something lacking (e.g. from an organization or process or system), via a fantasy or vision of what might compensate for the lack, to an engineerable specification of an engineerable product or service.

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.

Evolution of stakeholder identity

Developing identity of requirements owner (or client)

During the requirements formulation process, the requirements owner is himself transformed: from a ’naive’ client who articulates an infinite (imaginary, fantasy) demand for a magic solution, into a ‘mature’ client who articulates a moderated (symbolic, formal) desire for a realistic solution.

References

R.A. Veryard & J.E. Dobson, 'Third Order Requirements Engineering: Vision and Identity', in Proceedings of REFSQ 95, Second International Workshop on Requirements Engineering, (Jyvaskyla, Finland:June 12-13, 1995)

top

home page