Hans van Loenhoud Kim Lauenroth Patrick Steiger

The goal is to solve the problem

Some thoughts on problems and goals in the context of requirements engineering

A requirement is "a condition or capability needed by a user to solve a problem or to achieve an objective" (AKA a goal), see the CPRE Glossary ^{[Glinz 2014]}. Thinking in terms of problems and goals thus is a core competence for the requirements engineer.
But what in fact is a problem or a goal? This may seem to be a rather philosophical question. As requirements engineers we should be quite specific on this point as the problems and goals of our clients are the raison d'être for our work. In this article, we start from a theoretical viewpoint: we critically explore the concepts and look into the relation between problems and goals through solutions. We will also pay attention to their recursive nature. We will end up with several (slightly provocative) thoughts on the subject, including practical implications for the work of the requirements engineer.

Problems

A problem is a mental construct of a stakeholder. It concerns a present, negatively experienced state of an aspect in the stakeholder's context. If it concerns a potential future, negatively anticipated state of an aspect in the stakeholder's context, the mental construct is called a risk (i.e. a potential future problem). The same actual state in reality can be perceived as a problem by one stakeholder whereas another stakeholder does not care. For instance, let us assume a business context in the insurance industry. The fact that 20.000 application forms have been submitted on paper (rather than electronically) is a problem for the stakeholder who is responsible for efficiently processing them, whereas the stakeholder responsible for sales might be just happy to have increased the business volume. Often, a certain state in the context is perceived as a problem because it inhibits the stakeholders (or their teams) from doing something desirable or from achieving a goal.

Goals

A goal is another mental construct of a stakeholder. It concerns an envisioned, future, positively anticipated state of an aspect in the stakeholder's context. A certain state in the future can be conceived as a goal by one stakeholder, while another stakeholder would be indifferent to it or even perceive it as a risk. For example, let's look into the same insurance case. The process manager wants to get rid of paper-based applications. His goal is to receive only electronically submitted applications. The sales manager may consider it as a risk: the company may lose customers that still prefer an application on paper. Often, a certain future state in the context is perceived as a goal if it will enable the stakeholders (or their teams) to do desirable things.

Problems and goals belong together

As you see, problems and goals are tightly connected to each other. They are conceived in that negative or positive way, because they influence a certain behavior of stakeholders: a problem in the present inhibits the behavior, while a goal will enable it in the future.

Thus, a problem is always connected to an inherent goal: the intended behavior or state. In the same way, a goal is always connected to an inherent problem that refrains the stakeholder from the intended behavior or future context state. Without an issue, risk, challenge, handicap, etc., there is no need to formulate an explicit goal.

Solutions: The third party

Problem and goal are connected by another mental construct, the solution. A solution is the roadmap for an intervention in the context of the stakeholder: it describes a way in which the actual negative state in the present can be changed into a desired state in the future. For example, the process manager in our insurance example might ask for a one million Euro digitalization project (as a solution) in order to get rid of paper-based applications. Be aware that a solution is only the roadmap. It is the execution of the actions described in this map, that, if successful, actually causes the desired change in the context state.

Stakeholders who express a problem and/or a goal always have some idea about a solution. A change of the actual state in the direction of the desired state is thought to be possible, even if the solution itself is not clear.

So, we find that problems, solutions and goals form a trinity. They cannot exist without each other: if there is no problem, why define a goal? If there is no solution, just accept the problem as a fact; without a goal, there is no purpose for any solution.

Recursiveness

Explicit problems and goals may be occurrences of implicit higher level problems or goals. They never come alone, they are part of a large family of parents and children. The siblings in this family are to be discovered to get a complete picture.

Parents of a certain problem can be found by looking for causes. What causes this problem?
Take for instance the insurance problem of getting too many paper-based applications. The cause for this might be the laziness of brokers who want to avoid the administrative work of digitalizing the application - it's more convenient for them to just hand in the paper forms signed by the customers.
Parents of a goal can be revealed by analyzing the behavior that is enabled when the goal is reached. Why does the stakeholders have this goal?
Regarding the goal of only receiving electronic insurance applications, the next higher level goal is derived from the reason for that (why?), namely to automatically process them. Why? Because that reduces costs and processing time. Why? Because that adds to the profitability of the companies’ business and increases customer service (e.g., enabling the acceptance at the point of sale).

The children in the family (the lower level problems and goals) can be found through solutions. Every action of a feasible solution sets a new goal (and problem) at a lower level for someone who is responsible for implementing it and has the challenge of how to effectively do so.

For instance, let us assume that the process manager got approval for his digitalization project. He hires a project manager who's (lower level) goal it is to enable the digitalization of all insurance applications and thus to get rid of paper applications, and who's (lower level) problem is how to set up a project team appropriately. How? By forming a few agile teams building on the promises of the agile approach to software development.

The model

The following class model shows the relation between these concepts.
A problem inhibits a goal and is caused by higher level problems. A goal enables higher level goals.

A problem may be solved by a solution, that may achieve the pertaining goal. A solution defines certain actions to perform. Each action sets one or more lower level goals on its implementation.

The requirements engineer

As a requirements engineer, you have your own problems and goals: you are saddled with the problem of finding solutions for your clients; your goal is to get your solutions accepted by them. This means that you have to elicit, analyze and understand the complete network of problems, goals and solutions in their context. 'See the Whole', as IIBA calls it ^{[Stapleton 2013]}. Only after you have drawn the complete picture does it make sense to choose certain viable solutions to elaborate into requirements.

Usually a certain problem or goal is the starting point for your work. In literature, there are several approaches that focus on problems, e.g., Problem Frames ^{[Jackson 2001]}, or goals, e.g., KAOS ^{[Van Lamsweerde 2009]}, but to 'See the Whole' you need a more holistic view.

Subjective components

Unfortunately your stakeholders seldom tell you their true problems or their real goals; they just give you some clue about what troubles them in the present, or scares or attracts them in the future. Because problems and goals exist in the minds of stakeholders, you can only discover them by communication with these stakeholders. For the same reason, problems and goals will always contain a personal, subjective component. Finding these subjective components and taking care of them is often crucial in finding a proper solution. Systematic and repeated stakeholder management is another key success factor to get the appropriate access to the stakeholders in order to elicit the real problems and goals.

The requirements engineer can use Why? questions to elicit these subjective components: Why do you perceive this actual situation as detrimental? Why are you attracted by a future situation? Why is the to-be-enabled behavior important to you? Sometimes, a problem can even be solved by just reframing/rephrasing the subjective components related to it - but only if you have drawn the complete picture of problems and goals in all their objective and subjective components.

Past and future problems

A problem with problems is that a client often comes up with a context state that does not exist any more or that does not exist yet. A problem in the past (i.e. it is not a problem any more) has become a fact, as we cannot change history. E.g., your stakeholder of company A explains that it is a problem that they have bought company B two years ago, because company A is now being sued for something that company B did five years ago.

As a requirements engineer, you should follow the effects of this past problem and find out what consequences it has for the current context state. In this way, you discover the actual problem and can start finding a solution for that. In our "company A bought company B" example, the actual problem for the stakeholder is being sued (everything else described above is history and cannot be changed).

Future problems do not exist right now, but as prospective thinkers, our stakeholders might still perceive them as a current problem. A so-called 'future' problem is, in fact, a risk: a certain probability that an expected negative state will arise. This is the business of risk management. Identifying potential problems in the future transforms them into manageable problems today. Generally, there are four solutions to risks: avoid, reduce, transfer, take/accept ^{[Steiger 2000]}. Which solution to choose depends on the goal that is at danger. If human lives are threatened or the company's existence is endangered, avoiding or reducing solutions are preferred. On the other hand, future problems identified by the risk manager might be irrelevant for the management, i.e. taking the risk might be the right solution in that case.

The requirements engineer dealing with risks should therefore try to identify affected goals and then determine the appropriate solution derived from the four generic approaches mentioned above.

Goals without problems and vice versa

Another challenge for the requirements engineer is that a stakeholder might formulate a goal without a problem. If you then ask what actual context state inhibits reaching that goal, you may be confronted with all kinds of problems, none of them having a clear relation with the formulated goal. On the other hand, problems without goals cannot exist in theory, because part of the definition is that a problem inhibits a desired behavior. But, in reality, a client easily comes up with some context state that troubles him, without being able to tell you what he would do if this state was altered.

In both cases, unmentioned, subjective problems and goals are likely to be involved. Why questions can help to find the 'real' ones, before you can start thinking about solutions.

Problems and goals without a solution

A problem without a solution is a fact; a goal without a solution is a daydream. But be careful with this problem-goal-solution trinity. The fact that the stakeholder cannot think of a solution does not mean that no solution exists.

Just a century ago, putting a man on the moon was a daydream. As mankind invented solutions to overcome the problem of gravity, now we can imagine the goal of travelling to Mars.


Brainstorming and other creativity techniques may be used to find new, previously impossible solutions. This often starts with defining a clear goal and then, step by step, identifying and peeling off the problems that inhibit reaching it. Time may be on your side: what was impossible yesterday, may be feasible tomorrow.

Freestanding solutions

As a requirements engineer, you are often confronted with a client that directly comes up with a solution ('We need a CRM system!'). Then if you analyze the situation, you may find that there is no explicit problem to be solved or goal to be reached. And by the time you have unraveled the implicit problems and goals, the requested solution seems to be irrelevant, except, perhaps, for some subjective components. You will then need to show the complete problem-and-goal landscape to convince your stakeholder to look for a proper solution.

One last question - what about requirements?

Maybe you recognized that we did not dive into the term 'requirements'. They are of course also related to problems, goals, and solutions. But this is a completely different story and this story would exceed the size of this paper. You can look at another article in the RE magazine, if you are interested in one viewpoint on this topic ^{[Lauenroth 2014]}.

Finding the 'right' solution

Just like problems and goals, solutions do not exist in the real world; they are mental constructs. Solutions, however, are not present in the minds of the stakeholders, so they cannot be found through elicitation. Solutions will arise in the mind of the requirements engineer, the stakeholders and other people involved through a creative design process starting from the elicited problems and goals. Usually, more than one solution may solve the problems and reach the goals - to a certain extent. It is up to you as a requirements engineer to come up with suggestions for the right solution; primarily a solution that can be accepted by your stakeholders - if not, all your work was in vain.

To convince your clients that your solution is the right one, you will concentrate on its value. A proper solution offers added value. This is calculated as the balance between the benefits of reaching the goal and the costs of executing the actions as defined by the solution.

But added value is more than just a calculation in Euro's: costs are tangible expenditures in the present, while benefits are subjective expectations about the future. Thus, the outcome will always be subjective.

Another point to consider is the risk of a certain solution: the chance that the goal will not (completely) be reached, the benefits will be less than expected or the costs will overrun.

Don't forget to include the timescale. Both value and risk will change over time and a seemingly good solution for next month may create a problem next year.
In the end, as a requirements engineer you must be able to sketch the tableau for your stakeholders: the complete set of related problems, goals and possible solutions, clarified with benefits, costs, and risks. Only from that set can a proper solution be chosen.

Conclusion

Dear reader, you may agree with our viewpoint or not. To be honest, during the creation of this text, we recognized that we started with three completely different perspectives on the topic. It seems that the debate on problems, goals and solutions (and even requirements) is something that is embedded deep into our field. So, if you do not agree with us or you have a different opinion on the subject, please contact us with feedback or even write another article for the RE magazine with your ideas.
We believe that discussing fundamental terms in a field is not a weakness; it is a strength and shows that we are building a healthy community. With this article, we want to encourage practitioners and researchers to join us in this effort.

References

• [Glinz 2014] Glinz, M.: A Glossary of Requirements Engineering Terminology (Version 1.6 May 2014), IREB, 2014.
• [Jackson 2001] Jackson, M.: Problem Frames - Analyzing and structuring software development problems. Addison-Wesley, 2001.
• [Lauenroth 2014] Lauenroth, K.: What does it mean to say "requirement"? An inquiry into the abilities of the human mind and the meaning of the word "requirement". Requirements Engineering Magazine 01/2014.
• [Stapleton 2013] Stapleton, P.: Agile Extension to the Babok® Guide (Version 1.0). International Institute of Business Analysis, 2013.
• [Steiger 2000] Steiger, P.: Computer-based Support for Comprehensive Personal Risk Management. Institute of Insurance Economics, University of St. Gallen, Switzerland, 2000.
• [Van Lamsweerde 2009] Lamsweerde, A. van: Requirements Engineering: From System Goals to UML Models to Software Specifications. John Wiley & Sons Ltd., 2009.