Evaluation

 

 

Once the new system has been implemented and is in full use, the system should be evaluated (this means that we take a long, critical look at it).
The purpose of an evaluation is to assess the system to see if it does what it was supposed to do, that it is working well, and that everyone is happy with it.

What Does an Evaluation Look For?

When the systems analyst evaluates the new system, the following questions will be asked:

Is the system efficient?

Does it operate quickly, smoothly and with minimal waste?

Is the system saving time, and resources?

Is the system easy to use?

Are all of the system's users able to use the system easily and effectively?

Can new staff understand and use the system with minimal training?

Is the system suitable for that particular business / organisation?

Does the system actually meet the needs of the business / organisation?

How is a System Evaluated?

The systems analyst will use a number of techniques to evaluate the system...

Check against the Requirements Specification

If you remember, earlier on in the Systems Analysis, the old system was analysed, and a checklist of targets was drawn up for the new system.

This list was called the Requirements Specification.

The systems analyst will use this document to check the new system. Going through the requirements one-by-one the analyst will check if they have been met.

 

Check the Users' Responses

It is essential to get feedback from the users of the system...

• Do they like it?
• Does it make their work easier?
• What, if anything, could be improved?

The systems analyst can get this feedback in the same way they collected information about the original system.

 

What Happens Next?

The outcome of the evaluation will be to identify any limitations or problems with the new system.

The system analyst will then need to begin the task of system analysis from the beginning, but this time analysing the new system, and then designing, testing and implementing improvements.

Thus the whole process repeats.

 

 

Documentation

Documentation

 

There are two types of documentation that should be produced when creating a new system:

• User documentation
• Technical documentation

 

User Documentation

The user documentation is intended to help the users of the system.

The users are usually non-technical people, who don't need to know how the system works. They just need to know how to use it.

User documentation usually includes:

• List of minimum hardware and software required to use the system
• How to install the system
• How to start / stop the system
• How to use the features of the system
• Screenshots showing the system in typical use
• Example inputs and outputs
• Explanations of any error messages that might be shown
• A troubleshooting guide

 

Technical Documentation

The technical documentation is intended to help the maintainers of the system (the people who need to keep the system running smoothly, fix problems, etc.)

The maintainers are usually technical people, who need to know exactly how the system works.

Technical documentation usually includes:

• Details of the hardware and software required for the system
• Details of data structures (data types, field names, etc.)
• Details of expected inputs
• Details of validation checks
• Details of how data is processed
• Diagrams showing how data moves through the system
• Flowcharts describing how the system works

 

 

Implementation