Software Requirements and 6 Thinking Hats

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.

I 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. [...]

  • Project Success
    Permalink Gallery

    A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

A Pragmatic approach to Software Process: UP + Critical Chain; Applied to a Retro-Engineering fixed-price project

Software Process is great topic for endless conversations (and battles) among IT professionals. Every now and then, a new process is arriving on the market that is introduced as the new marvel of the world, the new silver bullet, thanks to which every software project is going to be a never seen before success. We can name a few:

Prince 2 (although this one is not really an IT project process)
Unified Process
Agile family

eXtreme Programing
DSDM (Dynamic systems development method)

During our decades of projects experiences, we have encountered many of these processes, used on various projects and in various circumstances. Today, I would like to talk about a project during which we have used a combination of a “proper” (in the sense of created with this purpose) software development process and a more generic project management approach. The two processes are:

The Unified Process (also known as Rational Unified Process, before IBM bought Rational) created initially by Ivar Jacobson, Grady Booch and James Rumbaugh.
Critical Chain, created by Eliyahu Goldratt

The Unified Process
The Unified process is not only a process but more generally it is a framework that has been created for being tailored for each project. It is the first iterative and incremental framework that has been applied widely in the industry.

It is composed globally of four Phases, each Phase being composed of Activities.

One of the most interesting elements is the Phases as they describe periods of the project during which the objectives are different. The first phase, the Inception is about scoping the project, identifying a possible architecture and listing the risks to come. Then comes the Elaboration phase, mostly about validating an architecture, [...]

Iteration size and the tap water glass

When I teach iterative approach in software development, I use to justify it with an analogy that I have borrowed from Kent Beck: managing software is like driving a car; you permanently need to adjust left and right if you don’t want to have an accident. That’s a fine analogy and it always worked for me. Being myself deeply convinced that iterative approach is a completely natural human behaviour I have added my own list of images, examples and stories to reinforce the concept. For instance, I often ask my audience in autumn, how many in the classroom know precisely what they are going to do for Christmas eve. At best I have a couple of people saying they do and all the other ones showing uncertain faces. If I ask how many have a rough idea of what they are going to do, most hands come up. And all in all, we all know that Christmas will come and that we’ll do something special on the 24th and 25th. Interestingly, you will notice that nobody is seriously contemplating the idea to postpone Christmas because we would not be ready. So, we deal with it!
I often use another example and ask my delegates to plan a year long trip around the world to start in 3 months time. To keep a long story short, we always end-up with at best a planned trip for the first weeks and a lot of unknown to adapt to the situation. I never had the case of someone describing week by week what they will be doing, visiting, and where they will be sleeping or what transportation they will use. But they can all assure that they [...]