These lecture notes are primarily about domain modelling and only secondarily how to transform domain models into domain and interface requirements. The following facets of domain modelling will be covered: business processes, intrinsics, support technologies, management and organisation, rules and regulations, scripts, and human behaviour. The lectures will exemplify excerpts of models of container shipping, financial services, etcetera. We shall relate two (of three) parts of requirements models to domain models: the domain requirements- which are the requirements that can be expressed solely in terms of the terms of the domain models, and the interface requirements- which are those requirements that can only be expressed using terms both of the domain and the machine: the hardware and software being required. For domain requirements we briefly sketch the domain-to-requirements “algebra ” of projection, instantiation, determination, extension and fitting. For interface requirements we briefly sketch the domain & machine issues of shared entities (bulk data input and refreshments), shared functions, shared events, and shared behaviours. 1

Road systems, railway systems, air traffic systems, and, for example, container vessel shipping, all share underlying abstractions such as transportation nets with hubs (road intersections, train stations, airports and harbours) and links (road segments, train tracks, air and sea lanes) and their states of being open or closed for certain flows of traffic across hubs and along links, etc. In this paper we shall first hint at an abstract formal model for such transportation and then show how it can be refined into models for road traffic, train traffic and air traffic. Then we likewise hint at how such, so-called domain models — which reflect only what there is ”out there”, in reality, before computing and communication — can be rigorously transformed into requirements for respective traffic monitoring and control systems. The paper concludes with a discussion of issues of development of the right systems, that is, the systems that customers (that is, transportation and traffic authorities) expect to receive,

We shall touch upon four issues of software engineering (SE): domain engineering, formal techniques, SE sociology, and academic software architects. First, before software can be designed one must understand its requirements; but before requirements can be formulated one must understand the domain. So we assume that requirements development is based on first having established models of the (application) domain. I will illustrate facets of the railway domain. Second, we touch upon all of the three phases: domain engineering, requirements engineering and software design also being done formally, however ”lite”. Third, despite 35 years of formal methods, the SE industry, maturity-wise still lags far behind that of other engineering disciplines. So we examine why. Finally, in several areas, in health care, in architecture, and others, we see that major undertakings are primarily spearheaded by senior academic staff. Professors of medicine daily perform specialised surgery and treatments at hospitals. Professors of architecture design new, daring buildings for industry, and professors of civil engineering head the engineering structural design of new, daring bridges. So we speculate what a similar approach would entail for SE. The paper is provocative, it postulates, but most claims are not (but can and will be [4]) substantiated. 1.

By ‘believable software management ’ we shall understand a “state of software development” (as an established practice) in which all developers, that is, programmers and managers at all levels, in their conscience, are confident that everybody is working according to state-of-the-art methods. In this Software Engineering Encyclopedia entry on ‘believable software management ’ we shall therefore survey what it means to be a programmer or a manager working according to state-of-the-art methods. To us, the concept of ‘software management’, covers both software development project management and software product management. We shall therefore have something to say about both. Much about the former and just a tiny bit about the latter. Many aspects of

Road systems 1, railway systems 2, air traffic systems 3, and, for example, container vessel shipping 4, all share underlying abstractions such as transportation nets with hubs (road intersections, train stations, airports and harbours) and links (road segments, train tracks, air and sea lanes) and their states of being open or closed for certain flows of traffic across hubs and along links, etc. In this paper we shall first hint at an abstract formal model for such transportation and then show how it can be refined into models for road traffic, train traffic and air traffic. Then we likewise hint at how such, so-called domain models — which reflect only what there is ”out there”, in reality, before computing and communication — can be rigorously transformed into requirements for respective traffic monitoring and control systems. The paper concludes with a discussion of issues of development of the right systems, that is, the systems that customers (that is, transportation and traffic authorities) expect to receive,