3 A Theory of Requirements Engineering - Part II
The previous chapter introduced the first part of the theory of requirements engineering by defining key concepts: the World and the Machine, phenomena, Machine inputs and outputs, actors and stakeholders.
This chapter presents the second part. It starts by defining the concepts of behaviours, properties, domain goals, machine requirements and domain assumptions. It then explains the important formula Req, Dom \(\vdash\) Goals that relates software requirements and domain assumptions to domain goals. The chapter ends by summarising the implications for practices of this theory and by discussing important aspects of requirements engineering beyond this theory.
3.1 Behaviours and Properties
Discovering requirements involves understanding which behaviours stakeholders consider desirable or undesirable in the world. This section defines what we mean by behaviour and explains how properties characterise sets of behaviours.
Behaviours
Figure 3.1 and Figure 3.2 show two behaviours for the ground braking system.
In Figure 3.1, the behaviour is a sequence of three sets of phenomena, holding at time t0, t1, and t2, respectively. At time t0, the plane is flying; at a later time t1, the plane is moving on the runway and the ground braking is enabled; and at the later time t2, the plane is moving on the runway, the ground braking is enabled and the reverse thrust is deployed. Between time instants, the phenomena stay the same. This sequence illustrates a normal, expected behaviour of the ground braking system.
In Figure 3.2, the behaviour also has three time instants. At time t0, the plane is flying. At time t1, the plane is still flying and ground braking is enabled. At time t2, the plane is flying, ground braking is enabled and reverse thrust is deployed. This is an undesirable behaviour because we do not want reverse thrust to be deployed while the plane is flying.
A synonym for ‘behaviour’ is ‘scenario’. In practice, scenarios can be represented using a variety of textual and graphical notations that are more stakeholder-friendly than the notation used in Figure 3.1 and Figure 3.2. For example, behaviours can be described as UML use case scenarios, domain stories, or given-when-then scenarios from Behaviour Driven Development. These techniques will be described in Chapter 18 and Chapter 20. The concept of behaviour is also fundamental to process models, state machines, and for the definition of domain goals, machine requirements and domain assumptions.
Properties
Listing all conceivable behaviours of a system and classifying each one individually as either desirable or undesirable would be tedious and never-ending. A more practical approach is to formulate properties that characterise entire sets of behaviours as either desired or undesired.
A behavioural property, or property for short, is true for a set of behaviours and false for all other behaviours. For example, the property that “reverse thrust should not be deployed when the plane is flying” is true of all behaviours that satisfy this condition (Figure 3.1 and many others), and false of all behaviours that violate it (Figure 3.2 and many others).
A property is an abstract condition that exists in people’s minds; it can be formulated in multiple ways. For instance, the statement “If the plane is flying, reverse thrust must not be deployed” expresses the same property as “reverse thrust should not be deployed when the plane is flying”. Even a more loosely worded version—such as “reverse thrust must be safe during flight”—may be referring to the same underlying property, though in a less precise way.
A property may be formulated in multiple natural languages–for example in English, French, Arabic and Chinese. These would be multiple formulations of the same property.
Properties can be formulated in natural language and formal logic. For example, two properties for the ground braking system are:
(G1) Ground braking must be enabled when the plane is moving on the runway.
MovingOnRunway=>GrdBrakingEnabled
(G2) Ground braking must be disabled when the plane is flying.
Flying=> \(\neg\)GrdBrakingEnabled
In the formal logic expressions, P => Q means that P implies Q at the current and all future times; and \(\neg\) is the logical symbol for negation (“not”).
Going back to the relation between properties and behaviours, we can observe that the behaviour in Figure 3.1 satisfies G1 and G2. At time t0, when the plane is flying, ground braking is not enabled. At time t1 and t2, when the plane is moving on the runway, ground braking is enabled. We can also observe that the behaviour in Figure 3.2 does not satisfy G2 because at times t1 and t2, the plane is flying and ground braking is enabled.
Natural languages and formal logic
In requirements engineering, natural language is always the primary language for communicating properties. Logical formulae are optional and usually not shown to stakeholders. Some requirements engineers use formal logic “behind the scenes” to facilitate reasoning and perform complex analysis using automated tools. The findings of such analysis are then communicated back to stakeholders in natural language.
For people who have learned formal logic, formulating properties in logic has many benefits:
- well-written logic formulae are shorter and easier to read than the equivalent natural language sentences;
- their structure is not subject to ambiguity (e.g. no pronouns ambiguity, no ambiguity about the scope of logical connectors);
- they can be analysed automatically using a variety of tools for consistency checking, simulation and verification;
Expressing software requirements in a formal language also provides the basis for automated test generation, program verification, program synthesis, and debugging.
The rest of the book does not require knowledge of formal logic beyond what is covered in standard introductions to logic for computer scientists; that is, it assumes that you understand the main propositional logic operators (not, and, or, implies, if and only if). Chapter 13 provides more information about automated tools used to analyse and debug requirements expressed in formal languages. Chapter 21 provides a short introduction to the use of temporal logic for formulating goals, requirements and assumptions. This chapter is optional; the other chapters can be read and understood without knowledge of temporal logic.
3.2 Goals, Requirements, Assumptions
Requirements engineering is concerned with three types of properties:
- domain goals, which are desired properties of the world;
- machine requirements, which are desired properties of the machine at its interface with the world;
- domain assumptions, which are assumed properties of the world.
Let’s look at each of these property types in more detail.
Domain Goals
When the context is clear, we will simply write “goal” for domain goal.
We also use the term stakeholder goal–a generalization of “user requirement”– to denote a domain goal that some stakeholder wants to be true of the world.
Examples
Two goals for the ground braking system are the properties G1 and G2 introduced earlier and recalled here:
(G1) Ground braking must be enabled when the plane is moving on the runway.
MovingOnRunway=>GrdBrakingEnabled
(G2) Ground braking must be disabled when the plane is flying.
Flying=> \(\neg\)GrdBrakingEnabled
A domain goal for an ambulance dispatching system is:
An ambulance must arrive at the incident scene within 14 minutes after the first call reporting the incident.
In this example, the 14-minute target comes from a UK Government standard that was in place at the time the London Ambulance Service first automated its ambulance dispatching system.
Grammar
In English, domain goals are formulated using modal verbs like “must”, “should”, or “shall” that convey expectations, recommendations or obligations. They form sentences in the optative mood — a grammatical mood that expresses wishes. Other languages have their own modal verbs and sentence structures to express wishes and expectations.
Characteristics
Domain goals have three important characteristics.
- Goals are formulated in terms of World phenomena. Because a goal is a desired property of the world, its formulation must refer to world phenomena. For example, G1 and G2 refer to
Flying,MovingOnRunwayandGrdBrakingEnabled. The goal of the ambulance dispatching system refers to two classes of phenomena: incident reporting and ambulance arrivals at incident scenes. The phenomena that a goal refers to may not be shared with the machine–that it, the goal may refer to world phenomena that are neither machine inputs nor outputs. - Satisfying a goal may involve multiple actors, not just the machine. For example, satisfying the above domain goal for the ambulance dispatching system requires the involvement of many actors: call takers, ambulance crews, GPS, the ambulances’ mobile data terminals and the ambulance dispatching software. The ambulance dispatching software cannot satisfy this goal by itself. For the ground braking system, satisfying goals G1 and G2 involves the wheels sensors (which detect whether the plane is moving on the runway) and the Ground Braking Controller (which enables and disables the system based on signals it receives from its sensors).
- Not all domain goals must be satisfied. Identifying and formulating a domain goal does not mean that the machine must necessarily support that goal. Some goals may be too costly to satisfy for the benefits that they bring. Some goals should not be satisfied because they conflict with other more important goals. However, it is important to identify and formulate such ideal and conflicting goals in order to decide later what tradeoffs should be made.
Synonyms
The concept of domain goals has many synonyms and specializations: “business goals”, “customer requirements”, “user needs”, etc. They include all phrases matching the two-word pattern <stakeholder-word> <goal-word>, where
<stakeholder-word>is one of {stakeholder, business, customer, user, system}, and<goal-word>is one of {goal, requirement, need}.
Terms like “business goal”, “customer requirement”, and “user need” are commonly used but rarely well-defined. A reasonable interpretation is that they denote domain goals that originate from the business, a customer or a user, respectively.
Unlike goal, the term requirement carries the connotation of being a property that must be satisfied, rather than one that is merely desired. Under this interpretation, a customer requirement can be seen as a particular kind of domain goal: one that originates from the customer and that must be satisfied. In practice, however, the term requirement is often used more loosely to mean a candidate requirement. For example, during requirements prioritisation, you may hear people refer to mandatory and non-mandatory requirements. If the term requirement were taken literally, mandatory requirement would be a pleonasm, and non-mandatory requirement an oxymoron.
Machine Requirements
Machine requirements can be viewed from two perspectives:
- From the implementation perspective, machine requirements are desired properties of the machine that define a desired relation between machine inputs and outputs. They are the properties to be satisfied by the machine implementation. These properties drive the software design, coding, testing and debugging processes.
- From the requirements engineering perspective, machine requirements are also desired properties of the world at the interface with the machine. Machine requirements are thus special kinds of domain goals: they are domain goals that refer to shared phenomena only and that must be satisfied by the machine alone.
Example
A machine requirement for the ground braking system is:
(R1) Ground braking must be enabled when the wheels sensors indicate that the wheels are turning.
WheelsPulsesOn=>GrdBrakingEnabled
To keep things simple, we assume for the moment that all domain goals and machine requirements are behavioural properties. We will see later that domain goals and machine requirements also cover quality properties (i.e. some of the “non-functional” requirements like performance, availability, etc.)
Characteristics
Let’s review two important characteristics of machine requirements.
Machine requirements refer to shared phenomena only. They cannot refer to world phenomena that are not shared with the machine. For example, the goals G1 and G2 are not machine requirements because they refer to the phenomena
FlyingandMovingOnRunwaythat are not shared with the ground braking controller. The requirement R1, however, is formulated entirely in terms of shared phenomena:WheelsPulsesOnandGrdBrakingEnabled.Machine requirements must be satisfied by the Machine alone. Unlike domain goals whose satisfaction may involve multiple actors, a machine requirement has to be satisfied by the machine alone, without relying on any assumption about other actors in the world. For example, the goals G1 and G2 cannot be machine requirements because the ground braking controller would not be able to satisfy the goals alone. In order to satisfy these goals, the ground braking controller relies notably on the correct behaviours of the wheels sensors. The requirements R1 however can be satisfied by the software controller alone. Even if the wheels sensors send incorrect information, the controller would still be able to satisfy R1.
The idea behind these two characteristics is that machine requirements must be implementable (at least in principle) without recourse to any additional information about the world.
The more precise formulation of these characteristics is that machine requirements must be realizable. Realizability is a more advanced concept that you can ignore if you’re reading this for the first time. An intuitive explanation is given below.
Synonyms
Synonyms for machine requirements are “software requirements” and “software specifications”. We will also sometimes simply write “requirements” to mean machine requirements. Many people also use the phrase “software specification” to mean the set of software requirements.
What constitutes a machine requirement depends on what is taken to be the machine. As mentioned in Section 2.4, we sometimes consider two nested machines: a system-level machine that contains a smaller software-level machine (see Figure 2.3). The terms “system requirements” and “software requirements” are then used to refer to machine requirements for the system-level and software-level machines, respectively.
Domain Assumptions
Domain assumptions are properties of the world that the software development team can rely when designing the machine. Labelling a property as a domain assumption also means that the development team does not need to satisfy that property within the Machine.
What constitutes a domain assumption is relative to the machine. An assumption for a team developing one machine may be a requirement for a team developing another machine.
Examples
Examples of assumptions for the airline braking safety controller are:
(D1) If the plane is moving on the runway, then its wheels are turning.
MovingOnRunway=>WheelsTurning
(D2) If the plane wheels are turning, then the wheels sensors indicate that the wheels are turning.
WheelsTurning=>WheelsPulsesOn
The assumption D1 can be viewed as an assumed property of nature; assumption D2 as an assumption on the behaviour of the wheels sensors.
Grammar
In natural language, domain assumptions are usually expressed using verbs in the indicative mood, a grammatical mood used to state facts and beliefs. For example, “If the plane is moving on the runway, then its wheels are turning”. This contrasts with domain goals and machine requirements that are expressed in the optative mood, using modal verbs like “must”, “should”, or “shall”.
However, domain assumptions that express expected behaviours of a world actor are typically written in the optative mood. For example, “After landing, the pilot must press the ground braking button to deploy the ground spoilers and reverse thrust”.
Synonyms
Common synonyms for domain assumptions are “domain properties”, “domain knowledge”, and “environment assumptions”.
Not all assumptions in software engineering are domain assumptions. Software engineers commonly make assumptions about all sorts of things. For example, assumptions about how long it will take to complete a task, assumptions about the deployment infrastructure, assumptions about the capabilities of a programming framework, etc. These assumptions are important but they are not domain assumptions.
3.3 Requirements Correctness
In theoretical computer science, a program is correct if it satisfies its requirements. Program correctness is thus relative to a set of requirements. In the same way, requirements are correct if they satisfy their domain goals. Requirements correctness is thus relative to a set of domain goals.
The turnstile symbol \(\vdash\) denotes logical deduction and can be read as ‘therefore’ or ‘implies’. The canonical example of logical deduction is: “All men are mortal”, “Socrates is a man” \(\vdash\) (therefore) “Socrates is mortal”.
In this definition, stating that the domain assumptions must be valid means that they must be true in the world.
Another condition, not stated explicitly, is that the domain assumptions must be logically consistent with the machine requirements. You may remember from your logic classes that if they were inconsistent, any statement could be deduced from them (“Ex falso quodlibet” - “From falsehood, anything follows”), rendering the correctness formula meaningless.
Example
Let’s illustrate this definition on the requirements R1:
(R1) Ground braking must be enabled when the wheels sensors indicate that the wheels are turning.
WheelsPulsesOn=>GrdBrakingEnabled
We want to show that R1 is correct with respect to the goal G1:
(G1) Ground braking must be enabled when the plane is moving on the runway.
MovingOnRunway=>GrdBrakingEnabled
Our argument will use the two domain assumptions:
(D1) If the plane is moving on the runway, then its wheels are turning.
MovingOnRunway=>WheelsTurning
(D2) If the plane wheels are turning, then the wheels sensors indicate that the wheels are turning.
WheelsTurning=>WheelsPulsesOn
We can show that D1, D2, and R1 imply G1. The logical argument is as follows. Consider a situation where the plane is moving on the runway. If D1 is true, then the plane wheels are turning. If D2 is true, then the wheels sensor indicate that the wheels are turning. If the machine satisfies R1, then the ground spoilers and reverse thrust are enabled. Therefore, every time the plane is moving on the runway, the ground spoilers and reverse thrust will be enabled. In other words, G1 is satisfied.
Observe the role of the domain assumptions in this example. Without the domain assumptions, it would be impossible to prove that the requirement satisfy the goal. The domain assumptions allow us to bridge the gap between the shared phenomena of the machine requirements and the non-shared world phenomena of the domain goal.
Goal Modelling: A Preview
In practice, the relation between machine requirements, domain assumptions and domain goals can be shown in a goal model. For example, Figure 3.3 shows the goal model corresponding to the previous example.
In this figure, the black dot denotes a goal refinement. The lines from D1, D2 and R1 to the black dot and from the black dot to G1 mean that the conjunction of R1, D1 and D2 imply G1. In other words, if R1, D1 and D2 are true, then G1 will necessarily be true.
Goal models will be explained in Chapter 19. The purpose of Figure 3.3 is to give you an idea of how the correctness formula is applied in practice. When modelling large systems, a goals model can include hundreds or thousands of goals and requirements. A goal model typically involves multiple levels of refinements from goals to subgoals, and eventually from subgoals to requirements. Goals and requirements are often more complex than in this simple example. In practice, not all domain assumptions are recorded explicitly, few goals (if any) are defined formally, and few refinements (if any) are formally proved to be correct. Despite this—or perhaps thanks to this—goal models are extremely useful for structuring, analysing, and evolving requirements for complex systems.
3.4 Implications for Practice
The theory has direct applications on specific requirements engineering methods and wider indirect implications for all requirements engineering practices.
Direct Applications
A few requirements engineering methods–notably the Problem Frames approach and the KAOS goal-oriented requirements engineering method–are based directly on this theory.
In these methods, requirements engineering includes three intertwined steps:
identify, formulate and agree on a set of domain goals (Goals),
identify valid domain assumptions (Dom),
formulate machine requirements (Req) such that Req, Dom \(\vdash\) Goals.
This is a highly simplified presentation. The methods include a range of techniques that support these steps, along with other important analyses that will be discussed later (Chapter 19). At the heart of such methods is the idea that requirements engineering involves the explicit formulation of domain goals and the gradual derivation of machine requirements from those goals, using domain assumptions.
Wider Implications
The theory also has practical implications that go beyond its direct applications in specific methods; its ideas apply to all requirements engineering methods.
Here, we discuss the three most important:
The importance of stakeholder goals. The purpose of the machine is to support the satisfaction of stakeholder goals. These goals exist independently of the machine and refer to world phenomena not shared with the machine. Understanding the stakeholders’ real goals is essential, because ultimately the quality of the machine is determined by the extent to which it satisfies those goals. Many requirements engineering methods, however, focus almost entirely on understanding the desired properties of the machine at its interface with the world–for example, in terms of use cases or user stories–with little attention to stakeholder goals beyond the machine requirements. To ensure such goals are not overlooked, methods that focus solely on interaction with the machine must be combined with others–such as goal modelling or impact mapping–that analyse domain goals more explicitly. We describe these methods in Chapter 13 and Chapter 19.
The role and importance of domain assumptions. Domain assumptions play a critical role in software development: they are necessary to bridge the gap between stakeholder goals and machine requirements. As we will see in Chapter 4, critical failures are often caused by invalid domain assumptions. Effective requirements engineering therefore demands a critical examination of domain assumptions. However, few requirements engineering methods pay explicit attention to domain assumptions. One exception is the use of goal modelling and obstacle analysis to systematically record and challenge all assumptions made in the definition of machine requirements. We briefly illustrate this method in Chapter 4 and describe it in more detail in Chapter 13 and Chapter 19.
The nature of machine requirements. Traditionally, the difference between requirements and implementation was explained by stating that a requirement should specify what the software must do, but not how it must do it. However, the distinction between what and how was never entirely clear. The modern view—-based on the theory presented in this chapter—-is that the difference between requirements and implementation is not about what versus how, but rather about where: requirements refer to phenomena at the interface between the world and the machine, while implementations refer to phenomena inside the machine. Machine requirements are the desired properties of the machine as seen from the outside, i.e. from the world. This is also the idea behind use cases and user stories: to describe the software’s functionalities from the users’ perspective. For many software engineers, describing the machine as seen from the world does not come naturally.
It requires a radical shift in perspective from our habitual way of thinking about software from the inside, in terms of lines of code, implementation frameworks, and technologies. We must temporarily suspend this way of thinking in order to consider software behaviours as they appear from the world.
3.5 Beyond the Theory
The theory presented here is not a complete theory of requirements engineering. It describes an ideal end product of requirements engineering — the formulation of goals, requirements, and assumptions — and deliberately ignores the real-world processes that help us move towards this ideal. Many important aspects of requirements engineering are therefore left out:
Knowing when Requirements are Good Enough. For any real system, it is impossible to identify all stakeholder goals and define machine requirements and domain assumptions in such a way that Dom, Req \(\vdash\) Goals can be proven. The theory defines an ideal we can aspire to, but never fully achieve. In practice, we must decide when our understanding of goals, requirements and assumptions is good enough. The theory does not address such decisions.
Managing Conflicts. Stakeholder goals are often conflicting. The theory does not address such conflicts. The correctness formula starts from a situation in which conflict-free domain goals have already been agreed upon. In practice, identifying conflicts and finding suitable tradeoffs are crucial aspects of the requirements engineering process.
Exploring Alternatives. Requirements engineering involves exploring alternative ways to satisfy stakeholder goals. Each alternative corresponds to a different set of machine requirements and domain assumptions. The theory does not address how to represent these alternatives, evaluate them, and select a preferred one.
Dealing with Partial Goal Satisfaction. Many stakeholder goals cannot be satisfied in an absolute sense. Often, we are interested in how well a goal is satisfied, rather than whether it is satisfied completely or not at all. This is particularly true for goals related to safety, security, privacy, performance, and other “non-functional” properties. The theory’s framing in classical logic suggests that goal satisfaction is all-or-nothing; it does not address how to describe and analyse degrees of goal satisfaction — an essential concern in practice.
Dealing with Uncertainty. Requirements engineers face many uncertainties – notably about stakeholder goals and their relative importance, the validity of domain assumptions, and the impacts of design decisions on those goals. The theory in this chapter does not address how to capture and analyse such uncertainties.
Implementation Constraints. Requirements engineering must account for technological, budget and time constraints – all of which are ignored by this theory.
We will describe various ways to deal with these concerns in future chapters. Some of them, however, remain important open research problems. The question of knowing when our understanding of requirements is “good enough” is perhaps the most important – and the most difficult – to resolve.
3.6 Notes and Further Readings
The theory of requirements engineering is based on the work of Pamela Zave and Michael Jackson. The main publications are referenced at the end of the previous chapter (Chapter 2).
Similar ideas were developed around the same time and presented a slightly different form in Axel van Lamsweerde work on the KAOS goal-oriented requirements engineering method (Lamsweerde 2008, 2009). I contributed to this work for my PhD thesis (Letier 2001). Formal definitions of realizability in requirements engineering can be found in my papers (Letier and Van Lamsweerde 2002; Letier and Heaven 2013).
As noted earlier, this theory of requirements engineering forms the foundation of several requirements engineering methods: the Problem Frames approach (Jackson 2001), the KAOS goal-oriented requirements engineering method (Lamsweerde 2009), and the REVEAL method used at Praxis Critical Systems (Hammond, Rawlings, and Hall 2001; Hall 2010).
Our terminology differs slightly from that used in Zave and Jackson’s papers and in KAOS. The following table explains the correspondence:
| This book | Zave and Jackson | KAOS |
|---|---|---|
| Domain goal | Requirement | Goal |
| Machine requirement | Specification | Requirement |
| Domain assumption | Domain knowledge | Assumption or Expectation |
Our definitions also differ slightly from earlier ones.
Zave and Jackson’s definitions refer to grammatical moods: requirements and specifications are statements in the optative mood; domain knowledge consists of statements in the indicative mood.
In KAOS, the definitions refer to whether a statement is prescriptive or descriptive: a goal is defined as a prescriptive statement whose satisfaction may require the cooperation of multiple actors; a requirement as a prescriptive statement to be satisfied by the machine alone; an expectation as a prescriptive statement to be satisfied by actors other than the machine; and an assumption as a descriptive statement about the world. Our definitions are similar in meaning, with the minor difference that we refer to goals as desired rather than prescribed.
A more important difference is that we do not define goals, requirements, and assumptions as statements, but rather as abstract properties that may or may not be stated explicitly. Goals, requirements and assumptions are properties that exist in people’s minds. They exist even if they are not formulated as explicit statements. A single goal could be stated in multiple ways; some ways can be more precise than others. The same goal could also be expressed in multiple languages, for example when a project involves stakeholders speaking different languages.
Despite these differences, the core ideas of what constitute domain goals, machine requirements, and domain assumptions remain the same.
3.7 Review Questions
…