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.
Hans van Loenhoud MSc is a consultant and teacher at Taraxacum in the Netherlands. He has been working in software development for more than 35 years, starting as a Cobol programmer and later on specialized in test and quality management.
In this role, he has been teaching various ISTQB test courses and has been chair of TestNet, the Dutch association of professional software testers. In recent years, he joined IREB to build a bridge between software testing and requirements engineering. He gives various Business Analysis, Requirements Engineering and Software Testing trainings. Hans is also a lecturer at the Amsterdam University of Applied Sciences for these topics and participates in the IREB advanced level Elicitation working group.
Dr. Kim Lauenroth is Chief Requirements Engineer and leads a competence centre for requirements engineering at adesso AG.
He has over 10 years of experience in software and requirements engineering in different domains. He regularly speaks at internal conferences in the topic of RE. Within IREB, he is involved in the development of the advanced level module Elicitation & Consolidation.
Kim received his PhD in the field of requirements engineering from the University of Duisburg-Essen and studied computer science, business administration and psychology at the University of Dortmund.
Dr. Patrick Steiger, based in Switzerland, leads the requirements engineering activities of Infometis AG and is a part-time teacher at the MAS HCID (Human-Computer Interaction Design) which is provided as a cooperation of University of Basle and HSR Hochschule für Technik Rapperswil.
Since more than 20 years he works as a consultant in software engineering projects, focusing on requirements engineering. His PhD was on the topic of “Personal Risk Management”, which already at that time addressed problems and goals of individuals.
Comments (9)
I like the approach to look the problem/goal/solution triangle from a very theoretical point of view. However, the world is messy, difficult and complex...
I'm not sure if the entity relationship between a problem and a goal is 1:1 - I prefer to have fewer goals. There are always lots of problems!
I'm using the approach of a "problem space" and a "solution space". I prefer to keep these two concepts apart. Goals help to organize the two.
While in the problem space I'm trying to understand the problem - this is the "rationale" in a requirement. Use cases are an additional way describe how the problem is approached today.
Requirements fall out of such activities, but they are anything but complete.
The solution space is the area where many solutions should be considered. I have seen many mediocre or bad solutions in my career... simple because the first best solution was chosen very quickly. Here you can work with brainstorming and many other techniques.
By looking at different solutions more requirements come to light. Working with different solutions, selecting them and validating them is lots of fun, but typically a requirements engineer is not too deeply involved in that, unless she has good domain knowledge. Also, this should be done with more than one person.
A selected solution can now be validated with the stakeholders. This way will know quickly if the direction is right - before writing a single line of code, or starting the actual development. Prototypes help a lot - but they can be very simple and crappy.
Prototypes and validation with stakeholders will create more requirements. They tend to be more realistic than without looking at a solution closer.
Goals are great to organize requirements. The requirements (or specifications for the solution found) can be nicely organized with high level goals.
The two view points problem space and solution space help me to stay focused and not to get lost with all the different view points of the various stakeholders.
Hi Fabian,
Thank you for your valuable comment. Indeed, our article is written from a theoretical point of view. And because, as you say, the world is messy, difficult and complex, such a theoretical framework needs practical applications to make it work. Your approach with a separate ‘problem’ space and a ‘solution’ space certainly is a clear and practical way of working, although I would not hesitate to add ‘goal’ space as a third entity. In fact, the application of the ‘goal tree’ technique can be very useful in this domain.
Your doubts about the 1:1 relationship between problems and goals is a typical example of the gap between theory and practice. In theory one problem has always one related goal: to remove the problem. In practice we usually skip this step, and relate one (higher!) goal to a number of underlying problems, for which we then try to find a solution. The theoretical notion of a 1:1 relationship will help us to check whether all problems have indeed been removed by the solution.
The key message of our article is that the requirements engineer should always explore all three parts of the triangle. If a client comes up with a problem, ask ‘What will you be able to do when the problem is solved?’, i.e. the related goal. If someone mentions a goal, ask ‘What [problem] in your current context inhibits you to reach that goal?’. And if (worst case!) your customer brings up a solution, start a discussion about what problems could be solved by it and what goals will be achieved if the solution is implemented.
In my experience, the problem or goal initially brought up by the client is rarely the one that is most urgent or valuable to solve. One needs to explore the whole ‘landscape’ of related problems and goals at different levels and from different angles before one can even start thinking about solutions. Indeed, many solutions may fit in this landscape, and at the end, it is the community of stakeholders who should be able to choose. Lo-fi prototypes developed by the requirements engineer will then be a great help.
This search for solutions is a fuzzy process, in which many potential and often contradictory requirements will be discovered. After reaching agreement on a single preferred solution, one can start developing the detailed requirements for it. The landscape of problems and goals will then be used as a map to ensure the completeness and consistency of the set of final requirements.
Hans van Loenhoud
Very good article and yes, a shift of paradigm
There are problems (and/or goals, I even think this distinguishing is not that important), and there are solutions. Requirements are secondary and they are just about clarifying and restricting an - already defined - solution, related to the original problem/goal. Depending on the solution, there will be a different set of requirements.
The pair problem/solution is recursive in its very nature, and it is important to track problem-solution-requirements triplet on every level of consideration.
The core of these ideas was already formulated in the earlier article from Kim Lauenroth (What does it mean to say requirement?), which was a "moment of truth" for me back then.
If feel, it is needed now to re-tell the whole story of requirements engineering in new terms based on the above presented foundation. Some random ideas below:
To conclude, I observed another different meaning for the term Requirement. It can be used on any level by a person or organization responsible for building some solution to refer to anything which is required from them.
Sounds like a tautology, but think about it. If you are a software shop and you sign a contract and it has a spec attached, then everything said in that spec is a requirement for you - because it is your contractual obligation to build THAT THING. Even if most content in the spec is describing the solution and stating the goals. If you are a software developer, and you are to implement a task, every input you get to the task, will be for you "requirements". Some of them are derived from the customer's specifications, some maybe GUI wireframes created by a GUI designer, some maybe architecture blueprints, coding conventions and deployment guidance. All that are "requirements" from the point of view of the developer. They won't even necessary care where each of them is coming from.
I wonder how the authors see this meaning of requirements related to the previous meaning, defined above, as something connecting the problems with solutions.
Thank you very much and looking forward to more excellent reading!
Dear Grigory
Thank you for your extended feedback on our article. You are right that the term "requirement" has two faces: The originator (stakeholder) issues requirements to be implemented and, on the other hand, the receiver (developer) gets requirements that guide the actions performed by doing his job. A 'conditioned' developer gets used to work against requirements and hence, in case of lacking explicit requirements he might even come up with implicit requirements he expects from that stakeholder. E.g. he might think that the stakeholder wants him to program against coding standards - hence he perceives the coding standards as requirements.
We commence our article with the definition of the term "requirement" from the CPRE glossary: "A requirement is a condition or capability needed by a user...", hence it is a virtual contract between the stakeholder and the developer. Everything describing a solution that is to be implemented in the future is a requirement (sometimes also called a requirements specification). Everything describing an existing application is just a product documentation. Depending on the level of abstraction, the requirements might describe the concept of the solution (e.g. "we need a CRM") or they describe the technical details of a solution (e.g. the CRM needs to be a cloud based software as a service hosted in Europe). Especially in the agile approach, it is good practice that the developer and the stakeholder together come up with the detailed requirements. We agree with you that sometimes the stakeholder saves energy by just relying on a standard solution, assuming that the supplier has delivered the product to many other customers with similar problems and therefore that product is the solution to his problem/goal.
Regards,
Patrick Steiger
I agree with problems and goals.
What do we call a requirement engineer's proposal? An idea? If it is different from problems / goals stated by stakeholders, then would you add it to one of these terms in context of positive or negative? Or it is independent as it is solely proposed by requirement engineer as an enhancement?
Dear Lakshmi,
Thank you for your reaction.
In our opinion, the requirements engineer's proposal is, at first, a set of candidate solutions, related to the analysis of the complete landscape of related problems and goals.
Each solution should be accompanied with an estimation of benefits and costs, risks, and the degree to which the underlying problems are solved / the goals accomplished.
After the stakeholders have selected their preferred solution (based on the enhancements that they expect from it), the requirements engineer will elaborate it into requirements to a certain level of detail, depending on the project's needs.
Regards,
Hans van Loenhoud
A truly excellent article
I want to commend the authors for putting together a truly excellent article. They manage to take what are often treated as slightly-related concepts and not only tie them together, but to do so with a model that is logical and clear.
I think this is such and excellent article that I am going to recommend this to all the business analysts at my employer and post a personal blog article recommending it as well.
Kudos again to the authors and to the IREB for making such outstanding articles freely available with Requirements Engineering Magazine, rather than sticking this resource behind a paywall or membership requirement.
First requirements - then solution? Or the other way round?
Dear authors,
Thank you for the invitation to give feedback to your article. I would like to state briefly: I totally agree with your opinion. Although it is a fundamental shift of paradigm.
The key sentence in the article seems to be: “Only after you have drawn the complete picture does it make sense to choose certain viable solutions to elaborate into requirements”.
We are used to see it the other way round: We are told that as a requirements engineer it is our job to elicit and document requirements. On this base someone else (a solution engineer?) is designing a solution. (“First requirements, then solution”).
Now you are telling us, that we have to find a viable solution first, and on that base we will elaborate requirements (“First solution, then requirements”).
I think you are right. As analysts in IT projects we have to design solutions and not just to record requirements. I have been working that way for more than 30 years and I don’t know any “requirements engineer” who just records requirements and does not design solutions.
Furthermore: I think the concept of “requirement” is dispensable, we should replace it by something like "domain knowledge". But there is one problem: If we do not have requirements, what about requirements engineering?
Thank you for this article. I am looking forward to reading more of that.
Josef Falk, SEQIS GmbH
Solutions first, requirements second ...
Dear Josef Falk,
Indeed, we see a fundamental paradigm shift, which, in my opinion, is triggered by the Agile storm that has been raging over the IT world. Nowadays, stakeholders demand value from us: concrete solutions that take away their problems and enable their goals. They don't need a thick novel about a system that they can hardly imagine; the requirements engineer as the bookkeeper who meticulously describes hundreds of detailed requirements based on quicksand has no added value.
That is exactly the point that you make.
Requirements always relate to a certain solution, being a future system to be developed. But what solution?
You need a holistic view on all related problems and goals of all stakeholders, before you can draw up a menu of valuable solutions. Let the stakeholders choose from this menu. Big chance that they pick another solution than first seemed obvious from the original problem. Only after the stakeholders have, consciously, chosen a certain solution, it makes sense to elaborate requirements for that solution. In that sequence of working, I am convinced that 'requirements' still is a useful concept, being the input for the developers that have to deliver it.