Introduction

Team-Fly

---

  

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

---

A few years back your author attended a dress rehearsal of the Houston Grand Opera's production of Richard Wagner's Lohengrin . I was part of an audience of maybe five people in Houston's great opera theater, the Wortham, and it was as though the entire production were being put on for me personally . It was wonderfully impressive.

During one of the more spectacular scene changes, where it takes about thirty minutes for our hero to arrive on stage in a boat pulled by swans (figuratively speaking, at leastthe swans weren't real), I started thinking about what I was seeing. In addition to the dozen or so leads, there were seventy-five choristers. The orchestra in the pit had over one hundred players. There had to be close to fifty technicians aboutstage crew, lighting engineers , the guy who ran the sur-title machine, etc.not counting the set designers and builders, the makeup people, the costumers, and so forth. And then there was the Houston Grand Opera administration. Altogether, nearly three hundred people were working together to produce one of the most spectacular pieces of stage work I had ever seen.

In our industry, we're lucky if we can get three people to cooperate. Why is that?

The secret to Lohengrin is, of course, Richard Wagner. Some 150 years ago he conceived this opera and documented it to a high degree of detail. Most significantly, he produced the score and the libretto. Every actor, every chorister, and every musician has a script to follow. The set designer, to be sure, has some latitude. In this case Adrianne Lobel based the sets on the surrealist works of Ren Magritte. This certainly gave the stage a distinctive appearance. But even the stage crew, who have less direct guidance from Wagner, have tasks that follow both from the set designs and the actions on stage.

What we so often are missing in our business is the score.

Requirements analysis is the process of creating a score for a systems effort. What is the objective of the effort? What are its components ? Who should do what? Absent the score, each person does what seems appropriate, given a particular view of things. The result is neither coordinated nor integrated and often simply does not work. It certainly does not last 150 years.

Back in the old days, programmers simply wrote programs to perform specific tasks. If you knew what the task was, you could write the program. Improvisation was fine back then. Programming was more like a jazz concert than an opera. Now, however, we are building systems to become part of the infrastructure of an organization. We cannot build them without understanding the nature of that infrastructure and what role the systems will play in it. You cannot construct an opera without a score.

There is an unfortunate tendency in our industry to respond to the various pressures of system development by short-circuiting the analysis process. We don't sit down before creating a system to decide what it will look like and, by implication , how we will get there. It's not that we don't know how. It's just that multiple, conflicting demands often force us to take shortcuts and skip the specification step.

This invariably costs us more later. We clearly do not produce the systems equivalent of great opera.

One main problem with short-circuiting the analysis process is that it leads to unnecessarily complex systems. It is important to understand that, while simple systems are much easier to build than complex ones, simple systems are much harder to design .

You have to be able to see the underlying simplicity of the problem. This is not easy.

Analysis of requirements should be done by people who are able to focus on the nature of a business and what the business needs by way of information. It should not be done by people immersed in the technology they assume will be used for solving whatever problems are discovered .

Consider, for example, the following poem:

Un petit d'un petit
S'etonne aux Halles
Un petit d'un petit
Ah! desgrs te fallent
Indolent qui ne  sort  cesse
Indolent qui ne se mne
Qu'importe un petit d'un petit
Tout Gai de Reguennes.

Luis d'Antin van Rooten
Mots d'Heures: Gousse, Rames [Beer, 1979, p. 301]

If you know French, you will find this impossible to read. It looks like French. It has all the structures of French. But it is completely wrong! It makes no sense. ("A little of a little astonishes itself at Halles"?) On the other hand, if you don't know French but have a friend who does, ask that person to read it aloud . If you listen very carefully with a non-French ear, you will figure out what it really is. ^[1]

^[1] . . . and if you can't, there's a hint at the end of this Introduction.

The point is, your ability to see the problem depends entirely on your perspective. No matter how hard you study it, if you come at it from the wrong direction, you simply will not see what is in front of you.

The techniques described in this book will show you how to look at problems from a different direction in order to see the true nature of an enterprise and, with that, its requirements for new systems. Then you can design systems that, as part of the infrastructure of that enterprise, truly support it rather than adding yet another burden to its operation.

---

Team-Fly

Top