veryard projects - innovation for demanding change

The Paradox of Demanding Solutions

veryard projects > requirements > demanding solutions

Richard Veryard, 1996

abstract contents more material ...
The purpose of requirements engineering is to determine exactly what the user wants or needs, so that a high-quality solution can be designed and implemented. The quality of the solution is defined as the totality of characteristics of the solution that bear on its ability to meet the user's stated or implied needs.

But requirements engineering is doomed to fail; the user's needs will never be met; the customer will never be satisfied; there is always more work to do.

This article was first published in the journal Requirements Engineering in 1996.

Axiom 1: The user demands the impossible
Axiom 2: Technology promises gratification of all desires
Corollary 1: Technology always disappoints
Corollary 2: The solution generates further demands
Axiom 3: Everything changes
Corollary 3: The userís requirement changes
Corollary 4: The user changes
Axiom 4: The user never learns
Theorem: Quality is impossible
Technology and Magic

Axiom 1: The user demands the impossible.

Put on one side for a moment the fact that, in any interesting project, there are many stakeholders with conflicting perceptions, agendas and even value systems, and it is impossible to satisfy them all simultaneously. Let's pretend that there is only one stakeholder: the User.

The User's problem is the real world. The real world is troublesome. Competitors steal customers, politicians change the rules, staff make mistakes. The future is unpredictable and chaotic.

The goal of the User is to make the world less troublesome. If only we could insulate ourselves against the perverse demands of customers and politicians, if only our competitors could be tamed, if only our staff were perfect. To the extent that the User is successful today, he wants this success to be perpetuated; to the extent that the User is unsuccessful today, he wants this lack of success to be permanently reversed.

And it is technology that is supposed to achieve this miracle. Ultimately, at the bottom of every requirements engineering project, this kind of fantasy can be detected. This is not a complaint but an observation. We humans are irrational creatures, and we need these kinds of drives to spur us into action. Any technological project requires human energy and vision, as well as an element of play, and these qualities are inextricably linked to irrational fantasies.

Axiom 2: Technology promises gratification of all desires.

Put on one side also the widespread cynicism about technology hype, the common dismissal of 'silver bullets'. The fervent denial of silver bullets on the surface reveals how desperately we really want to believe in silver bullets.

Why do we expect so much from technology? Because it often delivers.

We believe in magic because magic sometimes works. Primitive man believed that if you want something to fly, you attach a symbol of flight. So they tied feathers to their arrows. As luck would have it, this improved the aerodynamic qualities of the arrows, thus confirming their superstitions. But primitive man's superstitions are as nothing compared to the superstitions of the modern technology user. (Think of the 'magical' powers attributed to Bill Gates.)

> technology and magic
Technological progress offers an apparently unlimited trend of improvements in productivity, efficiency, quality, user-friendliness, safety, accessibility, eco-friendliness and, above all, speed. These improvements are visible and genuine - to some extent. This encourages us to believe that they will continue - and that the improvements themselves will become faster and more reliable.

Corollary 1: Technology always disappoints

The engineer promises satisfaction. Something is designed (probably), constructed (perhaps), used (if you're lucky). Is the User satisfied? Not at all.

In an environment where technology is expected to succeed magically in resolving all the world's troubles, it is of course bound to fall short of these expectations. Mary Catherine Bateson calls this the Revenge of the Good Fairy - technology is like the three wishes in the fairy stories that have unforeseen and unwanted effects.

In the long run, technology also disappoints the supplier. It loses its ability to excite, it becomes taken for granted, the intellectual property gets eroded, competitors learn how to produce similar (or better) devices, a once-unique technology becomes a standard commodity - taken for granted unless it fails.

A prime example of this is the motor car and its associated production technologies. Produced in enormous quantities, the car has made most of us dependent upon it. We take for granted a level of comfort, convenience and safety that was unheard-of a few decades ago. The technological differences between one model and another are actually quite small, but they are made to seem highly significant by desperate suppliers and compliant motor-journalists.

Instead of feeling grateful to the motoring technologists, the driver fumes against the pollution and congestion caused by other drivers, and envies the features and styling of more expensive models.

And think of the inventions that seemed such good ideas at the time: DDT, leaded petrol, various pharmaceutical drugs whose side-effects only became known later. The people who developed these products were no different from us - they meant well, but they were just horribly unlucky.

Corollary 2: The solution generates further demands

Requirements engineering is recursive. Once we have motor cars, we also want catalytic converters, smog detectors, radar speed traps, radar speed trap detectors, traffic simulations, real-time traffic controls, seat belts, airbags, ambulance helicopters and organ transplant databases.

Neither the engineer nor the user can fully anticipate these demands. How many readers, however technically sophisticated, can honestly claim to have completely configured a new personal computer in one go? Many of us have to go back to the shop (or the purchasing department) to get this extra piece of software, that connector or network card, before we can even get onto the Internet - and then the further demands really start.

Axiom 3: Everything changes

Whatever world the User occupies - Business, Government, Military - is changing.

A solution is an application of technology to a problem in the User's world. Not only is the user's world changing, but also the available technological opportunities are changing.

For the engineer, it's like trying to build a bridge between two banks of a river, but both banks of the river are moving.

Sometimes it is possible to find a spot where the two banks of the river are at least moving in the same direction, albeit at different speeds. That's the case with the technological trend towards open distributed computing technology, which happens to coincide with a business trend towards federated organization structures. Does that make it easier to build bridges?

Corollary 3: The user's requirement changes

Every engineer knows the gap between what the User said he wanted before you started work, and how he rephrases this requirement when he sees what you have delivered. "What I really wanted was ..."

What can the engineer do about such posthoc reinterpretations of the user's requirements? He cannot ignore them, since they affect the user's judgement (which is, after all, the only one that counts) of quality. Quality means satisfying the user's needs, which means today's needs. It's just no good matching yesterday's needs - you may be able to force the user to pay for something he no longer wants, on the grounds of a written contractual specification, but that's not quality.

Hence the standard advice to the engineer to manage the user's expectations. But although it's an arrogant conceit, it is also insufficient. What the engineer needs to do is manage the whole user. Both the user's interpretation of the stated needs, and the user's implied needs, shift as the user's worldview shifts.

Corollary 4: The user changes

The expression 'You are what you consume' applies to far more than food. A man with a car is not the same as a man without a car. A secretary with a word processor is not the same as a secretary with a typewriter. When an organization implements distributed workflow technology it becomes a different organization.

These technologies change users' perception of the world, and their place in it. It changes users' behaviour. Thus it changes their identity - the psychological identity of an individual, the cultural identity of an organization. Such changes affect the priorities and needs, which lead back again into new requirements for new technologies.

Each of us, as simultaneous users and engineers of technology, have multiple conflicting perceptions, perverse agendas and even inconsistent value systems. These shift over time, so that we are never the same again. No wonder our requirements change.

Meanwhile the engineer is also changing, in ways that resemble how the user is changing.

Axiom 4: The user never learns

As intelligent mammals, we pride ourselves on our ability to learn from our mistakes. But because we are changing, and the world about us is changing, we usually merely learn the surface pattern and fail to learn the deep pattern. An organization has a bad experience with a given product, attributes this experience to a particular feature of the product, and subsequently avoids all products with this feature. This can be labelled as superstition or bounded rationality, depending upon your perspective.

The same patterns recur, over and over again. While pooh-poohing silver bullets, we fall for the next silver bullet; while preaching caution, we take preposterous risks.

How can we learn, if we have even forgotten who we are? How can we learn, if we cannot even maintain continuity of perception? How can we build on our experience, if our experience must be constantly and radically reinterpreted?

Theorem: Quality is impossible

It is left as an exercise for the reader to prove that requirements engineering is doomed to fail, that the user's needs will never be met, that the customer will never be satisfied, that there is always more work to do.

veryard projects - innovation for demanding change veryard projects > requirements
Technical update July 22nd, 2003
Copyright © 1996 Veryard Projects Ltd