Speaker: Steve Easterbrook,
Associate Professor, University of Toronto

As technical communicators, we are greatly affected by the problems addressed by Requirements Engineering (RE). Our work goes better or worse depending on whether developers have a clear and consistent view of their goal. We are in a position to promote good requirements.

Requirements engineering (RE) was developed to discuss software engineering, because software is both complex and invisible. However, other disciplines have, and need, requirements engineering too.

When Steve Easterbook was teaching at the School of Cognitive and Computing Sciences at the University of Sussex, UK, the school launched a survey to discover why local companies were not hiring their graduates. The answer was that computer science grads were hopeless as communicators – it was easier for companies to hire writers and teach them to program than to teach computer scientists to write. This was an early clue that software development is about people – and communicating, and needs to be studied in a multidisciplinary way. Steve’s frst example showed how requirements is about more than just modelling a system.

Important things get lost if the people specifying the software don't know what the system requirements are for and why they're important. Steve’s first example was a little misunderstanding about what the requirements what the Mars Polar Lander were supposed to accomplish, which resulted in the complete and mysterious failure of the mission at a cost of $165 million U.S. dollars.

For example, in 1999, the Mars Polar Lander started its descent from Mars and was never heard from again. Because it was expensive to transmit while descending, the mission failed without leaving a clue why—so that other missions could not be made more reliable without guesswork about the probabilities. The researchers then realized that the requirement to do a single mission cheaply could conflict with the requirement to have a successful space programme.

Analysis: The most likely cause of the failure was premature engine failure during the descent. Sensors in the legs could be tricked by vibration into thinking that the lander was on the ground. Therefore, signals from the sensors were supposed to be ignored unless they were repeated or the lander was within 12 metres of the ground. When the lander was tested, the signals were properly ignored. Later, the testers discovered that the sensors were wrongly wired and no signals were getting through. They corrected the wiring, but did not rerun the end-to-end tests that would have found a failure in the interaction of the systems’ parts. The second requirement, that the lander be almost down before signals from the landing legs were attended to, never got into the software requirements because the people writing them didn’t realize that it was important. This illustrates how important it is to have people who understand the system collaborate in writing requirements. It is also important that the requirements be traceable: we should be able to demonstrate how system requirments translate into software requirements. They should also have a rationale explaining why they’re important and be attached to a name so that someone can go and ask about them.

Extensive analysis revealed that one system requirement was not transcribed into the software because designers didn’t realize it was vital. A related test was not repeated after the fault that made it invalid was corrected.
We need to be identify the purpose and context of a system’s use. This can be a bridge between real-world needs, and the abilities of a system.

Modelling in the RE tradition includes structural analysis, behavioural analysis, object modelling, and the use of UML or Universal Modelling Language (where everything that does something is an “agent’ but not necessarily a person). Modelling is not enough because RE is a communications problem: you need to find out what people really want and communicate those requirements to the people building the system.
Software modelling is a technical activity. It should be precise, complete, and consistent. The real world is not precise and can not be completely modelled. All models are approximations because there are properties of the world that are not modelled and properties of the model that the world does not have. This leads to false assumptions about how a system will act in the real world.

So, how can we use the princples of Requirements Enginering in technical communication?

1. First, elicit requirements. Gather information about what problem the system will solve. This is a place for goals and sub-goals.

2. Analyze the problem and what will solve it. Here is the place for modelling.

3. Get agreement about requirements and their importance, e.g. cheap vs. reliable. Describe the situation as it is, e.g. what sensors perceive and what we’d like to be true (the improved situation).

4. Communicate the requirements to system designers.

5. Keep the requirements up to date. They will evolve during and after the project.

Each of these has steps has its challenges.

1. Understanding of or documentation about the problem can be difuse. It can be hard to describe some problems in words, especially physical actions. The people who could describe it might be too busy using the old system. The presence of an observer can affect an interview or situation. People might not be free to tell you what they know. This leads to an ethnographic, almost anthropological approach, where researchers act as passive observers and discover more properties of a work setting.

2. Choose everything that’s relevant and nothing that’s irrelevant.

3. System requirements are traditionally written in one big software requirements document that tries to be both a contractual agreement and a means of communication that is used both as a system description and a change control document. These purposes can interfere with each other as the legal document contains standard text that has little meaning for the system, and the language is left deliberately vague or too inclusive.

4. Thus the SRS does not communicate well. The SRS might omit features entirely or be ambiguous. It is generally impossible to trace who understands which requirement, why it is which important, and how important it is. It is almost impossible to keep an SRS up to date. Making it into a Web document with many hypertext links leads to a huge maintenance problem.

5. In addition, the SRS is a record of what the clients and designers used to want. There is always a time lag in supplying what has been requested and a feature lag between what is in the spec and what people want now.

If you missed this excellent meeting, check out Steve Easterbrook's Web site or click here for a PDF version of his slides for this presentation. This is a large file, 1.5 megabytes.

You can check the NASA official site for reports about the Mars orbiter: http://mars.jpl.nasa.gov/msp98/orbiter/.

The previous mission, the Mars Climate Orbiter, was lost because two teams didn’t take into account that one was using metric and the other Imperial units.