A survey of domain engineering

Abstract

Summary form only given, as follows. The practice of domain engineering as a precursor to requirements engineering in software development is gaining acceptance. In this tutorial we shall argue that before software, S, can be designed, one must understand its requirements, R, and that before requirements, can be prescribed, one must understand the application domain, D. Therefore, to us, software engineering consists of three major phases: domain engineering in which a domain description is developed; requirements engineering in which a requirements prescription is developed and related to the domain description; and software design in which a software specification is related to the former: the Software is correct with respect to the Requirements in the context of the Domain. In this tutorial we shall focus on domain engineering. Domain engineering, to recall, aims at producing a description of the domain: of its endurant ("data") and perdurant ("action, event and behaviour") entities. So a main activity of domain engineering is the analysis of endurant and perdurant entities. As for endurant entities we shall outline principles and techniques for describing how a domain is composed from parts, their values and types and how they relate to one another. We refer to this aspects of domain analysis as mereology. We shall, however briefly, also outline principles and techniques for describing perdurant entities: (actions, events and behaviours). The tutorial will start with the presentation of a non-trivial example: the domain description of a class of transport systems (road nets, rail nets, airline nets, shipping nets). And the tutorial will end with a discussion of how one can develop requirements from domain descriptions; how domain descriptions relate to ontology; issues of domain science: laws of domain descriptions; possible calculi of domain discoverers; who should be researching and developing domain descriptions; etcetera.