Domain engineering

Abstract

Before software can be designed we must know its requirements. Before requirements can be expressed we must understand the domain. So it follows, from our dogma, that we must first establish precise descriptions of domains; then, from such descriptions, "derive" at least domain and interface requirements; and from those and machine requirements design the software, or, more generally, the computing systems. The preceding was an engineering dogma. Now follows a science dogma: Just as physicists have studied this universe for centuries (and more), and will continue to do so for centuries (or more), so it is about time that we also study such man-made universes as air traffic, the financial service industry, health care, manufacturing, "the market", railways, indeed transportation in general, and so forth. Just in-and-by-themselves. No need to excuse such a study by stating only engineering concerns. To understand is all. And helps engineering. In the main part of this chapter, Sect. 1.4, we shall outline what goes into a domain description.1 We shall not cover other domain stages, such as stakeholder identification (etc.), domain acquisition, analysis of domain acquisition units, domain verification and domain validation. That is, before we can acquire domain knowledge, we must know what are suitable structures of domain descriptions. Thus, we shall outline ideas of modelling: (1) the intrinsics (of a domain), (2) the support technologies (of..), (3) the management and organisation (of..), (4) the rules and regulations (including [licence or contract] scripts) (of..) and (5) the human behaviours (of a domain). Before delving into the main part we shall, however, first overview what we see as basic principles of describing phenomena and concepts of domains. At the basis of all modelling work is abstraction. Mathematics is a reliable carrier of abstraction. Hence, our domain modelling will be presented as informal, yet short and precise, that is, both concise narratives as well as formal specifications. © 2010 Springer-Verlag London.