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.
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.
Two Systems in Our Mind
Daniel Kahneman presents a model of the mind that consists of two systems :
- System 1 operates automatically and quickly, with little or no effort and no sense of voluntary control.
- System 2 allocates attention to the mental activities that demand effort, including complex computations.
Kahneman illustrates the differences and the power of both systems with two very simple problems:
- Is 17 x 24 equal to 123 or 12.609?
- Is 17 x 24 equal to 568?
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.
The Bat and Ball Problem
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.
What is a ‘requirement’?
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 :
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
- A documented representation of a condition or capability as in (1) or (2).
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:
- R1: The pressure sensor shall measure the pressure between 0 and 50 PSI with a precision of +/- x %
- R2: The pressure shall be measured every y seconds.
- R3: The system shall give a low tyre pressure warning if the measured pressure falls below the threshold z.
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:
- R4: The ESP shall continuously measure the rotation of all tyres.
- R5: The tyre rotation shall be measured with a precision of +/- x %.
- R6: A low tyre pressure warning will be given if the rotation of a specific tyre will deviate by z % for a time of y seconds from the other three tyres.
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.
Problem and Solution is a matter of Abstraction
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.
Putting the Pieces together
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:
- My System 1 started to analyse every statement about a software system I hear and every thought I have on a software system that I develop as requirements engineer. My System 1 tells me, for example, that a thought on the software system does not feel right. Then I use my System 2 to put the thought (or the stakeholder’s statement) into the PAL-model to identify its abstraction level and its nature (problem, requirements, or solution). This explicit and effortful task often unveils missing information and helped me to engage my stakeholders in intensive discussions about their intended systems.
- I recognized that I could use the PAL-model to structure my knowledge and to improve my ability to memorize information about a new software system. Especially the abstraction levels help me to focus on a particular part of the system. For example, during the beginning of a project, I focus on the context level to learn about the problems that the stakeholders want to solve and the way they want to solve their problems.
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.
-  Miller, G.A.: The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. The Psychological Review, Vol. 63, No. 2, 1956, pp. 81–97.
-  Bandler, R.; Grinder, G.: The Structure of Magic I: A Book About Language and Therapy. Palo Alto, CA: Science & Behavior Books, 1975.
-  Kahneman, D.: Thinking, Fast and Slow. Penguin Books, 2011.
-  Kahneman, D.: Thinking, Fast and Slow. Penguin Books, 2011.
-  The correct answer is 5 Cent. 5 Cent for the ball plus $ 1.05 for the bat equals $1.10.
-  Gladwell, M.: Blink – The Power of Thinking without Thinking. Back Bay Books, 2006.
-  see, for example, Pohl, K.: Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010.
-  see http://www.ireb.org/fileadmin/IREB/Download/Homepage%20Downloads/IREB_CPRE_Glossary_15.pdf , p. 16
-  see http://en.wikipedia.org/wiki/Tire-pressure_monitoring_system for more details on tyre pressure monitoring systems.
-  see, for example, Pohl, K.: Requirements Engineering: Fundamentals, Principles, and Techniques, Springer, 2010 or van Lamswerde, A.: Requirements Engineering: From System Goals to UML Models to Software Specifications, Wiley, 2011.
-  Colburn, T.; Shute, G.: Abstraction in Computer Science. Minds & Machines, Vol. 17, 2007, pp. 169–184.
-  You have to roll the paper as tight as possible. Then you have to fold it in the middle. The fold will create an edge that is strong enough to lift the crown cap.