The Business Context

In the following highly simplified view of the requirements process I feature three organisational elements:

1. The business, from which we elicit requirements.
2. The engine room, where we schedule and resource – and re-schedule, continuously.
3. The test area, where we verify the requirements.

The engine room can be full of activity and stress. We are assured, if not reassured, by the engine room that everything is under control, everything is being done properly. We are told that they don’t have enough staff, but, thanks to their (heroic) efforts, everything is just fine.

The metrics from the test area seem to tell a different story. There are literally hundreds of requirements related incidents representing waste, scrap and re-work. So what’s gone wrong?

To answer this question it can be worth examining the business end. Are projects are being kicked off with an adequate appreciation of the business context? Is the business problem well understood? What about the business goals? The business priorities? The list of questions could obviously go on and could be lifted from any text book on requirements engineering.

So, nothing revolutionary here, but the reality is that this is so often where things start to go badly – from the outset. If we understand the business problem that supposedly gave rise to project then we have some chance of coming up with a solution that will be satisfactory to the business. We will also have a chance of identifying readymade solutions in the market place or even of realising that someone else is already working on that same problem. If we understand the business priorities we have some chance of resolving issues of resource shortage. Again, the list goes on.

Whether our approach is Agile, Waterfall or something else, I suggest that we need to understand the business context. I think that this will always be true. Whether our requirements project is starting from a study of the business or whether we are simply being given a set of product requirements it is always useful to have some understanding of the business context, the problems, objectives and goals, scope, stakeholders, priorities and issues. And if we not given it, I suggest we make efforts to discover it for ourselves.

See also stages 2 and 3 of Capiro’s 8 Steps to Requirements Success for a view on the same topic.