For many years now, every systems engineer has learnt that it is essential to write requirements for every system. These, we were told, had to be separated into User and System requirements. Or perhaps we learnt to write Functional and Technical requirements, which seemed to amount to much the same thing. And when it came to verification (on the right-hand or rising limb of the 'V-model'), there were two similarly two sets of acceptance tests, which seemed at best rather confusing.

Either way, we had in each case to produce two documents, both of which seemed to be overheads on the plain tasks of designing the system, coding the software, and testing it. I well remember the shamefaced look of a respected colleague many years ago as I accidentally caught him sticking back the write-protect tab on an old 5½" floppy: it was the requirements archive disk, and he was performing the necessary task of keeping the requirements consistent with the code, while also complying with the (impossible) demand to freeze the requirements before starting the design. A write-secretly tab was the only solution.

My aim here is not to add to the criticisms heaped on the naïve waterfall model (basically the left-hand, descending limb of the 'V') – it was a necessary stage in the evolution of a workable development life-cycle. Instead, I want to look at the first two steps of the life-cycle, and see what they are meant to achieve.

The system requirements are probably clearer in intention, so let us begin with them. They specify what the system is to do, and as everyone knows, they are not supposed to say how the system is to achieve those results – that is the job of the design. Incidentally, they do not consist only of system functions. It is equally important that the system complies with safety standards, or provides a given quality of service. No-one has ever succeeded in getting a universally agreed name for these extra things – Constraints is about the nearest – so we have to make do with rough-and-ready terms like Non-functional requirements or the informal '-ilities' (such as reliability and maintainability), or the loose 'Quality requirements'.

Assuming, then, that systems are specified by a combination of functions – the system enables someone to get such-and-such a result, and constraints – the system is unavailable for at most such-and-such an amount of time per year, then you might think that the job of specification was complete. But no; we are also supposed to write a user requirements document. As Ben Kovitz has so wittily said, this has all too often led tired engineers to write as follows:

Well, you don't need to be told (do you?) that a lot of time and paper is being wasted if your organisation is duplicating the requirements in that way.

What, then, are user requirements for? They can't be meant to specify systems! Instead, they should be saying what business users need, leaving the question of how those needs might be met. This should sound familiar: it is similar to the job of specifying a system, leaving aside for a moment the issue of how the system should be structured. In other words, the needs of the business should be defined as a problem that a system can solve.

Why do business users need something? They are evidently trying to follow some set of business processes in their work, and discovering that some of those processes are difficult to implement. Therefore the logical starting point for any statement of business needs is a business process model, comprehensive enough to cover the whole of the problem area – you can never model everything, and there is generally no reason to try. If you don't know what the processes in the problem area are, the users's needs will appear as a disconnected bunch of isolated complaints, or a confused wish-list.

When you have a simple (or even a simplistic) business process model, the users' needs will click into place: first he needs to do this, then they need to do that, and so on. The same goes for the business needs: when you have a simple and clear set of stories – first I want to do this, then that, then the next thing – then the system specification will be easy to understand, because each feature makes sense in terms of what the people need.

So, requirements mean very different things in different places:

A Business Process Model says what a business does. Such models are not requirements, but they provide a context for understanding requirements of all kinds.

Business Needs say what a business wants to be able to do, but currently can't, or at least, can't do easily, quickly, conveniently, and economically (this is where the constraints come in: ultimately they come from the business, just like system functions).

System Specifications say what a system must do, both in terms of its functions and in terms of the qualities or constraints that govern the delivery of those functions.

It should now be clear what was wrong with making the User and System requirements virtual copies of each other: the documents should be talking about business problem and system solution. All too often they both talk about the solution. This isn't surprising: engineers who work for a company that designs and makes systems, and who are only allowed to look at solutions, do not know the business problems and are not in a position to write user documents.

User or Business documents belong to businesses, not to engineers. If the problem domain is insurance, then the business needs must talk the language of insurance, and describe the insurance problems that the insurance workers are experiencing (they don't become 'users' until they get a system to use; the name 'users' betrays a system point of view). To system people, insurance people are '[problem] domain experts' as opposed to themselves, people expert in the solution domain.

Requirements engineers form a bridge between the worlds of people who use and people who make systems. We are in the curious position of scarcely ever owning the documents we handle – they belong either to one camp or to the other. The key task is to enable the needs to jump the divide. After that, all the tools and techniques of requirements management can be applied to try to ensure that the needs are fully satisfied: but all the effort is wasted unless the problem is correctly defined and communicated in the first place.

It is therefore crucial to separate out the job of defining the business need from the job of specifying the system. Both jobs are loosely called 'writing requirements' but I suggest that this dangerously glosses over two radically different activities: defining what people need, and finding a solution. If you want an unambiguous way of saying what should be going on in a development project, choose terms that make clear that problem and solution are different: Business Needs and System Specification, for example. Here is a redrawn and hopefully clearer version of the top levels of the life-cycle.

Finally, consider the purposes of the high-level verification documents. The acceptance tests are to demonstrate that the business needs have been met. The system tests are to show that the system works as specified. If the system specification exhaustively satisfies the business needs, then you could assume that showing the system worked would automatically show that the business needs would be met by the system. This would be a brave assumption. But that – and the whole problem of requirement traceability – is another story.

© Ian Alexander June 2001

Ben Kovitz, Practical Software Requirements, Manning, 1999