Know and understand the need to identify the inputs, outputs and processing of the current system, problems with the current system, the user and information requirements for the new system

7 – The Systems Life Cycle (SLC)

7.1 Analysis – Understanding the current system

7.1.1 Why analyse the current system?

Before a new computer‑based solution can be designed, the existing (often manual) system must be fully understood. The analysis provides the foundation for:

• Identifying what works well and what does not.
• Determining the exact data that must be captured (inputs) and the results required (outputs).
• Describing the processing steps that transform inputs into outputs.
• Gathering the users’ expectations and the information that the new system must provide.
• Producing a clear system specification – a document that records the findings and forms the reference for later stages.

7.1.2 Current‑system documentation

7.1.3 Problem categorisation (syllabus requirement)

Problems are usually grouped into three categories. For each problem note the impact and possible cause.

• Technical problems – data loss, lack of backup, poor data integrity.
• Organisational problems – duplicated work, bottlenecks, lack of standard procedures.
• Human problems – user fatigue, high error rates, resistance to change.

7.1.4 User requirements (AO2 – produce ICT solution)

Write requirements in plain, testable language. Use the template below:

7.1.5 Information requirements (data‑type, format, quality)

• Data types: text, integer, decimal, date, Boolean.
• Data format: dates in YYYY‑MM‑DD; currency with two decimal places.
• Data quality:

  • Mandatory fields – must be completed.
  • Validation rules – e.g. 0 ≤ Quantity ≤ 10 000.
  • Uniqueness – primary key values must be unique.
  • Check‑digit or checksum for IDs.

• Reporting needs: summary totals, trend graphs, drill‑down detail screens, printable PDF version.

7.1.6 Analysis checklist (syllabus checklist)

7.2 Design – Translating requirements into a solution

7.2.1 File‑structure design (syllabus expects primary/foreign keys)

For each logical file list the fields and their attributes.

7.2.2 Input‑screen design (validation checklist)

• Layout: logical order, clear labels, grouping related items, tab‑order consistent.
• Controls: drop‑down lists, radio buttons, check boxes, date pickers, numeric spin boxes.
• Validation taxonomy (syllabus requirement):

  • Presence – mandatory fields cannot be left blank.
  • Range – numeric values must fall within defined limits.
  • Type – only numbers, dates, or text as specified.
  • Length – maximum character count.
  • Format – e.g. email must match user@domain.com.
  • Check‑digit – for IDs such as StudentID.

• Example of a validation rule: IF (Quantity < 0 OR Quantity > 10000) THEN display “Quantity must be between 0 and 10 000”.

7.2.3 Output‑design

• Screen output: headings, column alignment, colour coding for warnings, pagination.
• Printed reports: title, page number, column headings, totals, footers with date and author.
• Export formats: CSV for spreadsheets, PDF for official documents, XML for data exchange.

7.2.4 User‑interface (UI) layout & accessibility (AO3 – evaluate)

• Consistent navigation – menu bar, breadcrumb trail, “home” button.
• Icons with tool‑tips; text alternatives for screen‑reader users.
• High‑contrast colour scheme, scalable fonts, keyboard shortcuts (e.g., Alt+S to save).
• Compliance with WCAG Level A (text equivalents, focus order, error identification).

7.2.5 Security controls (syllabus expects a checklist)

7.2.6 Backup & recovery plan (syllabus requirement)

• Backup frequency: full weekly backup, incremental daily backup.
• Media: external hard‑drive (offline) and cloud storage.
• Retention: keep backups for 6 months.
• Recovery procedure:

  1. Verify backup integrity.
  2. Restore latest full backup.
  3. Apply incremental backups in chronological order.
  4. Run test restore on a separate server.

7.2.7 Design checklist (covers all syllabus artefacts)

7.3 Development & Testing

7.3.1 Test plan (AO2 – apply life‑cycle stages)

7.3.2 Testing types (syllabus checklist)

• Unit (module) testing – test individual routines or screens in isolation.
• Integration testing – verify that modules work together (e.g., data entry → database → report).
• System testing – end‑to‑end test of the whole solution against user requirements.
• Acceptance testing – carried out by the client to confirm the system meets the agreed specifications.

7.3.3 Testing checklist

7.4 Implementation – Moving the new system into operation

7.4.1 Implementation methods (syllabus expects description of each)

7.4.2 Data migration plan (syllabus requirement)

1. Extract data from the legacy system into a CSV file.
2. Map old fields to new file‑structure (e.g., OldCustID → Customer.CustomerID).
3. Validate data against new constraints (mandatory, format, range).
4. Load cleaned data into the new database using import scripts.
5. Run reconciliation reports to verify record counts and totals.

7.4.3 Training & support (AO2 – produce solution)

• Training schedule – classroom sessions, e‑learning modules, on‑site practice.
• Training materials – user guide, quick‑reference cards, video tutorials.
• Support arrangements – help‑desk phone/email, on‑site technician for the first two weeks.

7.4.4 Implementation checklist

7.5 Documentation

7.5.1 Technical documentation (for developers/maintainers)

• System overview – purpose, scope, hardware/software requirements.
• Detailed file structure (field definitions, keys, indexes).
• Flowcharts or pseudocode for major processes.
• Data‑validation routines and algorithms.
• Security procedures (authentication, authorisation, audit).
• Backup, recovery and disaster‑recovery procedures.
• Test plan and test‑case results.

7.5.2 User documentation (for end‑users)

• Getting started – login, basic navigation.
• Step‑by‑step procedures (e.g., “Enter a new order”).
• Screen screenshots with labelled fields.
• Explanation of error messages and how to correct them.
• FAQ and troubleshooting guide.

7.5.3 Documentation checklist (syllabus expects both technical & user manuals)

7.6 Evaluation – Did the new system meet its aims? (AO3 – evaluate)

7.6.1 Evaluation criteria (syllabus expects efficiency, effectiveness, usability, appropriateness, security)

• Efficiency – faster processing, reduced paperwork, lower operating cost.
• Effectiveness – accurate, complete outputs; meets all user requirements.
• Usability – meets training‑time target, low error rate, positive user feedback.
• Appropriateness – fits organisational procedures and future growth.
• Security – data protected, backups reliable, audit trail functional.

7.6.2 Evaluation checklist

Review of Coverage Against the Cambridge IGCSE 0417 Syllabus