A recent discussion on the SRE mailing list focussed on what RE is actually about, and whether the Engineering referred to has any meaning, or is simply a noise-word like 'handling' or 'management'. Practitioners and academics have been arguing to and fro on the question. In other words, we are not sure that we believe that RE is engineering.
To put the issue in context, let me tell a true story. A friend of mine has a houseboat on the Thames. A compartment is reached by a hatchway, protected by a heavy hatch - 15 kg of it, to be precise. From above, this is not too bad, but from below, the task of climbing out while carrying something like a tin of paint in one hand and a brush in the other was pretty difficult: my friend used to lift the hatch with his head and then wriggle out.
One day, he came across the solution - an advertisement for air-springs. The air-spring is an ingenious contraption of the sort used to make car boots open easily. He phoned the makers and they asked for exact measurements of his hatch. By return of post came a precise drawing - a computer print-out - showing where to fit the air-spring attachments, and which size of spring to use. He followed the totally counter-intuitive recipe exactly, and now lifts the hatch with one finger.
Well, that's engineering all right. An input specification ('A hatch of 15 kg, dimension x´y´z …') is transformed completely algorithmically to an output specification ('model AS-123, attached at x1,y1 and inserted at x2, y2'). The result is ingenious - engine-ous, to spell it out - in the best sense; the problem is totally and permanently solved by calculation of the behaviour of an 'engine' of a special kind.
Trouble is, our discipline doesn't have nice sharp input specifications. In fact, it often doesn't have any input specifications at all. Where classical will-the-bridge-fall-down engineering is all about transforming specinput into specoutput, RE is about transforming specfuzzy-or-absent into specinput. Our product is the very same input specification that your classical engineer would (we hope) recognise as the starting point for real engineering.
If that really is where engineering proper starts, then obviously whatever we do may well be useful and necessary but by definition isn't engineering. Why then do we claim the title of engineer? One answer is that it's just to acquire the gloss or sheen of reputability, a little of the reflected glory of Henry Rolls and Isambard Kingdom Brunel, while inwardly we feel we are little better than quack psychotherapists, taking our clients' money for some half-understood advice and doubtfully efficacious patent nostrums.
But we need not be quite so hard on ourselves. That input specification has to be a solid, reliable, accurate, objective analysis; in short, a well-engineered product. The process by which it is obtained and formalized cannot be like the calculation of a beam's thickness or an air-spring's insertion point, because it is a different kind of engineering. Ours is a discipline that efficiently and rigorously elicits, organizes, checks, measures, prioritizes and documents what a set of diverse stakeholders want - and helps them to agree on the specification of a solution. Or at least, that is certainly what we ought to be doing.
Sometimes, the specification may be quite formal; but I would argue that by the time the problem is well-enough understood and scoped to be formalized completely, the RE task is as good as over; the hard part is getting something solid from something nebulous. A thermal engineer might think of it as condensing a gas - the speeding random requirements all end up crystallized, lined up in neat rows. As for requirements management, that is the easy bit - putting the elicited items into a neat database to enable projects to keep track of them safely - but it is certainly part of the overall RE process.
Consulting engineers have always helped their clients to state their needs accurately, as the basis for the calculations that followed. But perhaps they have not paid full attention to how this subtle, often informal human process was conducted. Highly expert engineers have probably always elicited requirements almost unconsciously. But that effortless-looking ease should not delude us into thinking that knowledge, practice, and experience were not needed to acquire the requisite skill. In fact, recognizing only the most obvious calculation-based skills as engineering is rather like searching for your car-keys under a lone streetlight because that is the only part of the street bright enough to search without effort.
© Ian Alexander 2001