FAQs: Frequently Asked Questions

25. Should/can/must stakeholders understand formal specifications?

No, not necessarily. As we have advocated, proper developments should contain complementary informal and formal descriptions, prescriptions and specifications.

For a number of software developments, customers may engage consultants to also check that the formal descriptions, prescrip-tions and specificaprescrip-tions are up to standard.

For a number of software products, insurance companies re-quire that a certified company, like Lloyd’s [165] (or such simi-lar companies as Norwegian Veritas [192], Bureau Veritas [68] or T ¨UV [237]), regularly and irregularly, unannounced, inspect and, in various ways, check the development. Such insurance and “ver-ification” companies are increasingly turning to formal techniques so their staff can understand and professionally evaluate the use of formal descriptions, prescriptions and specifications.

26. What should/could be the languages of informal descriptions?

For domain descriptions it should be the national, i.e., natural language of the client plus the professional language of the domain.

No IT jargon is basically needed — unless, of course, IT plays a nontrivial rˆole in the already existing domain.

For requirements prescriptions the answer is the same as for domain descriptions, except that now one is allowed to use, in appropriate areas of typically interface and machine requirements, an appropriate, generally established sublanguage of IT.

For software designs — for which we have not dealt with infor-mal annotations to any serious extent — it is, of course, necessary to use the language also of IT (software).

As for domain-specific languages, make also sure that proper terminologies are established for the IT (software) sublanguages that are used.

27. What should/could be the languages of formal descriptions?

Whichever is most appropriate and at hand. For most develop-ments that we know of, i.e., for most problem frames, the RAISE Specification Language, RSL, is adequate. You can then, when and as needed, augment RSLdescriptions, prescriptions or spec-ifications with Petri nets [148, 199, 210–212], message sequence charts [142–144], live sequence charts [80, 128, 153], statecharts [123,124,126,127,129] or duration calculus [247,248] descriptions, prescriptions or specifications — or several of these. These “aug-mentations” were covered, to some nontrivial depth, in [32, Vol. 2, Chaps. 12–15].

Or you can use CafeOBJ [89, 90, 99, 100]. The CafeOBJ soft-ware support system allows stepwise development, execution and verification of CafeOBJ specifications.

Or you can use B [1, 71], Event B, VDM-SL [55, 56, 95, 96] or Z [132,133,229,230,242] — all come, or will soon come, with suit-able Petri net, message or live sequence chart, statechart, duration calculus or TLA+ [156, 175] augmentations.

RSLvariants ofUML’s Class Diagrams may also be advisable [32, Vol. 2, Chap. 10].

28. When have we specified enough — minimum/maximum?

You have specified enough, both informally and formally, when what is left to describe are such things as identifier formats. That is, when you have specified everything but possibly that, then you have specified the necessary and sufficient amounts. The trivial things left unspecified are those things that one can safely trust the software designer to make final and trustworthy design de-cisions about. Also, certain aspects of graphical user interfaces, specific handling of tactile input, etc., seem to belong to this class of initially unspecified things.

Domains

29. Why domain engineering by computing scientists and software engineers?

Because computing science has the tools, namely the specifica-tion languages, and because computing science has the principles and techniques of abstract modelling. Mathematicians — in some sense — could be claimed to have similar such tools, but they really do not. Their abstractions go well beyond those that are needed for domain modelling. They are not interested in proof systems, for example, for formal specifications — but in the more

general notions of power of such proof systems, etc. Finally, the computing scientists interface, daily, with software engineers — and, in the hard realities of the day, domain theories are the first to be demanded by software engineers.

Most formal specification languages can handle systems that evolve, that is, whose components grow and shrink. Mathematics, in todays’ conventional sense, cannot handle system evolution.

30. Should one use normative and/or instantiated domain descriptions?

This is a contentious issue. For a specific requirements develop-ment one may be tricked into developing only an instantiated do-main description, that is, a dodo-main description that is already instantiated to the specific domain.

Some authors seem, in their writing, to assume instantiated domain descriptions. The author of this volume advises normative, i.e., generic, domain descriptions.

31. Who should research and develop domain theories?

There are basically three possibilities, listed in causal order:

• initially university and academic research centre computing sciencedepartments, i.e., their staff,

• eventuallydomain-specificuniversity and academic research centre departments, and

• finally, domain-specific commercial companies.

Initially it is advised that university and academic research cen-tre computing science scientists research and develop domain models. As mentioned above, in item 29, initially the computing scientists have the basic methods needed to do domain theory re-search, and are also interested in the engineering of large-scale documentation, etc.

But eventually, within years, say 3–5 years after the initial start of computing science R&D in domain theories, it should also be undertaken by domain-specificresearch groups: transporta-tion, in healthcare, in financial services, in marketing and sales (e-marketing), etc. Just as such university departments are, to-day, using (applied) mathematics, we can foresee that they will also be able, soon, to use even fairly sophisticated computing sci-ence ideas.

And, finally, private, commercial companies, for example, software houses strong in a particular application domain, will embark on such domain theory R&D, as will suppliers of any form of technology to companies within the domain.

32. What is the timeframe for the R&D of domain theories?

It is strongly believed that the timeframe for the R&D of domain theories is of the order of 10 to 20 years, or in cases up to 30

years, before one can safely say that a domain theory has been established.

In other words: Patience is called for. Conviction that estab-lishing such theories is of utmost importance is called for.

To do research and development on domain theories seems to belong to the category of “Grand Challenge” endeavours (Sect. 1.4.3).

Requirements

To us, there are basically only two questions concerning requirements devel-opment:

33. Requirements always change, so why formalise?

No! It may be true that people conceive of requirements “always changing”. But we venture to claim that such “changes” are re-ally not so much “changing requirements” as they are, or reflect, increased, and hence better, understanding of the domain.

In other words: Given that one had an established, i.e., a rea-sonably comprehensive, domain theory, we will then claim that requirements do not change “so much” (as before conceived)!

34. Must we formulate requirements strictly before software design? This question could also appear in the previous section as:Must we determine domain descriptions strictly before requirements prescriptions?

In both cases the answer is: Yes, for the time being. Till such a time when we indeed have (i) reasonably firmly established domain theories, and (ii) a sufficient body of knowledge, i.e., experience with requirements “strictly derived” from domain theories, until such a time we are, due to commercial, i.e., competitive, pressures, more or less forced to develop domain descriptions hand-in-hand with requirements prescriptions, and the latter hand-in-hand with early stages of software design. The special approach to software development shows a way in which to develop domain descriptions

“staggered” with the development of requirements prescriptions, and these again “staggered” with the development of software ar-chitecture design — where, by “staggering”, we mean that one phase follows almost right “on the heels” of the preceding phase.