Fulfilling requirements

This post is about how to simplify work, solutions and processes. For me this is a key topic.
I’d like to tell you, how to stop focusing on virtual, unrealistic requirements and start focusing on real customer needs, desires and requirements.
I take an example from software development to explain it, but I promise you, it is the same story all over in every business.

Unicorn feeding

I come across the following situation over and over again.

An application is being built and suddenly a developer starts to struggle. I start a discussion about the problem and why it happens. Then I figure out that the behavior of the application is undefined, when last Sunday was a solar eclipse and today the user is going to plant corn on his left toe.

The developer is breaking its head about the best behavior for this “requirement”.
But the problem isn’t the situation. The problem is the developer.

This “requirement” is a virtual one, invented by the developer. It will most likely never happen. Or even if it happens, there might be no desire for a special treatment on that.

Imagine there is a textbox to perform a search. The developer now says, when a user enters the word “date”, he could either mean the meeting with another person or the fruit.

I actually don’t care about what the user means. I care what he enters into the field and seek through the database for that word. Maybe the result page will display both mixed. Then he needs to refine the search conditions.

You may find this example stupid. And I admit that this never happened to me. But there were much more stupid examples than that, you wouldn’t believe me.

Touch the ground

Now how to get rid of such strange thinking? This might also happen to me, when I do not completely understand the customers process. So whenever I need one single second to think about a behavior of whatever, it means that it is not completely clear from the beginning.

I ask myself two questions:

  1. Is it a requirement / need?
  2. Does it make sense?

If you answer one of these questions with no, you should just not do it! Or if it is not a do or don’t question, but rather a how question: do it the easiest way possible.

Let me go a little more to the detail with the two questions:

With requirement / need I mean to be specified within any requirement document or the customer initially mentioned it in a discussion.
Don’t you even think about “how should I know what the customer said to the requirements engineer or sales man”!!!!
If you don’t know, then it is not desired, unless anybody tells you something different.

Remember the onion principle. Try to do everything as simple as possible. Better to increase the feedback frequency with the customer. He will tell you, when he misses the left toe planting behavior.


What I try to say with does it make sense is not what in a strange developers mind makes sense (sorry ;-) ). I mean, whether or not it makes sense for the customer. Will he ever meet this situation and if yes, is it that often or important to really implement a special behavior on that? When a customer would never think about this situation by himself, then it will most likely not make sense.

If it really makes sense, but is still not desired at this point, you might discuss it with the customer. But be aware, that you probably do it for free then!


If both questions are answered with yes (if you do your work right, this will rarely happen ;-) ), try to find a higher abstraction.
Back to the search example: You should not start to implement a special treatment for the date example. You should bring it on a higher level. There are also other homonyms, that may be treated the same way. It comes very often that the solution on a higher level needs less effort than the detailed situation itself.
And again: find the easiest way to solve the problem!

Requirements and payment

The major problem of the virtual requirements is, that you normally have a lot of effort to implement the special behavior and that nobody pays you for that.
Very likely you increase the risk of bugs and very often the application becomes less user-friendly because of incomprehensible behaviors in special cases.
Therefore you should try to avoid them, or, if not possible, try to deal with the situation in a more generic way.

Leave a Reply

Your email address will not be published. Required fields are marked *