The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to email@example.com from the e-mail address which you have registered with.
Developing a software system is a challenging task for all participants including stakeholders, requirements engineers, project managers, architects, developers etc. Advances in technology, such as the Internet or mobile communication, make new abilities and functionalities of future software systems possible. In this process, the complexity of new software systems and the complexity of their development including requirements engineering will also increase.
Despite every technological advance there is one factor, which is unchanged in software and especially in requirements engineering: the essential and creative part of the engineering work has to be performed by humans. Together with the requirements engineers, the stakeholders create or define the requirements and thereby the software system. Therefore, all aspects of the system have to be understood and processed by the human mind (of stakeholders and requirements engineers).
You may say that the involvement of the human mind is more than obvious. You are right. However, do you think that there is a connection between the limitations or abilities of the human mind and successful requirements engineering? I think this is a very difficult question that I want to discuss in this article. For now, let us put this question aside, and let’s have a look at some results from cognitive psychology.
Before reading on, please ask yourself the following question:
What do you know about the limitations and abilities of the human mind?
Most people know something about the limitations of our short-term memory: 7 +/- 2 information units can be stored in our short-term memory. This number is a result from Georg A. Miller and has been presented in 1956 . He further showed that the structure of the information unit is very important for the short-term memory. For example, it is more difficult to memorize “FB INAS AUS AE UC NN” than “FBI NASA USA EU CNN”. Also common in requirements engineering is the work of Bandler and Grindler on natural language and transformational effects presented in 1975 .
In the following, I will present more recent results from cognitive psychology on the human mind that I found very interesting.
Daniel Kahneman presents a model of the mind that consists of two systems :
Kahneman illustrates the differences and the power of both systems with two very simple problems:
Observe yourself while thinking about the two problems. The answer to Problem 1) comes more or less immediately to your mind: 17 x 24 cannot be equal to 123 or 12.609. However, solving Problem 2) is much harder. You have to compute 17 x 24 to see that it is not 568 (it is 408 by the way). Both problems have the same structure (mathematical question). Yet, Problem 1) appears to be much easier to solve than Problem 2). Problem 1) is solved automatically by our System 1. Problem 2) is solved by System 2 and requires mental effort.
Kahneman  presents another interesting problem that is directly related to System 1 and System 2. Do not try to solve it, just read it and listen to your intuition:
A bat and a ball together cost $1.10.
The bat costs one dollar more than the ball.
How much does the ball cost?
Without any mental effort, a number comes to your mind: 10, for 10 Cent. System 1 produces this number. Although the number is very appealing, it is unfortunately wrong. Do the math and see yourself . Kahnemann’s point is that System 2 is lazy and often accepts results from System 1 that seem to be correct but are in fact wrong!
You might say that this experiment has nothing to do with requirements engineering practice or even with successful requirements engineering. I am not convinced of this. In a recent project, I observed a situation similar to the bat-and-ball-problem. A stakeholder formulated a requirement like the following in a workshop:
An order with a volume above one million Euro has to be approved by two department managers.
Everybody in the room agreed instantly and the discussion continued with another topic. A few minutes later, I asked a question related to the requirement presented above:
What happens if the order is above one million and a department manager has initiated the order? Is it still necessary to approve the order by two department managers?
This question initiated a lively debate on the approval of orders that lasted for more than an hour. The interesting thing in my point of view was that the discussion was not initiated by the requirement itself. Every participant seemed to have accepted the requirement without questioning it because it appeared to be very precise (result of System 1). Nobody seemed to think about the other cases that were not covered by the requirement (this would require System 2). My question pointed at these implicit cases (which activated the participant’s System 2) and initiated the discussion.
I further have seen people who could tell you within seconds that a specific specification concept (e.g. a data model) is not correct or at least not the best solution (I think this is very similar to recognizing that 17 x 24 is not equal to 123).
Kahneman says that such mental capabilities originate from a very specific training and understanding of the subject matter. The book Blink by Malcolm Gladwell  presents quite similar results and gives a great overview of outstanding mental capabilities.
My feeling is that process models or templates  for requirements are important for project organisation but not that important for project success. I believe that successful projects rely on effective people, and people become effective if they utilize the abilities of their mind. Kahnemann’s and Gladwell’s books both state that an effective mind requires specific training and/or an essential understanding of the subject matter.
In the following, I want to present some thoughts around the term ‘requirement’ that changed my understanding of the essence of requirements engineering. This understanding improved my daily work as requirements engineer in the way Kahneman describes in his book.
I want to start with our essential subject matter and outcome: requirements. Requirements engineers produce documents or specifications full of requirements (and other information). But what is this thing called requirement?
The IEEE 610.12 Standard defines a requirement as follows :
At a first glance, this definition sounds like a typical and mostly harmless academic definition. It seems to be a bit clumsy, but especially the first sentence is not that harmless. Let us have a more detailed look at this sentence.
a) It says that a requirement is a condition or capability. Conditions or capabilities are statements related to something. Therefore, a requirement is not an independent statement. Instead, it is related to something, typically the system (see second sentence) that has to be developed (I call this the solution).
b) A requirement is needed by a user (you could also say stakeholder) to solve a problem or to achieve an objective. This means that a requirement is always preceded by a problem that has to be solved (or an objective that has to be achieved). This means, that the problems must have existed before the requirement is formulated or even comes to existence.
Now let us put a) and b) together. The result is that you need three types of information to formulate a requirement according to IREB’s definition: the problem, the solution (the thing that will have the condition or capability), and the condition or capability itself.
This means that it is impossible to formulate a requirement without knowing a problem that has to be solved and a solution (the thing which is referred by the condition or capability of the requirement). You could also say, a requirement depends on a problem and a solution. A requirement depends on a solution? Should it not be the opposite way? A solution is realised based on the requirements? Yes, but the definition says that a requirement requires a decision for a specific solution, since the requirements describe the conditions or capabilities of this solution. Therefore, the decision for a particular solution must have an impact on the requirements.
The previous statements appear rather philosophical and seem not to be related to practice. My personal experience shows exactly the opposite. I want to illustrate the practical importance of these statements with a practical example.
Assume that we are working for a car manufacturer. The problem that we want to solve is defined as follows:
Warn the driver in case of low tyre pressure
The solution that almost instantly comes to mind is quite easy (remember Kahnemann’s System 1): We install pressure sensors into every tyre and monitor the sensors. A requirements specification for such a system might contain the following requirements:
This list of requirements does not appear to be very special. However, the solution (measure the pressure) somehow occurs in every requirement.
I argued above that the solution has a great impact on the requirements. Therefore, we will now try a different solution for our tyre pressure problem. A different solution for detecting low tyre pressure? Yes, we are going to exploit the fact that a reduced tyre pressure will reduce the diameter of the tyre . And, a reduced tyre diameter will lead to an increased rotation of the tyre compared to other tyres. A requirements specification for such a system might contain the following requirements:
Again, the resulting requirements look like usual requirements. Nevertheless, all three requirements are completely different from the requirements for the pressure sensor solution presented above. This very simple example shows that a change of the solution will lead to a completely different set of requirements.
What can we learn from this example? First of all, we have three essential concepts in requirements engineering: problems, requirements, and solutions. They are related to each other as follows (see arrows in Figure 1). The solution is obviously related to the problem it solves (arrow from S to R). Requirements are related to problems and solutions (arrows from R to P and S). Only the problem is an independent entity (no arrow is starting at P). This means that only problems can be discussed independently.
The explicit separation between problem and solution is a common principle in requirements engineering . The extension of this dualistic principle with the concept of requirement allows for a more precise understanding of the word requirement. It even defines a seal of quality that says that a statement is a requirement only if the statement defines a condition or capability that is related to a problem and a solution.
We no longer say that a stakeholder formulates a requirement. Now we can say that a stakeholder formulates a statement with the quality of a requirement since we have an easy tool to determine whether a statement is a requirement or not: We ask for the condition or capability, and the related problem and solution. I will show the application of this tool later with the tyre pressure example.
We have intensively discussed the meaning of the term ‘requirement’ and we have used the terms ‘problem’ and ‘solution’ to define whether a statement can be called a requirement or not. However, something does not feel right, when we look at the terms ‘problem’ and ‘solution’.
Above, I cheated a bit and declared that the statement ‘Warn the driver in case of low tyre pressure’ is a problem. Is this statement really only a problem? No, it is not. You can ask: Why do we want to do this? For example, it could be the solution for the problem ‘reduce fuel consumption’, since an optimal tyre-pressure reduces the road resistance of the tyre and thereby improves the fuel consumption. You could even go further and say that the problem ‘reduce fuel consumption’ is also a solution for another problem, e.g. the problem ‘reduce total driving costs’.
You can of course look into the other direction. The other direction is challenged by how-questions. How do we do this? Assume we want to recognize low tyre pressure by monitoring the tyre rotation. How do we measure the tyre rotation? Here we are, we can of course call the statement ‘measure tyre rotation’ a problem. And you can of course say that every solution creates new problems.
I assume, you are a bit confused now, because the same statement is once a problem and once a solution. This is a situation that I call the problem-solution-dilemma. What has happened? This does not seem right. And without a precise understanding of problems and solutions, the above-presented definition of requirement is more or less worthless. So lets go on with a bit more philosophy and have a look into the meaning of the words problem and solution.
The problem-solution-dilemma originates from the fact that it is not possible to classify a statement as problem or solution without further information. First of all, you can always ask the why-question. For example, why do you want to ‘warn the driver in case of low tyre pressure’? The answer of this question is the preceding problem. For example, we want to do this because we ‘want to reduce fuel consumption’. And why do you want to do this? Because … you can go on with this forever.
We can do this forever because there is no logical beginning when looking in this direction. The beginning of this list of problem-solution pairs is a decision made by a human being. Someone decides that the statement ‘reduce total driving cost’ is important and therefore becomes our root problem.
What about the how-questions? Is there an end? Yes and no. The first and most important information is whether a statement means a solution to us or not. What does it mean?
Let us have a look at a simple example. Our problem is that we want to open a bottle of coke (or beer) with a crown cap. As a first solution, I will hand you a bottle opener. As long as you know what a bottle opener is, you will intuitively take it and open the bottle. Now, I hand you yesterday’s New York Times and tell you to open the bottle with the New York Times.
Unless you do not know the way to open a bottle with a sheet of paper, the statement ‘open the bottle with a sheet of paper’ is not a solution, but a real problem for you. Once you know the trick, it becomes a solution. And knowing the trick means that the statement ‘open the bottle with a sheet of paper’ triggers some additional knowledge in your mind (you could also say, your System 1 comes up with an approach that System 2 can execute) on how to open a bottle with a sheet of paper.
Computer scientists call this an abstraction, more specifically an abstraction that is hiding certain information . The knowledge of how to open a bottle with a sheet of paper is hidden behind the statement ‘open the bottle with a sheet of paper’ . In essence, this means that the decision whether a statement is a problem or a solution is a matter of choice and of your position in the abstraction hierarchy.
In fact, we are now far away from requirements engineering. So let us take the ideas on problems, solutions, requirements, and abstraction back into RE practice.
As requirements engineers, we are part of the development process of a software system. The IREB BOK says that every software system is embedded into a specific system context and that the system context is relevant for the understanding of the system’s requirements. Therefore, the system context is the place where we can find and decide our initial problems that the system shall solve in the system context.
This distinction between system and context defines a first and important boundary that IREB calls the system boundary. This system boundary is an essential mechanism for abstraction to discuss and understand problems, requirements and solutions on the level of the system context and on the level of the system. The system itself can even be subdivided again into a logical and a technical level. The logical level describes the intended system with logical elements and the technical level discusses real technical elements (data bases, technical data structures, etc.).
This explicit distinction between problems, requirements, and solutions on three levels of abstract (context, logical and technical) creates the structure presented in Figure 2 that I call the Problem-Abstraction-Level-Model (short PAL-Model). It appears again to be rather theoretical and philosophical. It may remind you of traditional approaches such as the waterfall model. With this concept, I do not have any development processes in mind. I think about the mind when I talk about this. This step of understanding the underlying problems that a new system shall solve is, from industrial experience, a crucial success factor for every software project.
Here again is a small experiment. Just read the following text and observe your thoughts:
|1 + 1 = ?||2 x 3 = ?||1, 2, 4, 8, 16, ?|
I assume that you instantly start solving the problems without having the task to do so. Remember, above I only asked you to read the line. Why is that so? Kahneman says that our System 1 is at work in these moments and offering us a solution to the very easy tasks. However, we also discussed the bat-and-ball-problem. It was an example that our System 1 is not always right.
I think that the structure from Figure 2 helps to structure our thoughts when thinking about a software system. I want to illustrate this with the familiar tyre pressure example. Assume that again we are working in the automotive industry and our customer says to us:
We want to improve the fuel consumption of our cars by keeping the tyre pressure on an optimal level. The driver shall get an instant warning if the tyre pressure is 10% below or above the optimal value. We want you to build a system that creates this warning.
Assume, we now would listen to our System 1 that says something like:
Pressure sensors do pressure measuring. Measure the pressure with sensors and compare it to the optimal value
Everything is fine, but it is very likely that we never come across the idea of using the tyre rotation idea presented above.
So let us have a look again at the sentences from our customer and let us use the PAL-model. They describe our system context and contain a problem (optimal fuel consumption), the desired solution (warn if the pressure is not optimal), and requirements related to the timing of the warning and the meaning of optimal pressure.
With our PAL-model in mind, we can now discuss the initial problem (reduce fuel consumption) with our customers. The result of this discussion can be anything: assume that they confirm that this is their real problem. We document the initial problem in our structure (see Figure 3). As next step, we can approach the customer’s solution and discuss whether the tyre pressure warning is the proper solution for this problem. Again, the result could be anything. Assume, that they confirm that the tyre pressure is the primary reason for suboptimal fuel consumption. We put this information together with the requirements into our structure (see Figure 3).
Now we have an initial understanding of the system context and can approach the logical level. Based on our structure, we consider the solution together with the requirements on the context level as our initial problem on the logical system level (see problem statement on the logical system level in Figure 3). Now, our System 1 can again deliver the idea of using pressure sensors to compare the current tyre pressure with the optimal value. We can take this idea and put it into our structure. Or we could use our System 2 to deny the idea of pressure sensors and think of other solutions to detect the low tyre pressure. Thereby we could come across the idea of monitoring the tyre rotation and decide to use the ESP-System (a solution on the technical level) to monitor the tyre rotation.
I have been working on the ideas behind the PAL-model for several years and I have applied them in several industrial projects. My essential lesson from these projects is that the PAL-model really shaped and improved my way of thinking about requirements, and of course of problems and solutions.
Kahnemann’s book and his concept of System 1 and System 2 helped me to grasp the improvement much better. I believe that my System 1 is shaped by the PAL-model in two ways:
I hope you enjoyed my inquiry into the mind and the meaning of the word ‘requirement’. I do not want you to understand this article as a final result. You should consider it as a starting point for thinking of requirements engineering as a mental act and not so much as a documentation factory. Yes, we (as requirements engineers) often produce large and complex documents that describe a software system. Nevertheless, I hope that this article shows that the way people think during the requirements engineering process may have a large impact on the shape of the future system. The tyre pressure example with the two solution ideas (measure pressure vs. measure rotation) was a very enlightening example for me.
Nevertheless, I do not think that the presented PAL-model will always lead to innovative ideas such as the rotation example. Instead, I really think that the PAL-model will help you to increase your understanding of the system that you are developing as a requirements engineer. And this improved understanding may let you find innovative solutions.
I hope that this article will also change your way of thinking about requirements engineering. I am looking forward to receiving your feedback.