One other kind of surrogacy must be mentioned: we ourselves stand in for stakeholders of all kinds when we help to express their requirements for them. We naturally hope that we are amplifying rather than attenuating channels, but as Shannon so righly observed, there’s no such thing as a noise-free channel.

How can these obstacles to requirements engineering be overcome? Plainly the usual answer is to appoint surrogates: in which case the surrogate stakeholders (for we cannot in fairness now call most of them users) act both as our channel to the stakeholders they represent, and as a threat to our ability to find out what is actually required.

The unborn soldiers can be represented by some current soldiers, while the non-existent enemy and weapons can be modelled by domain specialists, simulation, and the creation of suitable scenarios.

The operators of the next, unbuilt, version of the system can often stand in for themselves: they can imagine what the extra functionality will be like, or can be helped to do so with prototypes, mockups, walkthroughs and so on. And I’ve given the game away by talking about versions: iteration in the form of evolutionary development, rapid prototyping, agile methods, what you will, enables people to glimpse future system behaviour in small imaginable steps, so present users insensibly grade into future ones.

The mass-market consumers (the role is a hybrid of purchaser, operator and functional beneficiary) can be represented by a statistical sample, i.e. a small group chosen to be typical in aggregate of the consumer population as a whole. A few tens or hundreds of randomly-selected people (possibly carefully matched for age, sex and purchasing habits with the intended population) speak not so much with their own voice but with the averaged voice of the market. They speak to people with other surrogate roles, marketing or product management (the two are different, but there are clear connections). Those people decide, on behalf both of the organization (itself a surrogate acting on behalf of financial beneficiaries such as shareholders and directors) and of the consumers what the sample of consumers indicate that the mass-market consumers will in future (there is present-for-future surrogacy in this too) choose to buy, and hence decide what products to develop. Did you follow all that at the back? Please pay more attention…. Surrogacy can get complicated.

The employees who can’t speak for themselves are most often represented by a purchasing or procurement department. The people in those roles again represent both the employees who need to be provided with new hardware or software, and the organization itself. Each buying decision is a trade-off between the needs of the workers and the cost and risk to the organization. One effect of surrogacy is thus to merge requirement conflicts within the minds of individual stakeholders, whereas classical requirements engineering would look for different viewpoints from different people.

The public who don’t know the details of the law or the doubtfully-pure insides of a business are represented by a salaried official such as a regulator or inspector, who is paid to speak up on or investigate matters financial, safety, environmental, or whatever. This role is special, as there are generally statutory or at least openly-agreed rules governing what regulators must do, and indeed empowering them explicitly to act as surrogates to protect the public. In this they are quite different from most other kinds of surrogate that requirements engineers might meet.

One such is the head of department who claims to speak for all departmental processes under his or her control. The problem with that – it’s fine in theory, perhaps – is that whatever may be supposed to happen on paper, what people in the department actually do is always, and I mean always, different in practice. Even in the most highly proceduralised domains like air traffic control, I am assured by people who know that rules may and must be broken when there is good cause: if not, the system just wouldn’t be able to handle the traffic.

This means that if the requirements engineer wants to find out what really happens, as opposed to getting the party line, there is no option but to speak to (or observe) the people ‘on the shop floor’. Perhaps there was a time when the boss knew everything, as in the rhyme about the famed Dr Jowett of Balliol College, Oxford:

I am the master of this college
And what I don’t know isn’t knowledge.

Lesser mortals, however, can rarely hope to know all the details of what everybody who works for them has to know, especially in rapidly-evolving fields like software and electronics. We are now familiar with the paradoxical situation that it is all too often the most junior people who have the practical operational skills; their managers have administrative and sales expertise, but little or even no knowledge of technical matters. This may be a sadness – how much better it was when an Isambard Kingdom Brunel could be at once entrepreneur, manager, and master engineer! – but it is everyday reality. It follows that if you want to find out the operational requirements of the people who will actually use whatever it is you are building, you must speak to them directly.

If, of course, you can get to speak to them – rather than a surrogate. Where you can’t, then the question becomes ‘how should I elicit requirements from these kinds of stakeholder, given what they represent and the authority, statutory position, and knowledge that they have?' There are plenty of claims for methods and tools, but few of them come with advice on who to use them on. Perhaps it’s about time they did. At least it’s fairly plain that the requirements of, say, parliament, a safety regulator, marketing, and procurement are going to have to be approached differently.

This tangled tale reveals a surprising truth: surrogacy, far from being a rare or obscure phenomenon, is actually pervasive in society and business; and it is perhaps especially important in exactly the parts of a business that we ought to be most concerned about: development. The surprise is how little attention seems to have been paid to it: maybe its very pervasiveness has fooled us – the hardest things to see are often right under our noses.

Mother (in annoyance): Where’s my handbag?
Children (in chorus): In your hand, mummy!