Download Insight (PDF) »

Many businesses remain blissfully unaware of ‘requirements’ as a discipline in its own right. Like Dr Johnson’s opinion of the performing dog: I am often not so much surprised that requirements are done badly, as that they are done at all.

In the early phases of software development projects, enthusiastic project managers often announce that they have ‘done the requirements’ and a weightyrequirements document is then produced. This usually amounts to little more than a senior management sponsored braindump of everything IT-related that they have been meaning to do for several years but have had neither the budget nor the political will to deliver.

Of course, as a consultant, I wouldn’t presume to know a client’s business better than they know it themselves. So why is it that they should know how to do ‘requirements’? Well, it is presumably to demonstrate to an IT consultant that they know how software development works, or else to shave a few weeks off the project duration to save some budget. In my experience neither really helps

the project and neither generally come to pass. Poorly-written requirements take time and effort to rescue, and DIY requirements often have the same consequences as domestic DIY efforts – shave a few millimetres off a table leg here, a few there, and you destabilise the whole undertaking. It is best left to the professionals.

So what is the underlying problem? I believe it is all to do with timing. Clients often leap-in at what they understand to be the start of a project with little critical questioning of either rationale or scope. They are solutionising - looking at perceived problems and designing solutions they think will fit. But tinkering around with your table legs is often a sign that there are bigger problems - maybe it’s the floor that’s uneven, maybe its woodworm. Thus it is the same with requirements. Business problems require business solutions that may or may not require a specific technical solution. The question we really should be asking is not “how can we solve this problem” but “what is the real problem”? What exactly is it that the business trying to achieve?

Defining the problem space may not be thought of as requirements engineering in the conventional sense. Engineering a solution, after all, demands that the problem has already been addressed. However, we have a responsibility to add value. One area where those engaged in requirements activities should certainly be adding value is in helping the business to define its own problem spaces. This

allows the business to understand the shape and fit of solutions which occupy those spaces.

Traditionally, strategy is the domain of the management consultants, and sometimes they can be very effective. However, at their worst, their output can be vague, poorly-qualified rhetoric that would give a skilled analyst sleepless nights. And of course strategy consultants are rarely responsible for delivery. This separation of strategy from the projects that are spawned by that strategy is divisive because it leads to projects (and particularly IT projects) being undertaken in isolation from ‘the business’.

Requirements managers are, however, naturally strategic and understand how projects contribute to the larger strategic aims, or goals, of the business. The problem is that we are usually engaged at a point where, at best, the strategy has already been set; and at worst, there is an absence of any strategy at all. We are brought in to ‘do the requirements’. However, our starting point should be to either align the project with a stated strategy or indeed to help define that strategy in the first place, and thus ensure that the business understands why

the project exists at all.

We help clients by positioning this work as an exercise in goal definition – the acknowledged realm of the requirements manager. Helping clients understand their goals has several advantages: firstly, it encourages clients to assess the project’s fit within their wider business strategy, which is good for them; and secondly, it enables equirements managers to position themselves at a level within the organisation above the middle managers who have been charged with delivering the project, which is good for us.

After all, we live and breathe this stuff. We have the unique ability to align these early deliverables (project goals) within the context of the wider business. Crucially, we are also responsible for defining what follows, be that solution, software or product development, to actually achieve those goals. By linking requirements to goals, we provide traceability back to the vision. We bridge the gap that often exists between vision and delivery, and hereby provide the continuity that is often lacking in projects.

This simplest of classifications – goals first, requirements later – allows us to position our work as strategic within the business. And strategy is generally ‘done’, or at least defined, at the senior management level. Gaining senior management buy-in allows the requirements manager to break out of middle management and gain that elusive ‘access all areas’ pass to roam freely across the business in later phases.

I find this tremendously uplifting in career terms. Requirements analysts and managers frequently originate from within the business analyst community and often struggle to move themselves up the food chain within the business. The perceived wisdom is that requirements managers may one day grow up to be project managers, but this is often far from the preferred career path for requirements analysts.

We must consider that a project manager can successfully deliver a project without ever having to think about ‘the vision’. I would argue that requirements analysts should constantly seek to align their work with the strategic direction of the business and strive to be the keeper of this vision. This is what sets us apart and it is an area where we can add real value to our clients’ or our own businesses.

This article appeared in Requirements Quarterly in March 2007