“I have never encountered a problem that I didn’t have an immediate solution for,” brags the project manager, who is always a huge fan of getting started straight away: roll up your sleeves, spit into your hands and get to work. So he was somewhat irritated that I didn’t want to hear anything about solutions. Problems are bad! Aren’t they?
Why problems are good
The project manager was certainly right that he has a solution for every problem. It is just that, unfortunately, it is seldom a good solution. And if the “solution” has to be carried on the backs of the developers – for instance, through weekend work – then it is definitely not everything that it should be.
Let’s admit that the word “problem” is somewhat overburdened. A better term might be “problem description”. Because to be able to assess a problem, it has to be measured against something. Whether an answer is true or false can only be judged if the question is known. This can be confirmed by everyone who has copied the answers from someone on a maths test and found out later that the teacher had given out two versions of the test with different numbers! There are also examples in daily life of solutions that work, but are not particularly good: from ticket machines, to revolving doors, to remote controls for televisions.
Don’t forget the context
A good problem statement describes the task to be solved as generally as possible. However, here, you will eventually hit the boundaries of what is possible – or sensible. There is an anecdote of a weapon manufacturer who had to develop a new gun for the British army. After he had reformed his requirements multiple times, because they were too solution-specific, he wrote, in the end “To defend the Queen and the United Kingdom.” Certainly correct, but now a part of the context is disregarded: in this case, the fact that he is simply working for a firm that manufactures weapons. This information can and should be taken into consideration.
The context, so the framework, can also contain other things. For an electric device, for example, this could be the permitted service temperature, for a car, the legal requirements.
Step by step to a solution
Only the smallest problems can be solved with one step. If you want to hang a picture on the wall, this is easily done. In one step you can decide on a nail, screw, iPad, nylon thread, sticky tape, stickers, washing line, projection, monitor, needle, drawing pins or chewing gum to fix the picture.
In most cases, finding a solution takes multiple steps: the problem is analyzed to find a solution approach. This solution approach presents the framework for the next problems. An example from the industry: a car manufacturer decided to develop a security against thieves (problem statement). A part of the solution should be the detection of movement in the interior. From this point the interior is given as context and a solution for the problem “surveillance” can be searched for. Possible solutions are surveillance with ultrasound, radar, infrared, camera or a dog.
Holes instead of a drill
Remember the example of “To defend the Queen and the United Kingdom”? Even if a large solution path is given, it cannot be inversed to look at the elementary problems again. Because the sad truth is that your customers are not interested in your product. Not really. Your customers are interested in what they can do with your product. Maybe you know the marketing saying: “Hardware stores don’t sell drills, they sell the opportunity to make holes in the wall.” The core expression is to not forget what is actually important to the customer. Even if you manufacture drills, you must consider that the customers are actually only interested in the holes in the walls.
“If I had asked people what they wanted, they would have said faster horses.” (Henry Ford)
Concretely, this means that problems on different levels should be considered differently. With the example above and the quotation from Henry Ford, it is about the customer level. That is one of the most important levels, because the customer is paying for the product in the end.
Not some solution and not the best solution. The right solution!
Meanwhile it should be clear why a good problem statement is worth a mint. The question is now how do we come to the solution? There are different, often complementary approaches. Here they are, sorted according to my opinion of the most important, without worrying about completeness:
Include the stakeholders: Even though the users are often perceived the most important stakeholders, they are not the only ones. The user is not always the buyer straight away: they have to be convinced to open their wallets. Stakeholders for operation, maintenance and service, as well as legislators, should not be forgotten.
Workshops: Concerning requirement elicitation, the book “Workshops im Requirements Engineering”¹ is an excellent, practical reference book for me. As the name says, it is the means of choice of workshop. Other related forms are also considered workshops, like interviews or focus groups. Often, the question arises of how things will proceed after the workshop. This book provides an easy, robust process to get resilient requirements from workshops.
Surveillance and reverse engineering: Component systems are also offered so as to use the currently kept requirements and documentation as a starting foundation. Pardon? They are not there? Then a reverse engineering must take place. The surveillance of the user when implementing the system is also a helpful method. However, we have to pay attention that we are not already confronted with a solution. It is important that the solution is recognized on the basis of the current problem.
At this point I would like to indicate the risk once again: often, it is attempted to find the best solution. That is good. Unfortunately, the “qualitatively most valuable” is often seen as the same as the “best”. And that is rarely the case, because the most valuable solution is often the most expensive. Most customers have a budget and thus expect a reasonable cost-price ratio. So the best solution is the one that best fulfils the requirements with consideration to the framework. And this can be a solution of low quality. If you ordered a salad to go in a take-away restaurant, you would certainly be confused if silver cutlery was given with your salad. And you would probably refuse to pay for it.
To record problems well is the first step to the right solution in this situation. Not only that: you notice that an “obvious” problem is suddenly no longer clear when you try to clearly fix it. That also helps to find the way to the “correct” solution – or it can even hinder you by causing to to solve a problem that doesn’t exist.
If you take a bit of time to cleanly formulate a problem in cooperation with the stakeholders definitely has better chances with the development. Maybe that will also convince the project manager mentioned at the beginning that it makes sense to earnestly grapple with the problem.
You can hear more from Dr. Michael Jastram in his weekly German blog System Engineering Trends and his English blog, Formal Mind Blog. He shares his knowledge of requirements exchange and public standard ReqIF in his online library ReqIF.academy.
 Only available in German: https://www.dpunkt.de/buecher/12024/9783864902314-workshops-im-requirements-engineering.html