The meaning of requirements

We use the term requirements to denote what are often called functional requirements. Requirements are located in the environment, which is distinguished from the machine to be built. A requirement is a condition over phenomena of the environment. A specification is a restricted form of requirement, providing enough information for the implementer to build the machine (by programming it) without further environment knowledge. To describe requirements appropriately we must fit our descriptions into an appropriate structure. This structure must respect the distinction between the machine and the environment, and the distinction between those environment properties that are given (indicative descriptions) and those that must be achieved by the machine (optative descriptions). Formalisation is a fundamental problem of requirements engineering. Since most environments are parts of the physical world, and therefore informal, the formalisation task is inescapable. Some techniques are discussed for tackling this task. In particular, the use of designations is explained, and the distinction between definition and assertion. By using the smallest possible set of designated terms, augmented by appropriate definitions, the developer can create a narrow bridge between the environment and its descriptions in the requirements. In this way a sufficiently faithful approximation to the informal reality can be obtained.

[1]  Jim Woodcock,et al.  Using Z - specification, refinement, and proof , 1996, Prentice Hall international series in computer science.

[2]  Pamela Zave,et al.  Deriving Specifications from Requirements: an Example , 1995, 1995 17th International Conference on Software Engineering.

[3]  John Wordsworth Software development with Z - a practical approach to formal methods in software engineering , 1992, International computer science series.

[4]  Michael Jackson,et al.  Domain descriptions , 1993, [1993] Proceedings of the IEEE International Symposium on Requirements Engineering.

[5]  Michael A. Jackson,et al.  Software requirements and specifications - a lexicon of practice, principles and prejudices , 1995 .

[6]  Peter G. Neumann,et al.  Computer-related risks , 1994 .

[7]  W. T. Farris,et al.  Software requirements specifications , 1993 .

[8]  Kjeld Schmidt,et al.  Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work ECSCW ’95 , 1995, Springer Netherlands.

[9]  Eugene S. Ferguson,et al.  Engineering and the Mind's Eye , 1994 .

[10]  Martin S. Feather,et al.  Language support for the specification and development of composite systems , 1987, TOPL.

[11]  Philippe Massonet,et al.  Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[12]  B. Molnar Software development with Z: a practical approach to formal methods in software engineering : J B Wordsworth Addison-Wesley (1992) 334 pp £21.95 softback ISBN 0 201 62757 4 , 1992, Inf. Softw. Technol..

[13]  Nancy G. Leveson,et al.  An investigation of the Therac-25 accidents , 1993, Computer.

[14]  Stephen Fickas,et al.  Goal-Directed Requirements Acquisition , 1993, Sci. Comput. Program..

[15]  Bashar Nuseibeh,et al.  Managing inconsistencies in an evolving specification , 1995, Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE'95).

[16]  Steve M. Easterbrook,et al.  Domain modelling with hierarchies of alternative viewpoints , 1993, [1993] Proceedings of the IEEE International Symposium on Requirements Engineering.

[17]  Liam J. Bannon,et al.  Questioning Representations , 1991, ECSCW.