Year 10 · ICT · Spring 2 · The systems life cycle; presentations

Documentation and evaluation

TheoryPresent ▶

What this lesson covers

7.5 Documentation

Cambridge IGCSE ICT 0417 · Topic 7: The systems life cycle · Paper 1

7.6 Evaluation

Cambridge IGCSE ICT 0417 · Topic 7: The systems life cycle · Paper 1

You will learn to

Explain the difference between technical documentation and user documentation.
List what goes in each type of documentation.
Evaluate a system against the original user requirements.
Suggest improvements based on user feedback.

Success criteria

I can sort ten items into technical or user documentation.
I can write three evaluation points about efficiency, ease of use and appropriateness.
I can link each improvement to a limitation that users found.

The syllabus points for these sections

Explain the difference between technical documentation and user documentation.
List the components of technical documentation.
List the components of user documentation.
Evaluate a system for efficiency, ease of use and appropriateness.
Compare the final system with the original user requirements.
Use user feedback to identify limitations and improvements.

Key words

Say each word, then read what it means. Every one is in the glossary too.

Questionnaire: A set of written questions given to many people to collect their views.
System specification: A list of the hardware and software the new system needs.
Field: One item of data in a record, such as Surname.
Coding of data: Storing short codes such as M or F instead of whole words.
Validation: An automatic computer check that data is sensible and allowed.
Check digit: An extra digit calculated from the other digits, used to detect input errors.
Data capture form: A paper or on-screen form used to collect data.
Test plan: A table listing each test, its data, the expected and actual outcomes and any remedial action.
Live data: Real data from the organisation, used to test the system with known results.
Evaluation: Judging the finished system against the original requirements after it has been used.

The explanation

Read it here, or open the study page below to go one step at a time with things to try.

7.5 Documentation

Technical documentation

Technical documentation is written for programmers and analysts who maintain, repair or upgrade the system later.

It explains how the system was built, so someone new can understand it without asking the original team.

Technical documentation contains	Why it is needed
Purpose of the system and its limitations	To know what it does and does not do
Program listing / coding and the programming language used	To find and change code
Program flowcharts or algorithms, and system flowcharts	To see the logic quickly
Hardware and software requirements	To install it on new machines
File structures (field names, data types, lengths)	To change or extend the data
List of variables and validation rules	To understand checks and avoid breaking them
Input and output formats	To change forms or reports
Sample runs and test results (test plan)	To retest after changes
Known bugs, meaning of error messages	To fix faults
Minimum memory and storage, operating system	To check compatibility

User documentation

User documentation is written for the people who use the system every day. It avoids technical words.

It may be a printed guide, a help file, a video or an online FAQ page.

User documentation contains	Example (library system)
Purpose of the system and its limitations	Records loans; cannot order new books
Hardware and software needed	Windows PC, barcode reader
How to load, run, save, print, log in and log out	'Click Start loan, scan the student card'
Input formats and output formats, with screenshots	What the loan screen looks like
How to add, delete, sort and search records	'To find a member, type the surname'
Meaning of error messages	'ID not found' means the card is not registered
Troubleshooting guide	'If the scanner beeps twice, rescan'
Frequently asked questions (FAQs)	'How do I extend a loan?'
Glossary of terms and an index	'Overdue: past the return date'
Tutorials	Step-by-step first loan

!Watch out

Some items appear in both lists, such as purpose, limitations and hardware needs. In an exam, if asked for user documentation, avoid items only a programmer would need, such as program listings.

7.6 Evaluation

What evaluation checks

Evaluation happens after the system has been in use for a while. It asks: does the new system do the job well?

Efficiency: is it faster or cheaper than the old system? Does it use fewer resources?

Ease of use: can staff use it with little training? Do they make fewer mistakes?

Appropriateness: is it the right solution for this organisation and its problems?

e.g.Example

Library evaluation after one term: A loan now takes 12 seconds (requirement: under 30 seconds). Met. Overdue books fell from 63 a month to 18. Improvement. Two librarians find the reports menu confusing. Ease-of-use problem.

How it is done and what comes next

The analyst compares the final system with the original user requirements from the analysis stage, one by one.

The analyst gathers user feedback by interviews and questionnaires, and compares results from the test plan.

Any limitations found are listed, with improvements to fix them. This may start the life cycle again.

?Why?

The requirements written in analysis are the yardstick. Without them, there is no fair way to say whether the system succeeded.

!Watch out

Evaluation is not testing. Testing happens before the system goes live. Evaluation happens after it has been used for real.

Study it

Open the study page and go one step at a time.

ICT topic 7

Check yourself

One question at a time. The reason shows after each answer.

Saved on this device.