[Jump to start of article]

Home > Requirements > User Requirements

User Requirements

A good set of user requirements are needed for any project, especially computer system projects, to be successful. This is where many projects fail, in that they do not specify correctly what the system should do. In fact many systems have just been given a deadline for delivery, a budget to spend, and a vague notion of what it should do.

The root of this problem is:

As a result paralysis sets in and business management time is concentrated on meeting timescales and budgets, rather than what is going to be delivered.

Requirements Definition

The truth is that you do not need a great deal of technical knowledge to specify requirements; in fact it can be a big disadvantage. A requirement for a computer system specifies what you want or desire from a system. For a business in particular this is, "What you want or desire from a system, which you believe will deliver you a business advantage".

This advantage need not just be a reduction in costs, in fact many systems justified on a reduction in operating costs, fail to deliver as low skilled but relatively cheap staff, have to be replaced by high skilled, and more expensive staff. The advantage can be a reduction in time to process something, which will lead to a reduction in costs, or being able to better use the unique knowledge base belonging to a business.

As you start to specify what you want or desire, you hit up against technical language of requirements. Fear not, this is quite straightforward:

Functional Requirements

These are the type of behaviour you want the system to perform. If you were buying vehicles for a business your functional requirement might be:

Similarly for a computer system you define what the system is to do. For example:

The important point to note is that WHAT is wanted is specified, and not HOW it will be delivered.

Non-Functional Requirements

These often lead to much mystical mumblings, implying that a high priest of the computing fraternity is the only person who can understand them. They are however quite simple; they are the restrictions or constraints to be placed on the system and how to build it. Their purpose is to restrict the number of solutions that will meet a set of requirements. Non-functional requirements can be split into two types: performance and development.

Performance Constraints

These constraints are how the system should perform when it is delivered. The vehicle example, without any constraints, might result in solutions being offered for everything from a large truck to a sports car. To restrict the types of solutions you might include these performance constraints:

You may include more. Similarly for a computer system you might specify values for these generic types of performance constraints:

For the customer records example these might be:

The important point with these is that they restrict the number of solution options that are offered to you by the developer. Performance Testing is used to prove these have been met.

Development Constraints

In addition to the performance constraints you may include some development constraints. These mainly fall in the field of project management, but are still a restriction on the types of solution that can be offered. There are three general types of development constraint:

Design Objectives

Design objectives assist in selecting a solution from a number that are offered to you. Only you know what is the most important feature of a new system, whether it should be fast, have large storage, be easy to use, or whatever. Unfortunately you can’t have all you want; compromises have to be made.

Experiments with teams of developers in the 1970's showed that they will deliver a system according to what is defined as the top design objective. A number of teams were given an identical set of functional requirements, but each had a different design objective: some had to make the system fast, some small to use only a small amount of computer storage, some easy to use, etc. Each team delivered a system that met their top objective fully, and other objectives to a lesser degree.

If you do not produce a set of design objectives, which are in a priority order, the developers will produce their own, and these might not be what you want. For the customer records example the top design objective could be that it easy for users to find customer information.

Requirements to Avoid

The above are all good types of requirements and will allow a development team to provide you with a number of options from which you can select a suitable solution. However many sets of requirements given to developers are polluted with design and implementation solutions. This means that the customer has told the developer how to conduct their business!

Examples of design solutions are:

Examples of implementation solutions are:

Each of these says HOW the system should be built, not WHAT the design should deliver, and you may miss out on a better solution, due to you making these design decisions.

There may be good reasons for some of these statements, but until you have seen a number of designs, you do not know if they are valid for you.

Prioritising Requirements

When a set of requirements has been produced it is often large and complex. The realities of times scale and resource mean that it won't all be delivered, at least not the first time out. The customer should prioritise the requirements to specify what they most want, and what is nice to have. A method of doing this is the MoSCoW technique. If the customer does not prioritise then it will be done by the developers, who may select the parts of the process which are easiest to produce, or that are technically challenging, but not taking into account the needs of the organisation.


A good set of use requirements consists of prioritised sets of:

And does NOT have any design or implementation decisions.

Producing these will enable you to get systems that will deliver a business advantage.

Requirement Issues