Every project attempts to meet a need by delivering some engineered product. Very often that product arrives late, is incomplete, or is not accepted by the customer. A major survey in 1996 by the Standish Corporation showed that only 16% of projects actually succeeded fully by these measures. Since the only sensible measure of the success of a commercial project is whether it delivers what the customer wants, it follows that projects can only be guided by knowledge of what that is: the user requirements.
User requirements state in the customer's own language the nature of the problem or need. If this need is described in engineering terms or in the language of a system, the users may not understand it, or (very likely) may believe that only one specific solution is possible. What is more, they may miss important aspects of the problem if they are thinking in terms of solutions inappropriately early. There is a human tendency to jump for solutions, when it is more productive to reflect on the problem to be solved.
It is therefore essential that the user requirements are prepared in close consultation with the customer, so that the people who will use any resulting system feel that they own the requirements. Once they do, they will use their knowledge and influence within their organisation to ensure that THEIR requirements are implemented. Without this essential balance, each new project is invariably seen as something imposed from outside, and its requirements are seen as part of a burden of administration or quality control.
Once the user requirement is in place, the task of system engineering can begin. A system requirement, which describes the scope of any possible solution to the problem, is defined. The system requirements document is critical, as all subsequent engineering work is traced back to it, and verified against it. At the top level, the system tests aim to prove that the system does not meet its requirements. Only if all attempts to show that the system is unsatisfactory fail is the system accepted.
The bulk of the engineering takes place at lower levels, as the requirements are used in the design of the system. The architecture consists of a hierarchy of subsystems and components (down as many levels as necessary), with precisely identified interfaces between them. Each component and interface is verified against its own specification, so the system engineering approach is the same at every level (i.e. it is recursive).
Given this organisation, which is essential to control complexity, it can be seen that there is a constant structure and approach at each level:
It is worth observing that only at the lowest level (individual components) does design lead directly to implementation of hardware or software. At all levels, however, there are Requirements and Tests to be specified in detail. The more visible parts of the system, embodied in the Design, form the remainder of the work. Specification is therefore vital throughout the life of a system.
Every system is steered by its requirements, just as a supertanker is steered by its rudder: the rudder seems a small part of the ship, and so it is; but it sets the direction of the whole, and controls it throughout its journey.