Published: 5 October 2017
Every once in a while I come across an article that discusses some subject in an incredibly clear and thoughtful way. Issue 2017-02 of IREB's Requirements Engineering Magazine online contains just such an article. It's titled The goal is to solve the problem
and it's an article that I recommend any Business Analyst or Requirements Engineer read. And if you are relatively new to the field I recommend it even more.
This article is full of highly quotable text and I have included some quotes below to give you a sampling, but it's just that. A sampling. You really need to read the whole article to gain the full value.
As the authors state in the opening paragraph, they use to the article to:
... 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.
They then go on to an outstanding job of defining problems, goals, and solutions in extremely clear ways while providing additional context. For example, they define a problem as:
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).
And a goal is:
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.
They show how the two are dependent by showing that:
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.
They also define a solution as:
Problem and goal are connected by another mental construct, the solution. A solution is the road map 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.
They nicely tie all three together by saying:
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.
And they discuss the criticality of communication in defining solutions by saying:
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.
But these are just snippits to give you a taste of quality of thought and clarity of communication in the article.
They also discuss:
Lastly, they tie the article up with a few points that I think can't be stated often enough. These two points are sampled in the quotes below:
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.
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.
Hopefully, this gives you enough of an idea of the excellent quality of this article that you will immediately head over and read it. And then share it with your co-workers. And then with any other Business Analysts, Requirements Engineers, or others who might work with them that you might know.
Setting a strong foundation is critical to improving, and this article is one that I think should be required reading for anyone in our field.