Viewpoints Article submitted to Requirements Engineering

Fashion serves many useful purposes. It provides people with a way to show off themselves and their lifestyles. It offers fun, glamour, a sense of pace and change, an opportunity to clear out old stuffy wardrobes, a reason for buying new furnishings and goods of all kinds, from frocks to laptops. In short, fashion is an essential lubricant to the wheels of commerce in a consumerist society.

But fashion has a shadow side too: of waste, conspicuous consumption, built-in obsolescence, snobbish divisiveness, the scorning of those who do not play along. It can encourage cliquish thinking and a feeling of being the people who matter, who are better or smarter or more up-to-date than everyone else. And in the name of being different, it adds to the pressure to conform.

Are there fashions in engineering? And, if so, do they matter?

Think back to the rise and fall of Artificial Intelligence. Don't the very words sound rusty and antiquated now? A little old, a little stiff, rather H.G.Wells' creaking Martians than Arundhati Roy's oiled bodies? Now consider why we feel like that about it.

Let us look at the flowering of Artificial Intelligence in the '70s and early '80s a little more closely. It began in a small way with careful scholarly work in that quietist and driest of disciplines, formal logic. Then the papers started to flow, at first with cautious titles like 'A step toward automatic program writing', 'mechanical theorem proving'.

But very soon, the titles became bolder: 'Reasoning from Incomplete Knowledge'; 'Understanding Spoken Language'; 'Machine Learning'; 'Machines Who Think'; 'The Cognitive Computer'; 'Artificial Intelligence'.

The publishers and conference organisers, who know a main chance when they see one, gleefully leapt on to the bandwagon. The marketing men devised ever glossier fold-outs in cunningly shaped cardboard, the human heads overprinted with spooky green computer text, or unpeeled like oranges after M.C.Escher's engraving, to reveal the Knowledge within. In short, it was the height of engineering fashion.

How did one actually get the requirements for an Expert System, a Knowledge Base, an Intelligent Knowledge-Based System? Well, one just stepped right up to the Domain Experts and Elicited the Rules (without wondering too much whether Experts ever thought in Rules). The Expert mumbled something about the price of coffee and the Knowledge Engineer - yes, that's what a Requirements Engineer used to be called: embarrassing, isn't it? - skilfully wrote down

and eagerly awaited the next pearl of wisdom from the Expert. The Expert muttered a cautious disclaimer - Of course, it's very hard to be sure, but when I travel around the coffee estates before the harvest, I sometimes get a feeling - and the eager Knowledge Engineer pressed the Expert's wisdom, squealing, into another iron-hard rule

In response to a lot of failures, the rule was modified to

creating a proliferation of 'fuzzy' and often unfounded ways of reasoning, and a tangle of unverifiable Bayesian inferences, which did not exactly help matters.

The errors of a decade ago are easy to forget, like old clothes in the back of a wardrobe. In fact, we want to forget them. But they are important, as they tell us what goes wrong when fashion takes over in our corner of systems engineering.

The warning signs are simple and, if we dare to look, obvious:

• a torrent of books, papers, conferences and journals on a new topic;
• a batch of new buzzwords purveyed by the marketing machine;
• excited claims, quasi-religious fervour, large predictions for the future well-being of mankind;
• rather limited experimental evidence of performance or advantage from the technology;
• a theory being talked about as if it were inevitable, the only possible way to view reality.

The Artificial Intelligence craze diverted millions of dollars of research funds away from other areas. It attracted thousands of researchers and industrialists to spend time and money on projects which never quite yielded what was promised. It prompted Japan's MITI to launch a nationwide initiative to create an intelligent machine within 5 years, and the western world to launch counter-initiatives such as Alvey in anxious response. Well, the deadlines came and went, the ambitious goals were dropped rather more quietly than they were raised (the final sign), and the researchers hurried to rename their systems Enterprise Databases or anything else that didn't sound as though it was at all intelligent. (Several Artificially Intelligent Decision Support systems were also hastily renamed, for a variety of reasons.)

The robotics people, rather more grounded in reality than most - after all, if a robot falls over, or walks into things, everyone can see it ain't too smart - carefully carried on with discovering better and simpler ways of making things work, mainly by not trying to write rules for everything. They cheerfully admitted their best efforts were rather less intelligent than ants, but interesting nonetheless. Their work, which by now could seriously claim to be Artificial Intelligence, is starting to be useful in industrial, medical, and military applications, ironically the same areas where the AI craze failed.

In contrast, the AI miniskirt has faded away, along with the crinoline of flowcharting and the flared trousers of structured analysis, leaving behind a few much-hyped systems which work well enough, as long as some skilled programmers are constantly on hand to maintain their Automatic rules.

Fashion in engineering, then, can cause a colossal waste of resources, at least when it hits the big time.

So, is there a craze on today? In a small way, the name 'requirements engineering' is perhaps a fashionable title, replacing outworn models such as 'systems analysis', 'specification writing', or for that matter 'knowledge engineering'.

But the big craze, the Hula-Hoop Barbie Doll Rubik Cube granddaddy of all engineering fads, is the current fashion for Object-Oriented everything. Even requirements engineering is succumbing to the glitzy message.

All the signs are there: books, conferences, toolkits, marketing hype, research initiatives; the future of programming will be transformed, programs will be written by computers, or at least by idiots who will just click on a couple of icons. Look back at the warning signs, and see for yourself whether they apply.

Now, Object-Orientation as a design principle has much going for it, but as a means of eliciting requirements it is at least a doubtful proposition. I am not going to make jokes about customers who send themselves messages to retrieve their telephone numbers, but it cannot be wise to try to identify objects in a system before the problem, which that system might someday address, has even been described. (A classical example identifies a traffic-light object, before we have any idea whether the junction should be bridged, or have a roundabout, or slip-roads, or whatever).

In any case, the burden of proof lies squarely on the shoulders of those who want us to believe that object-orientation might be useful for gathering requirements. That, like the belief that rules can capture all kinds of knowledge, or that the Internet will replace all forms of face-to-face contact, is certainly not a self-evident truth. If a coherent theory can be put together, and if evidence can be found that it works, and if it turns out to have advantages in practice, then we should be convinced.

The real task of finding out what people are having trouble with in their businesses, of describing it simply and clearly in terms both they and system developers can understand, and of helping them to see their projects through to successful completion, is rather less glamorous. It could do with some quiet and careful thought, serious debate, and measured experimentation. There will always be room for improvements.

But a reflex lunge for the latest jumble of ideas and tools, no matter how elegantly packaged, will not help either us or the clients we claim to be serving. Any tool, technique, or method that helps us to model a problem a little more easily, explain things a little more clearly, or complete a task a little more safely, represents progress. Any approach that claims to do everything in one leap is probably just an engineering fashion.