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:
- Computer systems developers rarely have as good an idea of how a business runs and should run, compared with a business user,
- Business users have little idea of what a computer system could achieve for them.
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 - are what you want a system to do.
- Non-functional requirements - are restrictions on the types of solutions that will meet the functional requirements.
- Design objectives - Are the guides to use in selecting a solution.
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:
- The vehicle should be able to take a load from a warehouse to a shop.
Similarly for a computer system you define what the system is to do. For example:
- The system should store all details of a customer’s order.
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:
- It must take a load of at least one ton.
- The load area must be covered.
- The load area must have a height of at least 10 feet.
You may include more. Similarly for a computer system you might specify values for these generic types of performance constraints:
- The response time for information to appear to a user.
- The number of hours a system should be available.
- The number of records a system should be able to hold.
- The capacity for growth of the system.
- The length of time a record should be held for auditing purposes.
For the customer records example these might be:
- Information should be made available and be stored in a maximum of 3 seconds.
- The system should be available from 9am to 5 pm Monday to Friday.
- The system should be able to hold a 100,000 customer records initially.
- The system should be able to add 10,000 records a year for 10 years.
- A record should be fully available on the system for at least 7 years.
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:
- Time - When a system should be delivered is the obvious time constraint.
- Resource - How much money is available to develop the system is obvious, but a key resource would be the amount of time business staff could spend in briefing system development staff.
- Quality - Any standards which are used to develop the system including project management, development methods etc.
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:
- The system should run on our existing network of computers.
- The structure of a customer record must have a separate field for the first, and last names of a customer.
Examples of implementation solutions are:
- The customer record systems should run on a SQL database.
- The system should be built using the Java programming language.
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.
Conclusion
A good set of use requirements consists of prioritised sets of:
- Functional requirements,
- Non-functional requirements, and
- Design objectives.
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
- Characteristics of Good Requirements - eight characteristics and where they fit into communication, control and construction.
- MoSCoW Prioritisation - prioritising the user requirements and objectives of a project.