Solving the right problem (40)

After reading Patrick Duisters' article published last Tuesday and the one I published the week before you might be tempted to conclude that we do not agree at all. Patrick stated 'Begin with the end in mind' and do not write down your requirements too soon, whereas I said 'End with the begin in mind', meaning that once you have developed a product, you don't want to be surprised that you completely drifted away from the original thoughts.

The problem in our apparent misunderstanding originates in dealing with terminology and in dealing with time.

Of course it is important to have that proverbial spot on the horizon and keep it in mind to ensure that you are heading in the right direction. Using terminology like this 'the spot on the horizon', 'keeping the end (or begin) in mind' can be very confusing though. What is this spot, this end, or this begin. Are they the 'requirements'? Are they fixed? Does a requirement describe the begin or the end?

Note: this exact problem is addressed by a new topic in the most recent IREB CPRE Foundation Level syllabus. One of the 'Nine fundamental principles of Requirements Engineering', number 5 to be precise, is called 'Problem, requirement, solution'. If there is a problem to be solved, requirements describe what the solution should be like. But if the problem changes over time, the requirements must change as well so does the solution. Patrick states in his article that it makes sense to keep those requirements flexible until you have created the solution. This ensures that the solution adheres to the most recent version of the requirements. So keep the end in mind: make sure that the requirements meet the end product and vice versa.

But the requirements should not only match the solution. They are in between the problem and the solution, so if the problem would change, the initial requirements would lead to a solution that wouldn't solve the problem. That is why I said 'keep the begin in mind', meaning: keep in mind what problem you are trying to solve and even more, watch out that the problem isn't changing as well!

As an example let's look at a problem most readers probably know, the traveling salesperson problem. For those who don't know this problem, it can be described as follows.

"Given a list of cities and the distances between each pair of cities, what is the shortest possible route that visits each city exactly once and returns to the origin city?"

It is not a new problem, but it is still a very relevant problem given all those parcel services and grocery delivery services that are currently blooming.

Now while the software developers are working on the planning software the problem changes. The company is growing rapidly so instead of just one truck delivering the groceries they need two. Distribution is done straight forward: one person takes all deliveries north of the company, the other one the rest. With 50 delivery trucks the problem has changed fundamentally.

This isn't new either, it's called the 'multiple traveling salesperson problem':

“Given a list of cities and a number of salespersons, determine a route for each salesman, such that the total length of the routes is minimized, and such that each city is visited exactly once by any of the salesmen.”

So the problem is even worse than the “solution bias problem” I described in article 38. Not only are we focusing on a suboptimal solution for the problem, we are focusing on solving an old version of the problem.

Having thought this over again I think we completely agree and maybe even "Begin with the end in mind" and "End with the begin in mind" mean exactly the same thing. Having the begin in mind means that you should ensure that you have solved?the right problem Keeping the end in mind gives you the challenge of keeping the requirements documentation in line with both the problem and the solution from the beginning of your development journey until the end (if there is one).

The words 'living documentation' suddenly come to mind. Improve Quality Services can offer training and consultancy to help you realize documentation that is always in line with the system it describes.

But we cannot perform miracles. Not every problem has a solution. The picture at the beginning of the article is an old bird-view map of the city of K?ningsberg (nowadays Kaliningrad, Russia). In the 18th century people wondered if it would be possible to take a walk that crosses every of the seven bridges once. In 1763 the famous mathematician Leonhard Euler proved that the “Seven bridges of K?ningsberg problem” cannot be solved.

This article is an article in the series about the versatile profession of requirements engineering. Every week a colleague of?Improve Quality Services?will share with the reader an aspect of requirements?engineers?from daily experience. Every article begins with a picture of a bridge. The bridge visualizes connecting two sides. In requirements?engineering connecting different stakeholders assisting the stakeholders in collaboration and communication about requirements.?

Articles published till date (the first articles are in Dutch):?

1.?Requirements?(Piet de Roo, December 1, 2020)?

2.?Shared Understanding?(Kaspar van Dam, December 8, 2020)?

3.?Context en requirements?structuur?(Patrick?Duisters, December 15, 2020)?

4.?Van Twin Peaks?naar?Twin Pines?(Patrick?Duisters, December 22, 2020)?

5.?Modellen om te bouwen?(Erwin Pasmans,?January?5, 2021)?

6.?Minimaal Modelleren?(Piet de Roo,?January?12 2021)?

7.?Begrip en Vertrouwen?(Benjamin Timmermans,?January?19, 2021)?

8.?En wat als de specialisten het niet met elkaar eens zijn??(Benjamin Timmermans,?January?26, 2021)?

9.?Waar zijn we nou helemaal mee bezig?!?(Erwin Pasmans,?February?2, 2021)?

10.?Soft skills? Keiharde wetenschap!?(Kaspar?van Dam,?February?9, 2021)?

11.?… en nu enkele feiten: Requirement Attributen?(Patrick Duisters,?February?16, 2021)?

12.?Waarom, waarom, waarom, ...?(Piet de Roo,?February?23, 2021)?

13.?Een leven lang zorgen?(Erwin Pasmans,?March?2, 2021)?

14.?Casus: Requirements management bij een distributiecentrum in aanbouw?(Eduard Hartog,?March?11, 2021)?

15.?Iteratief versus Incrementeel?(Kaspar?van Dam,?March?16, 2021)?

16.?Requirements of-the-shelf: geen maatwerk, geen requirements??(Erwin Pasmans, March 23, 2021)?

17.?Creatief?door constraints?(Piet de Roo, March 30, 2021)?

18.?3 Amigo’s?(Patrick?Duisters, April 13, 2021)?

19.?4 Amigos (of?meer?)?(Patrick?Duisters, April 20, 2021)?

20.?Requirements, de?CoronaCheck-app en Fred Flintstone?(Benjamin Timmermans, April 28, 2021)?

21.?Meer kapiteins op 1 schip (of staan de beste stuurlui aan wal)??(Erwin Pasmans, May 4, 2021)?

22.?Hoe SMART is SMART??(Benjamin Timmermans, May 11, 2021)?

23.?Jip en Janneke?(Piet de Roo, May 18, 2021)?

24.?Laten we het simpel houden?(Patrick Duisters, May 25, 2021)?

25.?Dilemma's?(Erwin Pasmans,?June?1, 2021)?

26.?Living?Documentation?Event 2021?(Kaspar?van Dam,?June?8, 2021)?

27.?Non-functional Requirements?(Patrick?Duisters, June 15, 2021)?

28.?The Big Shift?(Kaspar van Dam, June 22, 2021)?

29.?Why do we have these problems over and over again??(Erwin Pasmans, June 29, 2021)?

30.?Non-functionals, who cares??(Benjamin Timmermans, July 6, 2021)?

31.?Usability and UX, a revelation I had?(Benjamin Timmermans, July 13, 2021)?

32.?How??(Piet de Roo, July 20, 2021)?

33.?Requirements and design??(Erwin Pasmans, July 27, 2021)?

34.?Tom's people skills to deal with the customers?(Piet de Roo,?August 3, 2021)?

35.?Requirements creep: the ideal pocketknife with 3000 functions?(Benjamin Timmermans, August 10, 2021)

36.?Requirements creep: good or bad??(Benjamin Timmermans, August 17, 2021)

37.?End with the begin in mind?(Piet de Roo, August 24, 2021)

38.?Requirements: Do we really need them??(Kaspar van Dam, August 31, 2021)?

39. Begin with the end in mind (Patrick Duisters, September 7, 2021)