Thinking out of the Box

September 29, 2011 | 1 Minute Read
This post was originally posted on my old blog.

In requirements analysis we learn to pop the why stack and to challenge business requirements.

The goal of these techniques is to find the real business value at the heart of a given requirement. This real business value is often hidden by an already envisioned solution. Once we know this underlying business value, we might come up with a better/easier solution. Most often the reason why we can come up with an alternative solution is that we can look at the problem in another context and from different perspectives than the original requester of the feature.

This matches with the concept of 2nd order solutions in systems theory: 1st order solutions work within the existing system while 2nd order solutions modify the system itself.

The classical example from requirements engineering is the requirement that a software system must be able to print each UI-screen. The underlying reason was, that employees manually copied data from the given system into another system by printing them out and then typing them into a terminal of the other system. Once this underlying reason was discovered, an alternative solution could be realized: integrating both systems and digitally export/import data. This solution was cheaper to realize for the implementator and provides more business value for the enduser.

A more trivial example to illustrate this "out of the box thinking" is the following task:

Connect all the 9 dots in a single move, using 4 straight connected lines:

Can you do it with three lines?

Can you do it with one line?