An Examination of Requirements Specification Languages

If the resulting model is still too complex, further abstractions may be necessary, until the problem is reduced to a manageable size. The model is then analysed and manipulated until a feasible solution is found. In engineering, diagrams and mathematics are often used because they have been found to be more suitable for manipulation than verbal descriptions. One representation may have to be transformed into another so that the most appropriate model for a given analysis can be used. Diagrams, for instance, may have to be converted into equations. Finally, if the abstract solution is accepted by the customer, a construction phase turns it into a real system.

In order for a requirements specification to be useful in systems development, seen as an engineering process, the specification language must exhibit various features, each being relevant to one of the stages. These features will be highlighted in this section. We recognise that there are authors who may object to having an engineer’s view of information systems development. Examples are Checkland, Land and Mumford [5, 18, 23], who regard systems
development as a human activity process. They propose that emphasis should be made on such issues as understanding the impacts of change, people-oriented design and user participation throughout the development process. It would be interesting to study how our proposal for the desirable features of a
specification language fits into this alternative framework. It is, however, beyond the scope of the present paper to do so.