Introduction

Put radically, software engineering is requirements engineering, and as a consequence, in the average project considerable effort is put in managing the documents that are delivered as milestones, documentation or reports, coming from analysts, system developers, steering committees, and what more.

Software Engineering is Requirements Engineering!

Toy example: examples/hush/coffee


slide: Software Engineering is Requirements Engineering!

Each of the phases in the software engineering life-cycle is characterized by its own collection of documents. For example for the analysis phase, the IEEE advocates the use of its ANSI/IEEE 830 standard to specify the requirements a system must meet. Such documents accumulate over the subsequent phases and during maintenance, in particular, retrieval becomes a problem, unless adequate document management support is offered. Another problem is that the original meaning of specifications may get lost or, worse, that specifications may become outdated, making (diagrammatic) reverse engineering support desirable.

As an experiment, we augmented the standard documentation format for our Software Engineering course with hypertextual support, that is (among others) links, allowing students to jump from documentation to code, and back. To be clear, students had to write the documentation and code themselves! In the following, I will discuss the issues that are involved in providing hypertextual support for requirements engineering and software documentation. But first of all let's look at the requirements such documentation must meet.