Specifying, choosing and implementing computer systems

Stage 3 – Summarise and specify system requirements

Consolidate output requirements

This is a very important stage of the selection process. At this stage you should have one spreadsheet (SS 2-2) which brings together all the information requirements identified by the users and allocates these to the activities and tasks which will also have been identified. In order to produce a logical system it will probably be necessary to make changes to both activities/tasks (SS 2-1 Tasks) and objectives/information (SS 2-2). Some minor tasks (for example moving stock between locations) may not have been identified. It may also be useful to draw flowcharts to show how the tasks, information and databases are linked. (SS 3-1).

Since the software will be structured by activity/task the objectives/information data (SS 2-2) will be sorted by activity and task. It is this spreadsheet which will drive the selection of shortlisted software and the detailed testing of this software.

You may at this point be wondering why the Project Manager doesn't analyse the existing system and draw up the requirements from them without bothering about all the objectives. The problem with this approach is that it will just replicate the existing systems with a few improvements; there will be no allowance for the aspirations of users. In our example, we might not include the need to operate from several locations.

Purchasing software

You will now be in a position to understand what is required of the new system. The next stage is to put together about 10 essential requirements - that is the features the system should have without which you won’t consider it (SS 4-1). This helps to eliminate some packages immediately and enables you to draw up a shortlist. These requirements should include cost. They should also include essential features which might not be standard in the packages being considered, for example: a separate despatch address for each invoice; the ability to generate suggested orders, taking into account supplier lead times.

These essential requirements can be extracted from the requirements spreadsheet by a small group representing the users.

If you can't meet all the requirements of all the users you need to consider which will have to be dropped and discuss this with users in order to manage expectations. There may be alternative ways to produce the information they require, such as extraction into spreadsheets or other packages. This you can then build these in to the overall plan.

Developing software in-house

If you are building a system, you should now be able to design the database structure from the information requirements. The data items required for the output can be included as a column in the Requirements Spreadsheet (SS 2-2). These data items can then be linked to the users who are able to provide it. Knowing the data required and the users, you can design the input screens and test their practicality by writing the manual. Since you also know the users, you can design the technical infrastructure required.

Additional analysis

However, life isn’t usually easy and some system requirements, and possibly users, may have been missed. For complex systems it may also be useful to:

 List all input forms currently in use and link these to related tasks

 List all output reports currently in use and link these to related tasks

 Document current systems to compare them with the proposed systems

 Reference the current input/output/systems to the proposed systems to ensure requirements are met.

The time you spend analysing the existing systems will depend on how closely you wish to replicate those systems. I would be reluctant to spend too much time, since you will be replacing them with something which is, hopefully, better. Concentrate on:

 Delivering information which will enable users to fulfil their objectives effectively (SS 2-2).

 Managing the risks which threaten the achievement of these objectives (SS 1-9).

Advantages of this method

This process of detailing output is very time consuming BUT:

 It will have to be done at some time.

 Users, and their requirements, are identified early in the project. They therefore will feel more involved and supportive. If any of their expectations will not be met, they can be managed.

 The method is based on the users’ objectives, which should be clearly understood. It avoids the general question, ‘What do you want from the new application’ which users find too general, especially if they don’t clearly understand what the application will do.

 The requirements are based on what users need to achieve their objectives, not what is done at present plus a few enhancements. It may therefore result in requirements not usually specified, such as materials asked for by customers but not sold.

 The earlier that planning is done, the more time that is saved later in the project making adjustments for requirements missed in the initial planning.

 There is a greater chance of the application you choose meeting your requirements and, just as important, you will know where it doesn’t.