(A version of this note was published as three separate articles in the Communications of the ACM blog.)
Work in engineering, science or technology can only be effective if it relies on precisely defined concepts. For the fundamental notions taught at school, particularly in mathematics, physics, and chemistry, the definitions, honed over centuries, have become impeccable: integral, matrix, speed, mass, molecule… In engineering, definitions are often less satisfactory, sometimes giving the impression of following from a committee process where every member argued for the inclusion of his own pet idea, at the expense of the consistency of the result.
If you ask around you will receive general advice stating that a definition should be clear, precise, unambiguous, complete… All good, but too general.
A definition could satisfy several of these properties and still be flawed. In this article I will use examples – more precisely, counter-examples – from prestigious sources, analyze how they fail to achieve its goals, and draw some lessons for writing good definitions.
Defining requirements
The counter-example is one I used in the introductory chapter of my book about requirements engineering [1]. It comes from an IEEE standard on systems engineering [2] and reads:
Requirement: A statement that identifies a product or process operational, functional, or design characteristic or constraint, which is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance guidelines).
I am not picking on some obscure document; this particular definition is religiously cited by dozens of software engineering books and articles, even including the “Systems Engineering Body of Knowledge” [3].
The mangled syntax is not a good sign; let us be charitable and assume that “a product or process operational, functional, or design characteristic or constraint” actually means something. Translated into English, that something could be “a characteristic or constraint affecting the operation, function or design of a product or a process”. At least that is the only way in which I can parse the original so that it makes some sense. (It would have helped if the authors had at least known about the possessive in English and written “a product’s or process’s constraint, although “a constraint of a product etc.” is less contorted.)
Since the purpose of this article is not to poke fun at the venerable IEEE but to understand how to do better for our own definitions, let us turn positive and state a first rule, expressed here informally: to be crystal-clear, a definition should use the simplest language possible. The concepts may be complicated (we are talking about definitions in technology and science); no need to make comprehension harder by using contorted phrasing. One might even suggest that the more sophisticated the concepts are, the simpler the language should be.
Continuing to work from the ground up (from more superficial issues to the most important flaws in this counter-example), the end of the definition is not acceptable in a professional standard. First, again, a matter of form: there is no need to talk about “product or process” acceptability: the first part of the definition indicates that the requirement has to do with a feature or constraint of “a product or process”, so that is what we are dealing with; “acceptability” suffices.
The rule here is that a definition should be minimal and avoid repetition, which leads to confusion. Repetition is good in explanations of the definition, but the definition itself should only include the elements that are critical to identifying the concept, and include each once. Anything else causes bloat and can lead to misunderstanding. (The advice of avoiding duplication also applies to requirements; [1] contains an analysis of why repetition is bad. More generally, there is some commonality between software requirements and technical definitions.)
Overstepping the mandate
The end of the definition is flawed in a deeper way. We are told that a requirement should be “necessary for acceptability”. Fine, but how does one determine acceptability? That is a serious issue of systems engineering, but it is not part of the definition of requirement. The parenthetical remark, “(by consumers or internal quality assurance guidelines)”, is amateurish: acceptability should be determined by a well-defined process, not just summarily dismissed as something that “consumers or internal quality assurance guidelines” determine. “Consumers” is ‘not an engineering term, and is too restrictive: there are no “consumers” in a B2B product, for example (maybe they meant “customers”?). Who is the “consumer” in a compiler project? All serious companies have precise rules as to who determines the acceptability of a product or process (typically, QA engineers, not directly consumers) and how.
The authors of this definition are in over their heads here: it is not their job to determine (in this definition) who is in charge of determining acceptability. The only role of this concept in the definition of “requirement” is to state that one of the roles of requirements is to specify the conditions under which the final product will be acceptable. The occurrence of the term “acceptability” in this definition should be a reference (a hyperlink) to an “acceptability” entry in the standard. That entry can carefully and professionally specify what it takes to assess whether a product or process to be acceptable, based on concepts of quality assurance.
The definition of “requirement” is trying to do too much. It encroaches into a task (defining acceptability) beyond its job (defining requirements).
The rule here is another form of minimalism: a definition should define one concept. (In rare cases – although not this one – we may need to define two or more mutually-dependent concepts together, which we can in fact consider as a composite concept so as to fit within the rule.)
From the descriptive to the prescriptive
The example goes beyond its job in an even more serious way. It does not just try to say what a requirement is; it also decrees what a requirement should be. “Unambiguous, testable or measurable”. By the way, why “or”? Do we get a choice between testability and measurability? Probably not; the “or” was likely intended as an “and”, but that is the least of the problems.
A definition should be descriptive. With the addition of the three conditions, the definition of requirements becomes prescriptive, overstepping its role. A definition of speed tells you what speed is (ratio or derivative of distance against time); it should not tell you how fast you may drive. The confusion makes the definition of “requirement” both incomplete and wrong:
- It is incomplete because the three qualities cited (unambiguous, testable, measurable) are only a fraction of the desirable properties of requirements. For example good requirements should also be feasible, readable, prioritized… The requirements literature has in-depth discussions of the desirable quality factors; [1] has a chapter on the topic, with 14 separate factors. Why start listing some of them and stop at three? Is a requirement that satisfies one of them but not the others still a requirement?
- In fact, what about a requirement attempt that does not satisfy the quality factors, even just one of those actually included? According to the definition, if it is not “unambiguous” it is not a requirement. Nonsense. It is almost always the case that a requirements document (at least one expressed in some combination of natural language, UML and use cases, the dominant practice) will contain some ambiguity. It is still a requirement! A flawed requirement perhaps, but a requirement all the same. The speed of a car that is going over the speed limit is still a speed.
The rule here is simple: a definition should be purely descriptive. It is not a code of ethics. Any prescription on the use of the objects of the definition should come separately.
I hope this counter-example will encourage you to take a harder look at the effectiveness of some of the definitions you have encountered in your own work.
Before devising a set of general rules it is useful to consider another example, defining a notion that is particularly prominent right now: digital twins.
Digital twins
I recently attended a fascinating workshop on the just as fascinating notion of digital twin. I learned that there actually exists a “Digital Twin Consortium”, which has come up with its official definition of the term [4]:
A digital twin is an integrated data-driven virtual representation of real-world entities and processes, with synchronized interaction at a specified frequency and fidelity.
· Digital Twins are motivated by outcomes, driven by use cases, powered by integration, built on data, enhanced by physics, guided by domain knowledge, and implemented in dependable and trustworthy IT/OT/ET systems.
· Digital Twin Systems transform business by accelerating and automating holistic understanding, continuous improvement, decision-making, and interventions through effective action.
· Digital Twin Systems are built on integrated and synchronized IT/OT/ET systems, use real-time and historical data to represent the past and present, and simulate predicted futures.
Digital Twin Prototypes use data to model and simulate predicted futures before being integrated into IT/OT/ET Systems and before synchronization with the real-world entity or process.
The only part that resembles a definition appears in the first sentence. It is already debatable:
- “Integrated”: what would a non-integrated representation look like? Rule: a definition (of a category of artifacts) should be decidable, enabling a competent reader to determine whether a candidate artifact satisfies the definition or not.
- “Virtual”: what does that exactly mean? Probably a software representation, as already implied by the term “digital” in the name of the concept. A book description is “virtual” but probably not a digital twin. Why not say “a software representation”?
- “Real-world” is a treacherous word. What is real-world and what is not? In our digitalized-to-the-teeth society, software is so much part of reality that it becomes difficult to separate real-world from unreal-world (?) entities. Besides, the emphasis on modeling the real world is probably wrong, or at least restrictive: it is perfectly reasonable to have a digital twin of a software system, or another “virtual” system.
- “Synchronized interaction”: what would a non-synchronized interaction look like? To interact, you must synchronize in some way. (Rule: a definition should be falsifiable: there have to be artifacts that do not satisfy it; otherwise it is useless.)
- “At a specified frequency”. This requirement is very general. Assume for example that you have written a book that describes the US political system (president, congress, federal courts), and produce a new edition every 10 years. It is data-driven (integrated, I do not know, as the concept is vague); virtual; representing real-world-entities and processes; subject to synchronized interaction at a specified frequency (10 years); and presumably enjoying fidelity if correct at the time of publication. So, per the definition, it is a digital twin! I wonder, though, whether the Digital Twin Consortium would want to accept it.
- “Fidelity”. We understand the concept: the representation should be faithful. The phrasing is awkward because this property affects the representation, not the interaction (interaction at a specified frequency makes sense, but what is interaction at a specified fidelity?). But it is difficult to verify and enforce. Any representation is, by construction, unfaithful in some ways: full fidelity would mean that it reproduces every feature of the “entities and processes” it represents, but then it is not a representation any more, it is those entities and processes. Producing any representation, also known as modeling, inevitably means losing some details. In well thought-out modeling techniques, such as (in software verification) model-checking and abstract interpretation, there are rules on how the model may differ from the modeled system; for example, if certain properties hold in the model they hold in the system, but that is the case for only specified kinds of property. (Specifically in model checking: if the model is free from bugs of a certain kind, we know that the system does not have such bugs; but if the bug may arise in the model, that does not mean it arises in the system, as its occurrence might be a consequence of the modeling effort.) Those issues are subtle and a simple notion of “fidelity” may not suffice to cover them.
Still, those first two lines are a definition, even if subject to criticism. The rest of the Consortium’s text is worse. It consists of bullet points without any indication of their relation to the first part (as could exist if, for example, that first part ended with something like “satisfying the following properties:”). It looks like a laundry list of desired features of digital twins that various members of the committee were determined throw in, perhaps to promote a particular digital-twin tool. It goes into the prescriptive, in a way that is even worse than the definition of requirements in the first example: per the definition, an attempted digital twin that misses some of its prescriptions, for example because it is not explicitly “driven by use cases”, or does not use historical data (only real-time data), is supposedly not a digital twin. But of course it is! Possibly an imperfect digital twin, but a digital twin anyway. In no technical field should a definition of a concept restrict instances to being perfect. It may be a specific feature of software engineering that we tend to moralize all the time, reveling in telling people how they should work, sometimes to hide that we are not able to tell them clearly what they should do.
The bullet points go against the basic rules of clear writing since they do not indicate whether they should be taken as conjunctive or disjunctive (“and” or “or”). Must a digital twin satisfy all these properties? Any of them? Some of them, and then which ones? (Rule: a definition should be unambiguous).
Each of the points brings new problems, entangling the definition further in new concepts. If the references – three of them! – to “IT/OT/ET” are really necessary, they characterize the scope of digital twin as a whole, not specific properties, so the concept should appear at the beginning (in the first two lines, the genuine definition part), to state in what domain or domains digital twins are relevant. It would in that case not be beneath the authors to say “information, operational or engineering technology” and forsake the acronyms. What is “holistic understanding” and what does a word such as “holistic” have to do in a technical definition? How do we know that “action” is “effective”?
Such an accumulation of problems makes the definition essentially unactionable.
I am not an expert on digital twins but I think I have gained a basic understanding of the concept, which would lead to a definition such as this one:
A digital twin of a system S is a software system T intended to provide a usable representation of S, such that T takes inputs from actual measurements on S and can provide valid answers to questions about properties of S and about the effects on S of hypothetical changes to these properties, and in return act on the behavior of T.
The use of names S and T is not essential but is convenient (after all, mathematicians must know something). I expect digital twin pros to find things to criticize in this definition – and I welcome suggestions for improvement – but at least it is a definition. It does not try to be a textbook on digital twins, but opens the way to any further discussion of their other desirable properties, their limitations, future developments, open questions about them, and anything else that belongs to commentary rather than definition. It states what kind of beast a digital twin is and what essential properties it must satisfy. It does not contain any repetition. It tries to be as general and as specific as needed: S is “a system” without further qualification, the digital twin T is “a software system”.
Separating news from editorial
The most common mistake made by authors of technical definitions is to believe they must contain explanations. Of course they must be clear, but explaining is not part of their role. A definition’s only role is to enable a reader to determine whether a candidate element of the universe meets the defining criterion or not.
Any explanations should come separately. Have as many of them, as detailed as you like, just not in the definition. Some programming language standards show the way: they apply a strict discipline of separating “Informative Text” from the standard’s definitions and rules (syntactic, semantic), which are the only ones that have a formal value. I learned this discipline when working on the Ecma/ISO Eiffel Standard [5], which has hundreds of extracts of this kind, making the distinction stand out:
Note the underlined words, which mark elements having their own definitions elsewhere in the text, and are clickable hyperlinks to these definitions.
If the questionable definitions cited earlier had applied such a discipline, the results would have been both more suitable as definitions (by concentrating on the essential concepts) and easier to understand and apply (by freeing the explanatory parts from perceived constraints on the length of definitions and hence giving them more space when needed to present qualifications, examples and optional characteristics).
This discussion has been rich on criticism, although it has started on the side to introduce general positive rules. It remains to build on the preceding analysis and go full positive by proposing a set of (surprisingly simple) rules for effective technical definitions.
Writing good definitions comes down to one basic rule
In software engineering as in all technical work we find ourselves writing definitions of the concepts we need to work on. Often, such definitions leave much to be desired. The previous discussions scrutinized some widely used but not so brilliant and analyzed their deficiencies. It is time now to switch to a fully positive tone: what does it take to write a good technical definition?
When I started this work I intended it, informed by consideration of numerous bad and good definitions over the years, to lead to a set of complementary rules for making a definition good. But I now think that everything in the end boils down to a single rule which I will introduce here.
To get to it, we should simply remember what the purpose of a definition is. What are we trying to define? At first it seems there are three cases, for which we may use names from grammar: noun, adjective, verb. You may be defining one of:
- A thing or concept, or a category of things or concepts, such as speed, requirement, digital twin. This is the “noun” case.
- A quality, such as being “real-time”. In grammatical terms, an “adjective”.
- An action, such as compiling a program. A “verb”.
We can, however, unify these cases into one. A definition needs to assume a certain universe, a base set; then its role is to specify an element from that universe. For example, the last version of the digital twin definition (citing: “a software system T intended to provide a usable representation of S, such that T takes inputs from actual measurements on S and can provide valid answers to questions about properties of S and about the effects on S of hypothetical changes to these properties, and in return act on the behavior of T”) indicates that the universe is the set of “systems”. The definition serves to select elements of that set: those that deserve to be considered digital twins.
In other words, the “adjective” case subsumes the other two. For a thing or concept (a “noun”), the definition indicates what quality distinguishes it from others in the universe; for an action (a “verb”) , it indicates what makes the action different from any others. For example, the digital twin definition is there to tell us under what conditions we may designate a system (an element of the universe in this case) as a digital twin.
Viewed this way, a definition is a decision mechanism. It distinguishes some elements of the universe from the others. Hence the basic rule which (if I am right) unifies all the conditions on good definitions:
Basic Rule of definitions
A definition should specify, in a clear and non-redundant way: a universe (a set); and a criterion for selecting some elements of the universe.
Concrete, specific consequences
To characterize good definitions, you can still think of particular rules, which you will find if you ask competent people (or an LLM), or look up the literature; some of them were previewed in the first two parts of this discussion; but they all turn out to be specific (if sometimes important) consequences of this one. Here are some examples.
(1) A definition should be precise. That is a consequence of the Basic Rule, since if a definition is not precise it does not provide a “clear” selection criterion.
(2) A definition should be complete. That criterion appears to be tricky: complete with respect to what? The same questions applies to completeness of software requirements (again discussed at some depth in [1]). But here it is also a consequence of the Basic Rule: being “complete” means providing all the information for deciding whether a candidate element satisfies the “criterion for selecting” it.
(3) A definition should be independent from examples. In fact the kind of definition allowed by the Basic Rule does not need examples. It does not proscribe examples if they can help define the criterion, but almost all definitions will be more abstract. Examples belong to explanatory parts.
(4) A definition should be unambiguous. Otherwise it will not provide a decision criterion.
(5) A definition should provide contextual anchoring. That is achieved by making sure it specifies the universe.
(6) A definition should be testable. Clearly implied by the rule.
Disclosure: these particular six qualities are part of the answer I got from ChatGPT to a request I made, and refined through a number of prompt iterations, to tell me what a good technical definition should look like. I think they are all good, and as can be expected from an LLM answer, they reflect widely held views (in the sources that ChatGPT consulted to build its answer); but they are all specific and can be deduced from the Basic Rule (which, of course, did not originate with any tool).
More advice
The rules mentioned in the analysis of counter-examples reviewed so far also follow from the Basic Rule:
· (7) It should use the simplest language possible. This property follows from the requirement of being clear and non-redundant.
· (8) It should be minimal and avoid repetition. This property follows from non-redundancy. Note that the Basic Rule does not use the word “minimal”. Requiring that definitions be minimal would imply a search for repeated shortening, until we are sure we have reached a demonstrably minimum length. That is too demanding; we want good definitions, and cannot require perfect ones in any formal sense. Concision, reflected by non-redundancy, is what matters.
· (9) It should define one concept. The Basic Rule says that the definition specifies a criterion.
· (10) A definition should be descriptive rather than prescriptive. Prescribing how to use the concept is not within the scope of a definition as specified in the Basic Rule.
· (11) It should be decidable. That is the basic idea behind the Basic Rule.
While all these specific rules derive from the Basic Rule, they highlight its various aspects, and provide a good checklist for a candidate definition. I have numbered them with this purpose in mind.
A definition can never be recursive (well, hardly ever)
One more requirement applies to technical definitions, particularly in mathematics and computer science. A definition (12) cannot be recursive except with special precautions. “An X is an X” does not define anything. The rule also applies to mutual recursion: “A university is a place for students to study” and “A student is someone who studies in a university” is not good enough to define “university” and “student”.
In practice, we do use recursive definitions; for example, we accept “an X is either the letter `a’ or three X in succession” as covering such sequences as `a’, `a a a’, `a a a a a’ and so on. But what we have is not a definition; it is an equation E (of the form X = `a’ |X X X) and the implicitly associated definition is “X is a solution of E”. An equation of that kind may have no solution, one solution, or a finite or infinite number of solutions.
In a well-defined context it is clear what solutions, if any, exist, and which one we mean if there is more than one, so we allow ourselves to talk of a “recursive definition” (BNF syntax definitions are a common example), but we should not forget that they are not definitions except in that sense of specified solutions to the associated equation.
A definition should be “clear”
These observations lead us to ask what is meant by “clarity” in a definition. We can leave that term to its informality (the Basic Rule is not a mathematical statement). Clarify is of course relative: what is clear to an expert can be impenetrable to novices. But that issue is not a serious concern for definitions in science, engineering and technology. They target a specific technical community, usually well identified; being clear means being clear to a typical member of that relevant audience. In the very first example, a definition of “requirement” addresses professional engineers. It should be clear to them, but is not required to make sense to someone from another field.
Which brings us to one more derived rule (13): a definition should only involve previously defined concepts. Understood literally, this goal is unreachable; you may have noted that the above injunction to avoid mutual recursion can only be reached if the definitions are rooted, directly or indirectly, in a corpus of terms taken for granted. (As a counter-example, consider an English dictionary such as Webster’s: by construction it is recursive, since the words can only be defined, ultimately, in terms of others in the dictionary.) A set of technical definitions must rely, deep down, on terms taken for granted. In light of the preceding consideration of clarity, “taken for granted” means “known to the target audience” with the addition – in a compendium of definitions such as a technical standard – of terms that have their own definition elsewhere in the text, avoiding mutual recursion whenever possible.
Finally note that (14) a definition should be non-creative. Postulating that something exists is the purpose of axioms, not definitions. As the Basic Rule tells us, a definition works from a universe, so all the objects of interest should already exist, in the physical world or in one of our intellectual constructions. The definition just selects some; it does not create them.
All of us working in the technical field need sound, simple and effective definitions of the concepts with which we deal. I hope this discussion will help.
References
[1] Bertrand Meyer, Handbook of Requirements and Business Analysis, Springer, 2022.
[2] IEEE Standard for Application and Management of the Systems Engineering Process, 1220-1998, available at https://ieeexplore.ieee.org/document/741941 (paywall). The cited definition is 3.1.33, page 8 (page 15 of the PDF).
[3] Guide to the Systems Engineering Body of Knowledge (SEBoK), https://sebokwiki.org/wiki/Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK).
[4] Digital Twin Consortium, https://www.digitaltwinconsortium.org/initiatives/the-definition-of-a-digital-twin/.
[5] Ecma International and ISO standard: Ecma-367 – Eiffel: Analysis, design and Implementation Language, 2nd edition, June 2006, https://ecma-international.org/publications-and-standards/standards/ecma-367/. (The extract shown is from the next revision, planned for 2026.)
