On “The Right” Software

On “The Right” Software 

Dines Bjørner 

Denmark 

Beijing 26–27 April 2011 

April 1, 2011, 12:27 On “The Right” Software c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark 

1

2 

Summary 

• Boehm [Boehm81] is credited to have formulated the “Two Rights” of software: 

– the problem of getting the right software 

– and 

– the problem of getting the software right. 

• The development processes needed 

– to achieve software that is right, to us, 

∗ requires that a proper study of the application domain 

∗ be done before a serious requirements study is attempted; and 

– to achieve the right software, 

∗ that is, software that is correct, to us, 

∗ requires that a proper engineering degree of formalism 

∗ be applied to the entire development process; 

– that is, that we re-interpret classical development processes 

[Spiral-Model-Boehm-1988]. 

c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark On “The Right” Software April 1, 2011, 12:27

• We shall in this paper focus only on the issue of obtaining the right 

software. 

• In this talk we shall outline 

– what we mean by a proper study of the application domain 

– and how it influences the requirements development. 


3

4 

1. 

1. Introduction 

1.1. The Triptych Phases of Software Development 

• Before we can design software we must understand its requirements. 

• Before we can prescribe the requirements we must understand the 

domain, 

– that is, the application area for the contemplated software. 

• Thus we argue that software development consists of three major 

phases: 

– Domain engineering — which results in a carefully analysed (verified, 

checked, tested and validated) domain description; 

– Requirements engineering, based on the domain description — which results 

in a carefully analysed (verified, checked, tested and validated) requirements 

prescription; and 

– Software design, based on the requirements prescription — which results in 

carefully analysed (verified, checked, tested and validated) software code. 


1. Introduction 1.2. What Is Different ? 

1.2. What Is Different ? 

• Among several differences comparing the Triptych approach to conventional 

software engineering, we consider, in this talk, four differences. 

1.2.1. Domain Engineering 

• Classical software engineering focus on Requirements and Software design. 

• Although Requirements engineering do entail considerations of the Domain 

– there is no real attempt to establish 

– a comprehensive description and analysis of the domain 

– free from any considerations of requirements — let alone software. 

• The Triptych approach calls for such a free-standing description and analysis. 

– Yes, it is true that one understands far more of the domain after software 

design, 

– but it is sort of groping in the dark prescribing requirements without really 

having made an honest attempt at understanding the domain. 

• Including domain engineering into software development helps avoiding risks. 


5

6 1. Introduction 1.2. What Is Different ? 1.2.2. Derivation of Requirements From Domain Descriptions 

1.2.2. Derivation of Requirements From Domain Descriptions 

• We show a new approach to requirements engineering. 

– Whereas requirements conventionally are acquired, 

laboriously, from stake-holders, 

– major parts of requirements are now systematically “derived” from domain 

descriptions. 

– Of course, the burden has shifted, 

∗ facts about the domain is now acquired, laboriously, from stake-holders, 

∗ but the classical problem of “always changing requirements” 

has been partly alleviated: 

· domains are more stable than requirements 

· and arriving at “less fluctuating” requirements is made more 

deterministic in being based, to a large degree, on a more stable domain 

understanding. 

• Deriving requirements helps avoiding risks. 


1. Introduction 1.2. What Is Different ? 1.2.3. Duality of Narratives & Formalisation 

1.2.3. Duality of Narratives & Formalisation 

• For all specifications of 

– domain facts, 

– requirements and 

– software design 

• we mandate the use of informal narratives and formal specifications. 

– The formalisms serve the developers. 

– The narratives serve the stake-holders. 

– And narratives and formalism fit one-another: “hand in glove”. 

• Stating all domain facts, requirements as well as software 

architectures both informally and formally further helps avoiding 

risks. 


7

8 

• Engineering builds on science. 

1. Introduction 1.2. What Is Different ? 1.2.4. Domain Theory 

1.2.4. Domain Theory 

• And science is expressed through theories. 

• Software engineering, for every specific software (product) 

development, builds on usually three sets of theories: 

– theories of programming, 

– theories of the application domain and 

– theories of software development practice & management. 

• The example of this paper builds on a programming theory of 

formal specification, abstraction, refinement and verification. 

• The example itself builds a theory of a transport domain. 

• The person we are all honouring with this symposium has 

contributed, well, almost established the field of software 

development practice & management. 


1. Introduction 1.2. What Is Different ? 1.2.4. Domain Theory 

• The example of this paper does not really present a theory. 

• It primarily lays a foundation for such a theory. 

• A theory, in the sense as we shall mean it, 

– presents a set of axioms, 

– some proof rules, and 

– a set of theorems 

– that can then be proven. 

• The proof rules are those of the specification language. 

• The axioms is pretty much all the formulas 

(from Item 1 on page 27 to Item 27 on page 49) 

that we have written down — plus much more. 

• We need to express (and prove) far more theorems. 


9

10 1. Introduction 1.3. Relation to Other Work on Domains 

• The terms 

1.3. Relation to Other Work on Domains 

– ‘domain analysis’, 

– ‘domain specific languages’ and 

– ‘domain engineering’ 

are used, 

– by different authors, 

– in different contexts, and hence 

– with different meanings. 


1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 

1.3.1. Domain Analysis 

1.3.1.1. An Information Science Viewpoint: 

Hjørland & Albrechtsen suggested domain-analysis as a new paradigm for Library 

and Information Science (LIS): 

• ‘The domain-analytic paradigm’ is a theoretical approach to Information 

Science (IS), 

• which states, that the best way to understand information in LIS 

• is to study the knowledge-domains as ‘discourse communities’, which are 

parts of the society’s division of labor. 

• Knowledge organization, structure, co-operation patterns, language and 

communication forms, information systems and relevance criteria are 

reflections of the objects of the work of these communities and of their role 

in society. 

• The individual person’s psychology, knowledge, information needs, and 

subjective relevance criteria should be seen in this perspective. 


11

12 1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.1. An Information Science Viewpoint: 

Our understanding of ‘domain analysis’ is less ambitious. 

• Our approach is involved in ‘discourse communities’, we refer to 

them as domain stake-holders. 

• Such terms as ‘knowledge organization, structure, co-operation 

patterns, language and communication forms, information 

systems and relevance criteria are here reformulated into simple 

entities, actions, events and behaviours. 

• We do not consider ‘the individual person’s psychology, 

knowledge, information needs, and subjective relevance 

criteria’. 


1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.1. An Information Science Viewpoint: 

• Our approach to ‘domain analysis’ is to create a model for a 

domain, 

– a model from which we can “derive” computable requirements, 

– a model which we can formalise in order to prove properties, and 

– in general, in order to create a domain theory. 

• We seek to describe only that in the domain which can be 

objectively “measured” and hence modelled mathematically. 

• Our technical approach thus appears to be quite different from that 

of Hjørland & Albrechtsen . 


13

14 

1. Introduction 1.3. Relation to Other Work on Domains 1.3.1. Domain Analysis 1.3.1.2. A More Conventional Software Engineering Viewpoint 

1.3.1.2. A More Conventional Software Engineering Viewpoint 

• The more conventional understanding of domain analysis is in 

connection with software product line R&D. 

– In [Champeaux et al.: Chap. 13: Domain Analysis, 1993], 

– in various papers by D. Batory and his colleagues, 

– and in The FODA Report: Feature Oriented Domain Analysis [Kang et al., 

1990], 

• domain analysis is basically restricted 

– to consider only feature modelling 

– for a class of potential products (a product line), 

– and is hence bound to considerations of requirements and software design. 

• To us, domain analysis goes well beyond those concerns, 

– it is not restricted to be aimed at requirements and software design 

subsequent to domain description, but 

– stands alone and can be concerned with just understanding the domain, free 

from any concerns of IT. 


1. Introduction 1.3. Relation to Other Work on Domains 1.3.2. Domain Specific Languages 

1.3.2. Domain Specific Languages 

• ‘Domain specific languages’ (DSL) [M.Fowler: DSLs, 2010] 

– usually are programming (less often specification) languages 

– tailored for a very specific domain. 

– And usually one can program “whole” applications within such a 

DSL. 

– Thus DSLs are typically so-called “executable” and lack 

abstraction, refinement and proof systems. 

– We are not concerned with DSLs in this paper. 

• “Our” DSL is that of RAISE [RaiseMethod] formal Specification 

Language, RSL [RSL]. 

– It allows abstraction, 

– facilitates refinements and 

– permits proofs. 


15

16 


• The domain of RAISE includes 

– software development in general and 

– quite a number of real-life, also man-made universes of discourse. 

• But RAISE is not “universal”. 

– In fact, none of the leading formal specification languages 

(including RSL) can cope with 

∗ all facets of all possible software developments, but it can with 

quite a few, nor with 

∗ all observable phenomena of all domains, but again it can 

handle quite a few. 

– What, then, to do for cases where a DSL fails. 

– Well, as for DSLs (cf. [M.Fowler: DSLs, 2010]), one combine two 

or more DSLs. 



• Besides RSL there are other formal specification languages, some 

leading ones are: 

–Alloy, 

–CafeOBJ, 

–CASL, 

–B, Event B, 

–VDM and 

–Z. 

• These are then to be used jointly with one or more of, for example: 

–DC, 

–Timed Automata, 

–MSC, 

–Petri nets, 

–Statechart and 

–TLA+. 


17

18 

1. Introduction 1.3. Relation to Other Work on Domains 1.3.3. Domain Engineering 

1.3.3. Domain Engineering 

• The term ‘domain engineering’ is commonly used synonymously 

with ‘software product line engineering’. 

• Our use of the term may not be that fortunate: 

– perhaps we should rather use the term ‘domain analysis and 

description engineering’. 



• The distinguishing point between the ‘software product line 

engineering’ term and our use of the term ‘domain engineering’ is 

the following: 

– The ‘product line’ term refers to a usage 

∗ where domain analysis 

· (usually informal, 

· but except for its “tie-in” to software feature analysis, 

· like ours) 

is but part of the meaning of the ‘product line’ term. 

∗ The “larger” meaning of the ‘product line’ term 

∗ is that domain analysis plays a rôle, 

∗ but the goal is software versions. 


19

20 


– Our use of the term ‘domain engineering’ 

∗ does not necessarily entail software; 

∗ we are focused only on the domain; 

∗ we entertain no considerations of software features; 

∗ we wish to establish, independent of software, a theory of the 

domain being considered. 

– But, as a derivative from domain engineering comes the 

possibility of “deriving” requirements. 

– In [Domains: Their Simulation, Monitoring and Control] we 

show how a single domain description can be the basis for a wide 

software product line. 

∗ In this sense the two interpretations of ‘domain engineering’ 

converge. 


1. Introduction 1.4. Structure of This Talk 

1.4. Structure of This Talk 

1.4.1. General 

• We overview the Triptych model of software development (first 

part of Sect. 2), that is we highlight some, but far from all, aspects 

of 

– domain engineering (Sect. 2.1) and 

– requirements engineering (Sect. 2.2). 

– We omit detailed consideration of software design (Sect. 2.3). 

• Then we relate the Triptych approach to the “Two Rights” 

formulated in [Boehm81]. 


21

22 1. Introduction 1.4. Structure of This Talk 1.4.2. Rôle of The Example 

1.4.2. Rôle of The Example 

• In connection with the brief summarisations of 

– domain and 

– requirements 

engineering 

• we bring the rather large example. 

– Without a reasonably “substantial” example our brief summaries 

would be mere postulates. 

– With the example we can now better see 

∗ how a not insignificant number of domain description and requirements 

prescription development principles and techniques 

∗ warrant a far more detailed understanding of software engineering process 

models [Spiral-Model-Boehm-1988]. 


2. Introduction 

2. An Example of Triptych Software Development 

• Before software can be designed 

– one must have a solid grasp 

– of its requirements. 

• Before requirements can be precisely prescribed 

– one must have a solid grasp 

– of the [application] domain. 

• The Triptych model of software development hence evolves 

around 

– a phase of domain engineering, 

– a phase of requirements engineering and 

– a phase of software design — 

• properly reiterated while incrementing scopes and spans. 


23

24 

2. An Example of Triptych Software Development 2.1. Domain Engineering 

2.1. Domain Engineering 

2.1.1. Business Processes 

• The business processes of transport nets include: 

– (1) transport: vehicles entering and leaving the net at any hub 

or along any link and moving along routes seen as sequences of 

links and hubs; 

– (2) the maintenance, extension and reduction of nets through 

insertions and removals of hubs and links; 

– etcetera. 

• Telling a careful “story” here 

– is a good entry 

– to the more stringent domain descriptions to follow. 

• We later follow-up on BPE by BPR: business process 

re-engineering. 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.2. Domain Description 

2.1.2. Domain Description 

• The core part of the domain engineering of an application area is 

the description of the domain. 

• A domain description tells us the facts of the domain — 

– of what can be objectively observed 

(by human senses and physical apparati): 

∗ simple entities, 

∗ actions, 

∗ events and 

∗ behaviours. 


25

26 

2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.2. Domain Description 

• A domain description tells us of 

– what the domain is, seen from certain points of view, 

– without any reference to software for that domain 

– let alone requirements to such software. 

• A domain description is a specification of the domain 

modulo any requirements. 

• Let us exemplify fragments of descriptions for a domain of 

transport nets. 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.3. Simple Entities 

2.1.3. Simple Entities 

The basic simple entities of transport nets are their hubs 

(intersections, stations, airports, harbours) and links (road segments, 

rail tracks, air lanes and sea lanes, respectively). 

1. There are net, hubs and links 

2. From a net one can observe a set of 

one or more hubs and zero or more 

links. 

Hubs and links are sub-entities of composite nets. 

type 

1. N, H, L 

value 

2. ωHs: N → H-set, ωLs: N → L-set 


27

28 

2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.1. Unique Entity Identifiers: 

2.1.3.1. Unique Entity Identifiers: 

In order to identify how hubs and links are composed into nets we 

introduce the abstract concepts of unique hub and link identifiers. 

3. Hubs and links have unique and 

distinct identifiers. 

type 

3. HI, LI 

value 

3. ωHI: H → HI, ωLI: L → LI 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.2. Mereology: 

2.1.3.2. Mereology: 

The mereology of composite simple entities such as nets explains how 

its sub-entities are composed. 

4. From hub one can observe the 

identifiers of the zero or more links to 

which it is connected. 

5. From a link one can observe the 

identifiers of the two hubs that the 

link connects. 

6. Hubs and links so referenced in links 

and hubs are indeed hubs and links of 

the net. 

value 

4. ωLIs: H → LI-set 

5. ωHIs: L → HI-set 

axiom 

6. ∀ n:N,h:H,l:L•h ∈ ωHs(n)∧l ∈ ωLs(n) ⇒ 

6. let lis=ωLIs(h),his=ωHIs(l) in 

6. card his = 2 ∧ 

6. ∀ li:LI•li ∈ lis ⇒ 

6. ∃ h ′ 

:H • h ′ 

∈ ωHs(n)∧ωHI(h ′ 

)=li∧ 

6. ∀ hi:HI•hi ∈ his ⇒ 

6. ∃ l ′ 

:L • l ′ 

∈ ωLs(n)∧ωLI(l ′ 

)=hi 

6. end 


29

30 

2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.3. Simple Entity Attributes: 

2.1.3.3. Simple Entity Attributes: 

Entities have attributes. These are properties. Essential properties 

cannot be “removed” from an entity of a certain kind without 

destroying its being an entity of that kind. Inessential properties 

can be so ‘removed’ without such a ‘destruction’. 

7. Nets have geographical area of 

location, names, owners and so on, 

attributes. 

8. Hubs 1 have geographical location, 

length, name, and so on, attributes. 

9. Links 2 have geographical locations, 

name, and so on, attributes. 

1 besides unique identification and the identification of its connected links 

2 besides unique identification and the identification of its connected hubs 

type 

7. Area, Name, Owner, ... 

8. Loc, Len, Name, ... 

9. Loc, Name, ... 

value 

7. ωArea: N → Area, ... 

8. ωLoc: H → Loc ... 

9. ωLocL: L → Loc ∗ , ... 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.3. Simple Entities 2.1.3.4. States: 

2.1.3.4. States: 

The domain describer chooses a suitable subset of simple entities to 

serve a notion of state. Nets form an important state-notion. With 

hubs and links we associate observable state attributes. 

10. A hub (h) state, hσ, is a set of pairs of link 

identifiers (each pair (li, lj) stands for the 

ability to move from link li to link lj, where it 

is assumed that {li, lj, . . .} ⊆obs LIs(h)). 

11. A link (l) state, lσ, is a set of zero, one or two 

pairs of hub identifiers (each pair (hm, ln) 

stands for the ability to move on link l from 

hub hm to hub hn, where it is assumed that 

{hm, hn} =obs HIs(l)). 

12. A hub (h) state space, hω, is the set of hub 

states that a hub may take on. 

13. A link (l) state space, lω, is the set of hub 

states that a link may take on. 

type 

10. HΣ = (LI×LI)-set 

11. LΣ = (HI×HI)-set 

12. HΩ = HΣ-set 

13. LΩ = LΣ-set 

value 

10. ωHΣ: H ⇒HΣ 

11. ωLΣ: H ⇒HΣ 

12. ωHΩ: H ⇒HΩ 

13. ωLΩ: H ⇒HΩ 

axiom 

12. ∀ h:H •ωHΣ(h)∈ωHΩ(h) 

13. ∀ l:L •ωLΣ(l)∈ωLΩ(l) 


31

32 

2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.4. Actions 

2.1.4. Actions 

Actions occur. An action potentially changes a state. 

14. Nets are [de-]constructed from new 

net, insert and remove hub and insert 

and remove link actions. 

15. An insert hub (or link) action can be 

designated by providing a “fresh” hub 

(or link) with suitable unique identifier 

properties. 

16. A remove hub (or link) action can be 

designated by providing a suitable 

unique identifier. 

17. Insert and remove actions are 

commensurate with the net: the hub 

and link are new; so are their 

identifiers; inserted hubs are not 

connected, inserted links are 

connected. 



type 

value 

14. ActDes = iH | rH | iL | rL xtr LIs: N → LI-set, xtr HIs: N → HI-set 

15. iH :: H 

xtr LIs(n) ≡ {ωLI(l)|l:L 

16. rH :: HI 

15. iL :: L 

16. rL :: LI 

axiom 

17. ∀ n:N,iH(h),rH(hi),iL(l),rl(li):ActDes ⇒ 

17. h ∈ ωHs(n) ∧ l ∈ ωLs(n) ∧ 

17. hi ∈ xtr HIs(n) ∧ li ∈ xtr LIs(n) 

17. ωLIs(h)={} ∧ ωHIs(l)⊆xtr HIs(n) 

•l ∈ ωLs(n)} 

xtr HIs(n) ≡ {ωHI(h)|h:H•h ∈ ωHs(n)} 

get H: HI → N ∼ → H,get L: LI → N ∼ → L 

get H(hi)(n) ≡ 

let h:H•h ∈ ωHs(n) •hi=ωHI(h) in h end 

pre: ∃ h:H•h ∈ ωHs(n) •hi=ωHI(h) 

get L(li)(n) ≡ 

let l:L•l ∈ ωLs(n) •li=ωLI(l) in l end 

pre: ∃ l:L•l ∈ ωLs(n) •li=ωLI(l) 


33

34 


The following action specifications should be “obvious”: 

value 

newN: Unit → N 

newN() as n 

post (ωHs,ωLs)(n)=({},{}) 

emptyN: N → Bool 

emptyN(n) ≡ (ωHs,ωLs)(n)=({},{}) 

insertH: iH → N ∼ → N 

insertH(iH(h))(n) as n ′ 

pre iH(h): axiom 17. 

post ωHs(n)=ωHs(n ′ 

) ∪ {h} ∧ 

ωLs(n)=ωLs(n ′ 

) 

removeH: rH → N ∼ → N 

removeH(rH(hi))(n) as n ′ 

pre iH(hi): axiom 17. 

post ωLIs(get HI(hi)(n))={} ∧ 

ωHs(n ′ 

)=ωHs(n)\{get HI(hi)(n)} 

18. The above action definitions can be proven to result in nets that 

satisfy previously stated axioms. 

theorem: 

18. ∀ n:N,h:H,hi:HI•h∈ ωHs(n)∧hi=ωHI(h) 

18. ⇒ removeH(rH(hi))(insertH(iH(h))(n))=n 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.5. Events 

2.1.5. Events 

• A domain event can be characterised 

– a time or a time interval (“the” time [interval] of the event), 

– a pair of states of the domain: just before and right after the 

event, and 

– a predicate over time and the state pair. 

• Examples of transport events could be: 

– a mud slide covering a link or a hub and 

– a vehicle veering off a link. 

• We shall omit more detailed descriptions, including formalisations, 

of events in this paper. 


35

36 

2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.6. Behaviours 

2.1.6. Behaviours 

• Behaviours are sets of sequences of actions, events or behaviours. 

• Our example shall model such sequences by a function from time to 

states of nets and positions of vehicles on the net. 

19. Vehicle traffic 

(a) There are vehicles and there is time. 

(b) Vehicles are positioned at hubs 

(c) or fractions down links. 

(d) Vehicles either do not move or move 

monotonically. 

(e) Vehicles may leave or enter the net. 

type 

19(a). V, T 

19(b). VP == atH(hi:HI)|onL(fhi:HI,f:F,li:LI,thi:HI) 

19(c). F = Real axiom 0≤f≤1 

19(d). TF = T → (N × (V →m VP)) 

19(e). etcereta. 


2. An Example of Triptych Software Development 2.1. Domain Engineering 2.1.7. Discussion 

2.1.7. Discussion 

• We have hinted at what a domain description contains and what it 

might look like. 

• Our descriptions form pairs of narratives and formalisations. 

• The narrative is what the stake-holders read and validate. 

• The formalisations should fit, “hand-in-glove”, the narratives. 

• The formalisations are what the domain engineers construct 

‘hand-in-hand’ with constructing the narratives. 

• Requirements engineers read and transform domain descriptions. 


37

38 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 

2.2. Requirements Engineering 

2.2.1. The Machine = Hardware + Software 

• By ‘the machine’ we shall understand the 

– software to be developed and 

– hardware (equipment + base software) to be configured 

• for the domain application. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.2. Requirements Prescription 

2.2.2. Requirements Prescription 

• The core part of the requirements engineering of a computing 

application is the requirements prescription. 

– A requirements prescription tells us which parts of the domain 

are to be supported by ‘the machine’. 

– A requirements is to satisfy some goals. 

– Usually the goals cannot be prescribed in such a manner that 

they can served directly as a basis for software design. 

– Instead we derive the requirements from the domain descriptions 

and then argue (incl. prove) that the goals satisfy the 

requirements. 

– In this talk we shall not show the latter but shall show the 

former. 


39

40 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.3. A Suitable Decomposition of the Requirements Prescription 

2.2.3. A Suitable Decomposition of the Requirements Prescription 

• We consider three forms of requirements prescription: 

– the domain requirements, 

– the interface requirements and 

– the machine requirements. 

• Recall that the machine is the hardware and software (to be 

required). 

– Domain requirements are those whose technical terms are from 

the domain only. 

– Machine requirements are those whose technical terms are from 

the machine only. 

– Interface requirements are those whose technical terms are from 

both. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.4. An Aside on Our Example 

2.2.4. An Aside on Our Example 

• We shall continue our “ongoing” example. 

• Our requirements is for a toll-road system. 

• The goals of having a toll-road system are: 

– to decrease transport times between selected hubs of a general 

net; and 

– to decrease traffic accidents and fatalities while moving on the 

toll-road net as compared to comparable movements on the 

general net. 


41

42 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.4. An Aside on Our Example 

• The toll-road net, however, must be paid for by its users. 

– Therefore toll-road net entries and exits occur at toll-road plazas 

– with these plazas containing entry and exit toll-booths 

– where tickets can be issued, respectively collected and travel paid 

for. 

• We shall very briefly touch upon these toll-booths, in the Extension 

part (as from Slide 53) below. 

• So all the other parts of the next section (Sect. on page 44) serve 

to build up to the Extension part. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.5. Business Process Re-engineering (BPR) 

2.2.5. Business Process Re-engineering (BPR) 

• Before embarking on the detailed elaboration of requirements 

– it is advised that a thorough, rough-sketching of the 

re-engineering of the business processes take place. 

– We refer to our earlier mentioning of business processes. 

– Our example focus on following up on Item (1) of BPE: 

∗ A toll-road system is a special net consisting of a linear sequence of toll-road 

links separated by toll-road hubs. 

∗ Vehicles gain access to these hubs and links by entering (and leaving) the 

toll-road net at toll plazas, through entry (respectively exit) booths 

connected to the toll-road hubs by plaza to toll-road hub hubs. 

∗ Vehicles collect tickets upon entering the toll-road net. 

∗ Vehicles move around the toll-road hubs and links. 

∗ And vehicles return tickets and pay for using the toll-road net upon leaving 

that net. 


43

44 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 

2.2.6. Domain Requirements 

• Domain requirements cover all those aspects of the domain — 

– simple entities, 

– actions, 

– events and 

– behaviours — 

• which are to be supported by ‘the machine’. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 

• Thus domain requirements are developed by systematically 

“revising” cum “editing” the domain description: 

– which parts are to be projected: left in or out; 

– which general descriptions are to be instantiated into more 

specific ones; 

– which non-deterministic properties are to be made more 

determinate; and 

– which parts are to be extended with such computable domain 

description parts which are not feasible without IT. 


45

46 2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.1. The Domain to Domain Requirements Operations 

2.2.6.1. The Domain to Domain Requirements Operations 

• Projection, instantiation, determination and extension are the basic 

engineering tasks of domain requirements engineering. 

• An example may best illustrate what is at stake. 

• The example is that of a toll-way system — in contrast to the 

general nets covered by description Items 1–19(e). 

• See Fig. 1. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.1. The Domain to Domain Requirements Operations 

links 

hubs 

General Net 

plaza 

to 

plaza 

hub 

toll−way 

p1 links p2 p3 

p7 p8 

..... 

..... 

h1 h2 h4 h7 h8 

"twinned" toll−way hub 

toll−way links 

Toll−way Net 

Figure 1: General and Toll-way Nets 


47

48 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.2. Projection 

2.2.6.2. Projection 

We keep what is needed to prescribe the toll-road system and leave 

out the rest. 

20. We keep the description, narrative and 

formalisation, 

(a) nets, hubs, links, 

(b) hub and link identifiers, 

(c) hub and link states, 

21. as well as related observer functions. 

type 

20(a). N, H, L 

20(b). HI, LI 

20(c). HΣ, LΣ 

value 

21. ωHs,ωLs,ωHI,ωLI, 

21. ωHIs,ωLIs,ωHΣ,ωL Σ 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation 

2.2.6.3. Instantiation 

• From the general net model of earlier formalisations 

• we instantiate the toll-way net model now described. 

22. The net is now concretely modelled as 

a pair of sequences. 

23. One sequence models the plaza hubs, 

their plaza-to-toll-way link and the 

connected toll-way hub. 

24. The other sequence models the pairs 

of “twinned” toll-way links. 

25. From plaza hubs one can observe their 

hubs and the identifiers of these hubs. 

26. The former sequence is of m such 

plaza “complexes” where m ≥ 2; the 

latter sequence is of m − 1 “twinned” 

links. 

27. From a toll-way net one can abstract a 

proper net. 

28. One can show that the posited 

abstraction function yields well-formed 

nets, i.e., nets which satisfy previously 

stated axioms. 


49

50 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation 

type 

22. TWN = PC ∗ × TL ∗ 

23. PC = PH × L × H 

24. TL = L × L 

value 

23. ωH: PH → H, ωHI: PH → HI 

axiom 

26. ∀ (pcl,tll):TWN • 

26. 2≤len pcl∧len pcl=len tll+1 

value 

27. abs N: TWN → N 

27. abs N(pcl,tll) as n 

27. pre: wf TWN(pcl,tll) 

27. post: 

27. ωHs(n) = 

27. {h,h ′ |(h, ,h ′ ):PC •(h, ,h ′ )∈ elems pcl} ∧ 

27. ωLs(n) = 

27. {l|( ,l, ):PC •( ,l, )∈ elems pcl} ∪ 

27. {l,l ′ |(l,l ′ ):TL •(l,l ′ )∈ elems tll} 

theorem: 

28. ∀ twn:TWN • wf TWN(twn) ⇒ wf N(abs N(twn)) 


51 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.3. Instantiation 2.2.6.3.1 Model Well-formedness wrt. Instantiation 

2.2.6.3.1. • Model Well-formedness wrt. Instantiation• 

• Instantiation restricts general nets to toll-way nets. 

• Well-formedness deals with proper mereology: that observed 

identifier references are proper. 

• We shall omit showing a formalisation of well-formedness. 

April 1, 2011, 12:27 On “The Right” Software c○ Dines Bjørner 2011, Fredsvej 11, DK–2840 Holte, Denmark

52 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.4. Determination 

2.2.6.4. Determination 

• Determination, in this example, fixes states of hubs and links. 

• The state sets contain only one set. 

– Twinned toll-way links allow traffic only in opposite directions. 

– Plaza to toll-way hubs allow traffic in both directions. 

– Toll-way hubs allow traffic to flow freely from 

∗ plaza to toll-way links 

∗ and from incoming toll-way links 

∗ to outgoing toll-way links 

∗ and toll-way to plaza links. 

• We omit formalisation. 


2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.6. Domain Requirements 2.2.6.5. Extension 

2.2.6.5. Extension 

• For our example we choose to consider the toll plazas. 

• A toll plaza, 

– in addition to its hub, 

– also contains vehicle 

∗ entry and 

∗ exit 

booths. 

• We refer to Fig. 2 on the next page. 


53

54 


Vehicle 

Direction 

Ticket Dispensor 

Entry Booth 

Exit Gate 

Entry Booth 

Exit Booth 

Enter Sensor Exit Sensor 

Car 

Entry Booth 

Exit Sensor 

Exit 

Booth 

Entry 

Booth 

Car 

Exit Booth 

Enter Sensor 

Figure 2: Entry and Exit Toll Boths 

Exit Booth 

Exit Gate 

Payment Display & Acceptor 

Ticket Collector 

Vehicle 

Direction 



• Surely the mechatronics of toll-booths warrants a detailed 

prescription; 

– it is therefore, with regret, that we omit such a prescription. 

– The “bare-bones” of a plausible prescription would take up an 

additional four pages of narratives and formalisation. 

– So we refrain. 

– Instead we refer to [Olderog & Dirks 2008] for a convincing story 

on how to domain model and develop provably correct software 

for real-time, safety critical embedded systems. 


55

56 

2. An Example of Triptych Software Development 2.2. Requirements Engineering 2.2.7. Interface and Machine Requirements 

2.2.7. Interface and Machine Requirements 

• Interface requirements take into consideration both 

– the domain description and 

– the machine: 

∗ the hardware + base systems software 

∗ upon which the software to be designed 

is to be implemented. 

• So interface requirements are not exclusively “derived” from the 

narrated and formalised domain description. 

• And the machine requirements 

– make hardly any concrete reference to the domain description. 


2. An Example of Triptych Software Development 2.3. Software Design 

2.3. Software Design 

• We shall likewise omit any serious coverage of the software design 

process — except for these remarks: 

– As the domain description serves as a model for the development 

of the requirements development, 

– so do the requirements prescription serve as a model for software 

design; that is, 

– our whole software development is model-oriented. 


57

58 

2. An Example of Triptych Software Development 2.4. A Summary 

2.4. A Summary 

• We have over-viewed the Triptych approach to software 

development: 

– core aspects of domain engineering and 

– core aspects of requirements. 

• The conclusions that one may be able to draw from the example — 

– or at least a reasonable small number of such examples — 

are 

– that domains can be described, informally as well as formally; 

– that domain requirements can be systematically (but not 

automatically) “derived” from domain descriptions; and 

– that this approach puts requirements engineering in a 

rather new light. 


3. An Example of Triptych Software Development 

3. Relations to Boehm’s Work 

• In this section we shall discuss the issue of 

– how the Triptych approach secures “the two rights” of 

software. 

• Barry W. Boehm is often quoted [The2Rights:Boehm1989] as 

having expressed: 

– “verification is building the product right, and 

– validation is building the right product.” 


59

60 

3. Relations to Boehm’s Work 3.1. Correct Software 

3.1. Correct Software 

• The Triptych approach to software correctness is based on the 

use of formal specification. 

– Ideally, and eventually, one can prove properties of even large 

scale software systems. 

– This includes proving correctness of software with respect to 

requirements. 

• Verification proofs 

D, S |= R 

– show that the Software is 

– correct with respect to the R 

– while making assumptions about the Domain. 


3. Relations to Boehm’s Work 3.1. Correct Software 

• But just the use of formal specification of software helps. 

• Then the rigorous “derivation” of 

– software designs from requirements, and 

– domain requirements from domain descriptions, 

• contributes towards “building the product right”. 

• The above claims are supported by numerous reports on the 

industry-scale use for ‘formal methods’. 3 

3 See also: http://www2.imm.dtu.dk/˜db/fm-industry-project-survey/ 


61

62 

3. Relations to Boehm’s Work 3.2. The Right Software 

3.2. The Right Software 

• Our approach to getting the right software differs from that of 

Boehm’s [Boehm-Lifetime-Achievements-2007]. 

– It is not sôlely based on validation. 

– It is first based on 

∗ a careful domain analysis, 

∗ resulting in a detailed narrative and formal description, 

– and then ending with a likewise careful validation 

∗ of that description, by the stake-holders 

∗ who, in the first place, provided the “input” to the domain analysis. 

• But we claim that Boehm’s coinage 

– “verification is building the product right, and 

– validation is building the right product” 

has been very inspirational and influential. 



• The Triptych approach to obtaining the right software is 

– ultimately based on its starting the whole development process 

– with understanding the domain thoroughly; 

– then on “deriving” domain and interface requirements from the 

domain description. 

• An important aspect of achieving the right software is 

– the dual expression of domains and requirements both 

– in terms of narratives, i.e., informal specifications, 

– and in terms of formalisations: 

– ensuring a thorough, deep and comprehensive 

∗ understanding of the domain and 

∗ of the requirements. 


63

64 

• The repeated use 


– of both [i.e., informal and formal expression], together, and 

– for domains, requirements and software design, 

– and across many distinct stake-holder groups 

has shown to lead to very low numbers of misunderstandings. 

• All this has been experienced in many industry-scale projects since 

the early 1990s [UNU-IIST-10-Years]. 


3. Relations to Boehm’s Work 3.3. Process Models 

3.3. Process Models 

• There is a much larger area of SE concern so carefully worked on 

by Boehm. 

– That area is epitomized 

∗ by his books 

· [Software Engineering Economics 1981] 

· [Risk Management 1989] 

and 

∗ by his project as of late [LeanMBASE 2006]. 


65

66 3. Relations to Boehm’s Work 3.3. Process Models 

• Supporting — indeed implied by — the Triptych approach, 

– there is a general set of generic process models 

[The SE Book Vol.3, Chaps. 16, 24, 30]. 

• Paired with, for each instance of a domain-specific development, a 

[smaller] set of software development graphs 

[misc. 1980s papers], 

– the generic process models can be instantiated with the software 

development graphs, 

– to achieve specific practices process models. 



• A [formal] domain, requirements or software specification 

– can itself be developed in stages 

– and each stage can be understood as a 360 o revolution 

– with respect to Boehm’s Spiral Model. 

• Assuming a reasonably comprehensive and complete domain model, 

– a development into requirements and software design 

– which unravels the development, “a bit at a time”, that is, 

“spiraling”, 

– now makes sense — as has been shown in a number of projects 

already in the 1980s and 1990s. 


67

68 


• These spiral process models can now be used by management for 

process assessment and improvement. 

– The care with which process models are chosen and 

deployed as described in the LeanMBASE model . 

– including, notably, the intricately laid out pragmatic 

concerns: issues, checkpoints, resolutions, etcetera, 

– is something that need be considered by Triptych users. 

• I have been much inspired and derived several benefits from 

Boehm’s work in this area — as witnessed, alas, only to a tiny 

extent by [The SE Book Vol.3, Sect. 2.4]. 


4. Relations to Boehm’s Work 

4. Conclusion 

• It seems that the R&D of LeanMBASE 

– originally took its departure point in observing how software 

engineers performed their tasks 

– and then went on to apply empirical evidence and statistically 

observable measures 

– in monitoring and controlling such developments; 


69

70 

4. Conclusion 

• whereas the R&D of Triptych 

– originally took its departure point in results from programming 

methodology: program specification and verification 

– and then went on to apply the academic ideas of programming 

methodology to larger and large scale projects, 

– ending up, in the case of Triptych, with exactly that: 

Triptych. 

• A final claim of this talk is then going to be 

– that these two diametrically “opposed” and “originating” 

approaches 

– are now merging into one another. 


4. Conclusion 

• Both the LeanMBASE and the Triptych approaches may 

appear, to some, 

– to only apply to conventional, usually large scale software 

systems 

– such as compilers, operating systems, military information, 

command and control systems, banking systems, air traffic 

control systems, etc. 

• It is, however, also fully applicable, according to our experience, 

also from observation 

– of the kind of software development that goes on in about a 

dozen software houses started by our students, and now in their 

15th–25th year of existence, 

– to the development of software that in many aspects can be 

characterised as representing “immaterial labour” so aptly 

described in [ImmaterialLabor2011]. 


71

72 5. Conclusion 

5. Acknowledgements 

• I gratefully expresses his thanks to 

– Prof. Lu RuQian, Mathematics Institute, CAS, a friend since 

1980 (The IFIP Congress in Melbourne, Australia), and 

– Prof. Li MingShu, Software Institute, CAS, a friend also of 

quite a few years 

– for enticing him to submit and partially 

– supporting him to present this paper. 

• I also gratefully acknowledges the tremendous support received 

from Prof. Lee Osterweil and the anonymous referees in their 

refereeing this paper. 

• Final acknowledgements should be given to Barry W. Boehm for 

bringing all this about !

On “The Right” Software

Create successful ePaper yourself

Delete template?

Save as template?