9.1 What are requirements for?

Why write requirements?

Short answer; communication.

Requirements communicate information between the person3 who needs something to the person providing that something. Ideally this communication is unambiguous and complete. That is, the provider never asks the questions, ‘what exactly does this requirement mean?’ or ‘what else do you need?’. Nor does the requester feel the need to ask, ‘can we just add…’ .

Requirements vary considerably in complexity. On a one man project it is common for no requirements to be written. There is no communication problem, as both the requester and the provider are the same person4 the requirements can change without notice, there is no need to be specific, there is no problem of ambiguity (or at least the resolution of ambiguity is simple).

On a project with multiple participants the need for clear durable communication increases in proportion to the number of participants (one argument for small teams). One requester and one provider can likely be dealt with informally. Projects tend to be small and communication can be as regular and close as the two participants desire. Once several requesters are involved it becomes essential for the provider to ensure that there is consensus among the requesters. Failing to do so is almost certain to degenerate into chaos as disagreements among requesters drive the provider mad as they pull in different directions.

These communications are compounded further when multiple providers are involved (exponentially so when those providers work in different organisations).

Communication operates over space and time so although it may seem pointless to document requirements when only two or three people are involved remember that in future you may be dealing with more people (not to mention the future selves of the original participants). These ‘future participants’ may benefit greatly from well documented requirements (not to mention the history of decisions made in reaching those requirements).

If you’re working in a team these requirements help to ensure everyone is working to achieve the same result. I think of requirements as guiding lines that specify the essential properties of the system. Within this specification we have plenty of room to be creative but when all is said and done we must meet this specification before all else. These requirements help ensure we are not wasting resources on unnecessary activity.

I want to stress here that looking back on these requirements we may see violations. This is because requirements change. It is likely that the requirements the project has now will change as the project progresses, so we expect the system to sometimes violate these early requirements. This is not a failure on our part, it is simply the way the world works; you cannot see beyond the horizon.

9.1.1 What drives requirements?

People!

Specifically people’s goals.

People have goals, these goals drive requirements that in turn drive the need for system development (new features on existing systems or new systems).

Let’s generalise this a little. Goals may be personal, ‘I want to…’ or collective, ‘we want to…’ . Collective goals often stem from business objective, e.g. ‘Increase sales 10% during the next fiscal year’ is a business objective that may motivate several people within an organisation to start a project and hence write some requirements.

3I use ‘person’ here but ‘agent’ or ‘entity’ may be more accurate because requirements may also be imposed on our project from systems or organisations that interact with our system, not just humans.

4There are, even in one person projects, at least two participants; you now and future you. I have certainly had future me running foul of past me’s laziness in not documenting properly.