Ways to contributeContribute to the RE Magazine Search Authors
8
Comments
Issues
Close
Close
1Write an articleMore Information
2Place an advertisementMore Information
3Sponsor the magazineMore Information

The goal is to solve the problem

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

7 New
Comments
Written by Hans van Loenhoud, Kim Lauenroth, Patrick Steiger
Estimated Reading Time: 13 minutes, 0 second
Advertise with usAdvertisement
Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development

www.microTOOL.de
Best for System & Software Development

objectiF RPM – Requirements Engineering and Agile Development

www.microTOOL.de

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.

Image

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.


Give feedback


Feedback-

From Josef Falk

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

From Hans van Loenhoud – Author

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.

From David Olson

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.

From Lakshmiganthan Sundararajan

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?

From Hans van Loenhoud – Author

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

From Grigory Grin

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:

  • Dialog with a (potential) customer is NOT about "requirements elicitation". It is about getting the first understanding of a problem, OFFERING A HIGH-LEVEL SOLUTION, discuss, and drill-down to the next level of solution decomposition. Repeat as necessary, until both parties are confident enough.
  • The job of a business analyst is NOT about writing down requirements and context for someone else (architects, developers, etc.) to offer a solution. The job of an analyst IS to offer a solution.
  • This means in turn, that people without some level of understanding of the solution domain cannot perform analysis role well. Equally people without understanding of the customer's business, goals and problems cannot be successful software architects.
  • In the contracts about software development it is rare that the scope of work is described as "solve the problem ABC" or "fulfill the need ABC". Instead the contract's scope says "implement the solution XYZ". Even though it is important for development company to understand the context, the goals, the problems, etc., their business is selling solutions. Judgement is a certain solution really solves the original problem has to be done by the Customer.
  • This raises an interesting point about how the customer and the vendor should (differently) use analysts / requirements engineers and if both do, how the two can reasonably collaborate. Do you as a contractor remember the cases when you were not willing to bid against the spec presented by the customer? And the customer was not willing to read through the details of your specification?
  • Almost every book on the subject assumes the following: there is a problem/goal, and now it is about finding a solution most fitting to the problem. (And usually on a green field.) In the real life the customers are afraid of contracting someone to create a solution from scratch based on their requirements. They are looking for someone who already HAS a similar solution, which they can take and CUSTOMIZE. And suddenly the game changes. Now it is (for a software shop) about finding a PROBLEM fitting to their existing SOLUTION.

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!

From Patrick Steiger – Author

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

Sponsors