1 What is Requirements Engineering?
This chapter introduces requirements engineering with a working definition and two real-world examples. It also discusses common misconceptions that you are likely to encounter in your studies and professional life.
1.1 A Working Definition
Requirements engineering is a broad and evolving discipline that cannot be reduced to a single definition. Our working definition is a starting point. It emphasises six important ideas (shown in bold) that characterise requirements engineering as it is practised today.
Let’s briefly look at each of these ideas. We will examine them in more detail in the following chapters.
A set of activities. We define requirements engineering as a set of activities, not as the first phase of development. Requirements activities can occur at any time in the software development process; they do not stop when coding begins. These activities include discovery, analysis, and communication; they are not limited to interviews and writing documents or user stories. Software engineers play an active role in these activities; they are not just passive recipients of information provided by others.
Stakeholder needs. The stakeholders are all the people who have an interest in, or will be affected by the software. This usually includes many more people than the client (the person who pays for development) and the users (the persons who operate the software). For example, plane passengers are stakeholders of the many software systems used to control planes, maintain airspace safety, handle luggage at the airport, etc. The stakeholder needs are all the wishes and expectations that people have about the software’s impacts on their lives, work, or business. For example, plane passengers want to arrive at their destination safely, on time, and with their checked-in luggage intact. Ultimately, the quality of a software system is determined by the extent to which it meets its stakeholders’ needs. Understanding these needs is therefore essential for producing high-quality software. Stakeholder needs are also called “business goals”, “customer requirements”, “user needs”, and “stakeholder goals”, among others.
Context. The context is the physical, digital and social world surrounding the software. It includes people, external devices and other software systems. It also includes the work processes that the software must support. The context is also called “the environment” or “the application domain”. Stakeholder needs cannot usually be met by the software alone: people, external devices, and other software systems also have to play a role. For example, pilots, air traffic controllers, and baggage handlers all play important roles in bringing passengers and luggage safely to their destinations. Understanding the context is essential to delivering software that is appropriate for its context. We will later see that many errors in software development are caused by misunderstanding the context.
Software requirements. Software requirements are desired, externally visible behaviours and qualities of the software. The desired behaviours are called “functional requirements”; the desired qualities are “non-functional” requirements such as performance, reliability, availability, security and ease of evolution. Every software has requirements: the requirements exist even if they are not written down, fully understood, or communicated clearly. Software requirements are properties that the software must possess in order to satisfy stakeholder needs in a specific context. This relation between software requirements, stakeholder needs, and context is one of the most important ideas in requirements engineering. We will illustrate it on two examples below and describe it in full detail in Chapter 3.
Tradeoffs. Stakeholder needs are often conflicting: satisfying some stakeholder needs may interfere with the satisfaction of some other needs. Some stakeholder needs may also be impossible to achieve with existing technologies or within the available time and budget. Therefore, a significant part of requirements engineering involves finding suitable tradeoffs between conflicting needs and between what people want and what is possible to achieve given the technological, budget and time constraints.
Managing changes. Finally, requirements engineering involves managing changes to stakeholder needs, the context, and the desired software behaviours and qualities. These changes happen throughout the whole life of the software. They can happen before and during the software’s first implementation, and if the software is used, they will happen throughout its evolution. When a software system is part of a product family, requirements engineering also involves managing changes across multiple software variants that account for differences between market segments, individual clients, and deployment environments.
1.2 Two Examples
Let’s illustrate these ideas with two examples: an airplane braking system and an ambulance dispatching system. We will continue to use these examples in the next two chapters and other parts of the book.
An Airplane Ground Braking System
The ground braking system of an airplane is composed of three elements: the ground spoilers, the reverse thrust, and the wheels brakes. The ground spoilers are panels on the plane wings that deploy after landing to increase drag and slow down the plane. Reverse thrust consists in reversing the engines’ thrust to slow the plane down as quickly as possible after landing. Activating the ground spoilers and reverse thrust during flight would be dangerous as it could cause the plane to crash. To prevent such accident, airplanes are equipped with a ground braking software controller whose purpose is to ensure that the ground spoilers and reverse thrust are never activated during flight.
Stakeholder Needs
This software controller has two main stakeholder needs:
- The ground spoilers and reverse thrust should not be activated during flight.
- Pilots must be able to activate the ground spoilers and reverse thrust immediately after the plane has landed.
The first need is about ensuring the plane safety during flight; the second is about safety during landing. If the pilot is not able to activate the ground spoilers and reverse thrust quickly after landing, the plane may crash at the end of the runway.
Context
In order to implement a software controller that satisfies these two needs, we must understand the context in which the software will be used. The context in this example is composed of the plane, the pilots, the motors used to control the ground spoilers and engine thrust, and sensors on the landing gears that measure the wheels speed and the compression on the shock absorbers. Information from these sensors can help us determine whether the plane has landed or not: if the wheels are turning and the shock absorbers are compressed, then the plane has landed.
Software Requirements
The software requirements are the desired behaviour and qualities that the ground braking software controller must possess in order to satisfy the stakeholder needs. An example of functional requirement is:
[FR1] The ground braking system must be enabled when, and only when, at least one of the following conditions is met:
- the wheel speed is above 72 knots at both main landing gears,
- the shock absorbers are compressed at both main landing gears.
An example of quality requirements is:
[QR1] The likelihood that the ground braking system is not enabled within 1 second after one of the conditions defined in FR1 is true must be less than 1 per 109.
The reasoning behind these requirements is that if at least one of the two conditions in FR1 is true, then the plane has landed, and it is therefore safe to activate the ground spoilers and reverse thrust. However, if both conditions in FR1 are false, then the plane is not moving on the runway, and therefore the ground spoilers and reverse thrust should not be enabled. Note how this reasoning use knowledge about the context — for example: if the two conditions in FR1 are false, then the plane is not moving on the runway— to establish that if the software satisfies the requirements, then the stakeholder needs will be met.
Tradeoffs
Defining requirements for the ground braking software controller involves tradeoffs between the two stakeholder needs. Installing a software that disables the braking system during flight creates risks that, due to some malfunction, the software incorrectly prevents activation of the braking system during landing. Increasing safety during flight therefore reduces safety during landing. Vice-versa, increasing safety during landing may reduce safety during flight: if the conditions to enable the ground braking system are too permissive, the ground spoilers and reverse thrust could inadvertently (or maliciously) be activated during flight.
The problem is exacerbated by the possibility of component failures. For example, one or more of the landing gear sensors may fail to function correctly. Having to deal with potential failures adds much complexity to the software requirements. Once you take failures into account, finding suitable tradeoffs between safety during flight and safety during landing becomes a difficult problem that requires careful analysis.
Many of these tradeoffs will be made by systems engineers with expertise in aerospace rather than by software engineers. Close collaboration between systems engineers and software engineers is however crucial to ensure that the stakeholder needs, potential failures, and tradeoffs have been thoroughly analysed and are understood by all.
Managing Changes
Designing the braking safety controller also involves dealing with changes. Requirements changes may be triggered by changes in the context such as changes in the system’s sensors and actuators. Changes may also be triggered by specific incidents or accidents that prompt us to revise the system requirements, to install new components, and perhaps to change priorities between safety during flight and during landing.
Managing changes may also involve designing multiple variants of the braking safety controller to be installed in different types of airplanes with different physical components, or changing the behaviour of the braking safety controller in order to satisfy specific regulations in different regions of the world.
The requirements for the software controller will thus have multiple variants (changes in the product family) and multiple versions (changes over time). Because a typical software system for an aircraft will have hundreds or thousands of requirements and those requirements are related to many stakeholder needs, assumptions about the context, test cases, and code files, managing changes across multiple variants and versions is a complex information management problem. A single change often triggers many other changes to other requirements, test cases, and source code. Each of these changes may have multiple consequences that must be carefully analysed.
An Ambulance Dispatching Software
Let’s look at a second example. An ambulance dispatching software is a software that helps ambulance services take emergency calls from the public, decide what ambulances to send in response to a call, and communicate the mobilisation instructions to the ambulance paramedics.
Stakeholder Needs
The main stakeholder need is that ambulances should arrive quickly in response to emergency calls from the public.
Context
To implement an ambulance dispatch software satisfying this need, we need to understand the context in which the software operates. In this example, the context is composed of the public making emergency calls, the ambulance service staff answering the calls, the ambulance crew who respond to the incident, the city traffic that ambulances must navigate through, and the communication infrastructure used to locate ambulances and to communicate with ambulance crews.
Software Requirements
Defining requirements for this system involves defining software features that will help to satisfy the stakeholder needs. Examples of such features are:
- on-screen call-taking,
- automated caller location detection,
- identification of duplicate calls,
- automatic vehicle location through GPS,
- identification of the nearest available ambulances to an incident,
- communication of mobilisation orders through mobile data terminals in ambulances,
- maintaining information about ambulance status (e.g. whether they are available for mobilisation) from messages received from mobile data terminals.
The software requirements are the precise desired behaviours and qualities of each feature.
To satisfy the stakeholder needs, the software features and their requirements rely on many assumptions about the context. For example, they assume that the public can give correct information about the incident locations, that the call handlers encode the correct information in the ambulance dispatch software, that the GPS provides accurate information about ambulance locations, that ambulance crew will drive the ambulance to their assigned incident location, etc. As we will see later, these seemingly harmless assumptions are often where software engineers make mistakes.
Learning from Failures
The airplane braking system and ambulance dispatch software are classic examples in the requirements engineering literature because they are two systems where requirements errors contributed to major accidents and failures.
The first is the crash of an Airbus during landing at Warsaw airport in 1993. One of the main causes of the crash was that the software prevented the pilot from deploying the braking system for 9 seconds after landing. The software implementation was correct, but its requirements were wrong. We will study this example in more detail in the next two chapters.
The second is the failure of the London Ambulance Service in 1992. Soon after the new ambulance dispatching software was installed, ambulances gradually took longer to arrive at incident scenes. Many ambulances would take hours instead of minutes to arrive. The problems were mostly due to inadequate requirements. The software had been developed based on incorrect assumptions about the context in which it would be used. We will also study this example in detail in the following chapters.
Analysing past failures is a standard engineering practice: it allows us to learn from mistakes and improve our ways of working. Discussing past failures is also an important educational tool that helps us transmit knowledge through vivid and memorable examples. Although these two failures happened more than 30 years ago, we will see in later chapters that the lessons we can learn from them are still highly relevant today.
1.3 Common Misconceptions
There are common misconceptions about requirements engineering that you will almost certainly encounter when talking to clients, stakeholders and other software engineers. It is important that you are able to recognise these misconceptions and address them.
Not the first phase of development
The first misconception is to believe that requirements engineering is the first phase of development. This is how requirements engineering was defined in the past. The idea comes from the waterfall development process where, in theory, all requirements are defined at the beginning of the project before starting to design and implement the software. This rarely works in practice. For over 50 years, we have seen that software requirements can rarely, if ever, be fully identified at the start of a project. Expecting software requirements to be defined entirely at the start of a project is a bad idea. Today, most software systems are developed incrementally. We discover, analyse, and communicate requirements iteratively and continuously throughout the software development process. The early discovery of requirements is important but not sufficient.
Requirements engineering is also not entirely separated from design, coding, and testing activities. The responsibility for understanding requirements is not limited to people with the title of requirements engineer, business analyst, or product owner. Everyone in a development team is involved. For example, if you are a developer implementing some feature and you are trying to understand exactly how the feature is supposed to behave under some specific condition, you are dealing with a requirements engineering problem: you need to think about the stakeholder needs and the context in which the feature will be used in order to decide what its behaviour should be. Any activity related to understanding what should be implemented is part of requirements engineering, no matter when that activity is performed and by whom. This is important because recognising that a task you are working on involves some requirements engineering work will help you select the right tools and techniques for the job.
More than asking people what they want
The second common misconception is to believe that requirements engineering consists in asking people what they want, writing it down, and passing the information to the development team. This misconception can be observed in projects where requirements engineering is limited to creating a prioritised list of items (usually, the items are either user stories, use cases, “shall” statements, or features). Priorities often consist of simple labels such as ‘High’, ‘Medium’, ‘Low’, or ‘Must’, ‘Should’, ‘Could’, ‘Won’t’ (the MoSCOW prioritisation technique). This approach does not work well because people do not know what they want, and without the help of a skilled requirements engineer, they cannot communicate their needs with the clarity and precision required for software development. Requirements engineering involves more than asking people what they want. It involves clarifying what problems need solving, investigating the causes of the problems, exploring alternative solutions to the problems, making complex decisions that require tradeoffs between competing needs, and being able to communicate software requirements with precision and clarity.
One way to explain this point is by analogy.
Requirements engineering is not like taking orders in a restaurant: ask customers what they want, write it down, and pass the note to the kitchen where the software will be prepared. This is not how successful software are created.
Another approach is to think of requirements engineering as similar to the work of a medical doctor. Good doctors listen to their patients, investigate the root causes of their problems, and may sometimes require additional analysis or consult other specialists; they then discuss the best treatment options with their patients and explain tradeoffs. They then write a precise treatment plan for the patient and the medical team. What doctors prescribe may be different from what the patient initially asked for. During treatment, patient progress is monitored, and the treatment plan may be revised. Patients visit doctors because doctors have expertise in diagnosing and addressing health problems. In the same way, good requirements engineers have expertise in diagnosing and addressing problems that may require a software solution. Like medical doctors, they listen to people, investigate the root causes of their problems, consider tradeoffs, and help them identify solutions that will address their needs. They will also be able to write the “prescription” (the software requirements) with suitable precision and clarity for the subsequent coding and testing tasks. Skilled requirements engineers do much more than simply ask people what they want.
1.4 Notes and Further Reading
Our working definition is based on and adapted from earlier definitions by Pamela Zave (Zave 1997) and Steve Easterbook (Easterbrook 2006). A good overview of requirements engineering can be found in Steve Easterbook and Bashar Nuseibeh’s 2000 roadmap paper (Nuseibeh and Easterbrook 2000). A more detailed introduction can be found in the first chapter of Axel van Lamsweerde’s book (Lamsweerde 2009). Other definitions of requirements engineering can be found in the ISO/IEC/IEEE International Standard on requirements engineering (IEEE 2018) and in the International Requirements Engineering Board glossary (Glinz 2020). They emphasise other aspects of requirements engineering, such as client-supplier relations and minimising risks, respectively.
Michael Jackson first used the airline braking system to explain requirements engineering ideas in his keynote at the International Conference on Software Engineering in 1995 (Jackson 1995b) and in his book published the same year (Jackson 1995a). The next two chapters will study key ideas from that keynote and book. The ambulance dispatching system was introduced as a case study for the software engineering community by Anthony Finkelstein and John Dowell (Finkelstein and Dowell 1996). More details about both systems will be given in the next three chapters.
1.5 Review Questions
Let’s review the main points in this chapter with a series of “True or False” questions.
Question 1.1
Which of the following statements are true, which are false?