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 live.
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 characterize requirements engineering as it is practised today.
Let’s briefly look at each of these ideas in turn. We will cover them in more details in the following chapters.
Requirements engineering is 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. Discovering requirements does not stop when coding begins. Any activity related to understanding the software requirements is considered to be part of requirements engineering, no matter when that activity occurs. Requirements engineering activities are of many different kinds: they involve discovering, analysing and communicating. They are not limited to interviews and documentation. An important point is that software engineers are active participants in these activities, they are not merely passive recipients of information transmitted by others.
Stakeholder needs. The stakeholders are all people who have an interest in, or will be affected by the software. They are people whose lives will be touched by the code we write. 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, if you travel by plane, you are a stakeholder of the many software systems that are used to control the plane, maintain airspace safety, handle luggages at the airport, etc. Authorities who regulate and oversee air travel are other stakeholders. The stakeholder needs, also called stakeholder goals, are all the wishes and expectations that people have about the impacts of the software on their lives, work, or business. For example, plane passengers want to arrive at destination safely, on time, and with their checked-in luggages intact. Ultimately, the quality of a software system is judged not by looking at the code, but by evaluating whether it satisfies its stakeholder needs. Understanding stakeholder needs is therefore essential for producing high-quality software.
Context. The context is the physical, digital and social worlds that surround the software. It includes people, external devices and other software systems. It also includes work processes that the software must support. The context is also called “the environment” or “the application domain”. Stakeholder needs can usually not be satisfied by the software alone; people, external devices, and other software systems in the context have to play their roles too. For example, pilots, air traffic controllers, and baggage handlers all play important roles in bringing passengers and luggages safely to destination. Understanding the context is essential to deliver software that is appropriate for that context. We will later see that many errors in software development are caused by misunderstanding the context.
Externally visible behaviours and qualities. The externally visible behaviours and qualities that the software must possess are its functional and quality requirements. The software functional requirements are its desired externally visible behaviours; the software quality requirements are its desired externally visible “non-functional” characteristics like performance, reliability, availability, security and ease of evolution. Every software has requirements: the requirements exist even if they are not clearly written down, understood, and communicated. The software requirements are properties that the software must possess to satisfy the stakeholder needs in the context of use. This important relation between software requirements, stakeholder needs and context will be described in more details 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 first implementation of the software and, if the software is used, they will happen throughout its evolution. For software systems that are 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 on two examples: an airplane braking system and an ambulance despatching 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 is dangerous and would likely cause the plane to crash. Airplanes therefore have 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 satisfy the first 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 seconds 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, that if the two conditions in FR1 are false, then the plane is not moving on the runway— to establish that if the software satisfy 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 components 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 a 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 prompts 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 that requirements are related to many stakeholder needs, assumptions about the context, test cases, and software code, managing changes across multiple variants and versions is a complex information management problem.
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 mobilization instructions to the ambulance paramedics.
Stakeholder Needs
The main stakeholder need is that ambulance should arrive quickly in response to emergency calls from the public.
Context
In order to implement an ambulance dispatch software, 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 nearest available ambulances to send 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 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 well-known in the requirements engineering community because they are examples of 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 details 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 started to take longer to arrive at incident scenes. In many cases, it would take hours instead of minutes for an ambulance 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 more details in the following chapters.
Analysing failures is a common engineering practices: it allows engineers to understand what went wrong and to draw lessons to avoid repeating the same mistakes. Failure stories are also useful pedagogical tools: they help transmit experience and ideas through vivid and memorable scenarios. You will see in later chapters and through exercises that, although these two failures happened more than 30 years old, the lessons we can draw from them are still highly relevant today.
1.3 Common Misconceptions
There are a few common misconceptions about requirements engineering that you are likely to encounter during your studies or when working with clients, stakeholders and other software engineers. You need to be able to recognise 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 of software engineering, 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, analyze, and communicate requirements iteratively and continuously throughout the software development process.
Furthermore, requirements engineering is not neatly separated from design, coding and testing. It is also not the sole responsibility of people with the title of “requirements engineers”, “business analysts” or “product owners”. 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 engaged in requirements engineering activities: 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 can be seen as being part of requirements engineering, no matter when that activity is performed and by whom. This is important because being able to recognize when a task you are working on involves some requirements engineering will help you select the right 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. You can observe this misconception at work in projects where requirements engineering is limited to creating a prioritized list of items that can take the form of 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 prioritization 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 level of clarity and precision that is 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.
This point can be illustrated by an analogy between requirements engineering and the work of restaurant waiters and medical doctors. The idea that requirements engineering is about asking people what they want sees requirements engineering as nearly equivalent to taking orders in a restaurant: ask people what they want, write it down, and pass the orders to the kitchen. This is not a useful model of software development. In practice, requirements engineering has more similarities to the work of medical doctors. 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 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. It’s not just about asking 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 minimizing risks, respectively.
The phrase that “stakeholders are people whose lives we touch” is attributed to Marc McNeill by Dan North in an opinion piece about testing (North 2021). Stakeholders are important in testing too.
The airline braking system was first used to explain requirements engineering ideas by Michael Jackson in his keynote at the International Conference on Software Engineering in 1995 (Jackson 1995b) and in his book published the same year (Jackson 1995a). We will study key ideas from that keynote and book in the next two chapters. The Ambulance Despatching 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?