When in doubt: challenge the dodgy software requirements feature!

Writing software requirements (specifications) is a tricky business. On a project, there is a key role for that job: Business Analyst. They interact with the Business side and the Technical side. They are the bridge between two quite separate worlds. They are under tremendous pressure because they need to explain to one world what the other one wants. This requires, in the first place, understanding what the Business really wants. And sometimes, answering that basic question is difficult. There are several possible reasons for that. We could mention: difficulty to translate the business into computing routines; the difficulty to express without ambiguity a process that requires some level of human judgement, the business persons capable of telling what is needed are rarely available, there is no clear requirements process in place, the requirements capture format is fuzzy and not properly used, etc. But in this article we will study only the simplest one of them: The business may very well be simply unsure about what it wants. At the start of a project, it is quite common to make a long list of needed features. In this list, there are items that are obviously truly needed, and some are actually far less obvious.

Red Thinking HatI remember working on projects where some requirements were considered as mandatory, essential. One could not live without them. And when I was asking the simple question: who needs them? I could not get any answer. So, I then ask: who captured them? Still no answer. Nonetheless, someone, one day, believed it was a very nice feature indeed.

In some other cases, time is essential. The project must be released at a specific date. Features need some cleaning as it is becoming obvious that all won’t be implemented in time.

Sometimes, it is simply at the beginning of the project, while working at the Vision stage that it is needed to clean the core features from the fantasy features, the features that will make money and the features that will cost money.

Deciding what goes in and what goes out is often subject to long debates. Everyone who has worked on a project and has been involved at the requirements stage has participated to meetings to make decisions. The format of this meeting can be greatly improved by using the technique known as: 6 Thinking Hats.

Origins

6 Thinking Hats is a framework invented by Edward DeBono who also famously invented the Lateral Thinking concept. DeBono is defending vigorously the idea that thinking constructively and creatively is a skill that can be acquired. One is not necessarily born a thinker and everyone can become one. DeBono has written many books that I recommend. The one related to the technique covered today is: 6 Thinking Hats, by Edward DeBono, ISBN-13: 978-0141033051.

How it works

6 Thinking hats is a framework for focusing one’s thoughts on a specific part of the problem.

Read the whole paper on my business’ blog…