Know and understand components of user documentation including purpose of the system, limitations of the system, hardware and software requirements, how to load/run/install software, how to save a file, how to print data, how to add records, how to d

Systems Life Cycle (SLC) – Documentation (Cambridge IGCSE/A‑Level)

This note summarises the documentation that must be produced for an ICT solution in accordance with the Cambridge Section 7 – Systems Life‑Cycle syllabus. It links each type of documentation to the relevant SLC stage and provides a complete template for user documentation and technical documentation.


7 The Systems Life Cycle – Overview

  1. Analysis (7.1)

    • Research methods – questionnaires, interviews, observation, and document analysis.
    • Produce a system specification covering:

      • Functional requirements (what the system must do)
      • Non‑functional requirements (performance, security, usability, etc.)

  2. Design (7.2)

    • Design file structures (tables, fields, relationships).
    • Define input and output formats (date, phone, currency, etc.).
    • Specify validation routines (range, type, length, format, presence, check‑digit).
    • Produce algorithms / flowcharts for each process (e.g., “Add Record”).

  3. Development & Testing (7.3)

    • Write / configure the program (source code, configuration files).
    • Create a list of variables (name, type, purpose, initial value).
    • Develop a test plan covering:

      • Live data (real‑world values)
      • Normal data (within expected range)
      • Abnormal data (invalid type, out‑of‑range)
      • Extreme data (boundary values)

    • Record results in a test‑case table (see example below).

  4. Implementation (7.4)

    • Select a change‑over method – direct, parallel, phased or pilot.
    • Carry out data conversion, user training and support.

  5. Documentation (7.5)

  6. Evaluation (7.6)

    • Compare the finished system with the original specification.
    • Identify limitations, suggest improvements and collect user feedback.

How the stages interconnect

The output of each stage becomes the input for the next. For example, the system specification from Analysis informs the file‑structure and validation design; the design produces test data for Development & Testing; the tested system is rolled out in Implementation, where user documentation is handed to end‑users.


7.5.1 User Documentation – Components

  1. Purpose of the System

    A brief statement of why the system exists and the problem it solves.

    “To record, retrieve and report student enrolment, attendance and assessment data for the school administration team.”

  2. Limitations of the System

    • Maximum file size – 10 MB per student record file.
    • Supported operating systems – Windows 7+, macOS 10.12+, Linux with X‑Window.
    • Functions not provided – no payroll or timetable module.

  3. Hardware & Software Requirements

    ComponentMinimumRecommended
    Processor1 GHz2 GHz or higher
    RAM2 GB4 GB
    Disk Space500 MB free1 GB free
    Operating SystemAny OS with GUI support (Windows 7+, macOS 10.12+, Linux)Latest stable release of the chosen OS
    Additional SoftwareJava Runtime Environment (compatible version)Latest Java Runtime Environment

  4. How to Load / Run / Install the Software

    1. Obtain the installer (download from the official website or insert the media).
    2. Run the installer:

      • Windows – double‑click setup.exe
      • macOS – double‑click .dmg and drag the app to the Applications folder
      • Linux – extract .tar.gz and run install.sh

    3. Follow the on‑screen prompts:

      1. Accept the licence agreement.
      2. Choose the installation folder (default is fine for most users).
      3. Click Install.

    4. When installation finishes, click Finish. Launch the program from the desktop shortcut or system menu.

  5. How to Save a File

    1. Choose File → Save or press Ctrl+S (⌘+S on macOS).
    2. In the Save dialog, navigate to the desired folder.
    3. Enter a meaningful name (e.g., StudentData_2025.csv) and select the correct file type.
    4. Click Save. A confirmation message will appear.

  6. How to Print Data

    1. Select the data or report to be printed.
    2. Press Ctrl+P (⌘+P) or choose File → Print.
    3. In the Print dialog set:

      • Printer
      • Number of copies
      • Orientation (portrait/landscape)
      • Paper size

    4. Click Print. A status window confirms completion.

  7. How to Add, Edit and Delete Records (example: school‑management system)

    1. Add a record

      1. Open the Students module.
      2. Click New Record.
      3. Enter data in each field (see Input Format).
      4. Click Save. Message: “Record added successfully”.

    2. Edit a record

      1. Select the required record from the list.
      2. Click Edit.
      3. Modify the necessary fields.
      4. Click Update. Message: “Record updated”.

    3. Delete a record

      1. Select the record.
      2. Click the Delete icon.
      3. Confirm when prompted.

  8. Input Format

    • DatesYYYY‑MM‑DD (e.g., 2025‑11‑22)
    • Phone numbers+CC‑XXXX‑XXXX (e.g., +44‑1234‑5678)
    • Currency – numeric with two decimal places (e.g., 1234.56)
    • Student ID – 6‑character alphanumeric (e.g., S12345)

  9. Output Format

    • PDF – official printed reports.
    • CSV – data exchange with spreadsheets.
    • HTML – quick preview in a web browser.

  10. Sample Run – Adding a New Student

    > Open Students module

    > Click “New Record”

    > Enter: Name = “Alice Brown”

    > Enter: Student ID = “S1023”

    > Enter: Date of Birth = “2008‑04‑15”

    > Enter: Phone = “+44‑0200‑123456”

    > Click “Save”

    [System] Record added successfully.

  11. Error Messages

    Error CodeMessagePossible Cause
    ERR001Invalid date format.Date not entered as YYYY‑MM‑DD.
    ERR002Insufficient disk space.Less than required free space on target drive.
    ERR003Record already exists.Duplicate primary key (e.g., Student ID) entered.
    ERR004Invalid phone number format.Phone number does not match +CC‑XXXX‑XXXX.

  12. Error Handling

    • All input fields are validated before data are stored.
    • If validation fails, the offending field is highlighted in red and a tooltip explains the correction.
    • Critical errors write an entry to system.log and display a “Contact support” message.

  13. Troubleshooting Guide / Helpline

    1. Application fails to start

      • Check that the required Java Runtime Environment (or other runtime) is installed.
      • Verify that the system meets the minimum RAM and processor specifications.

    2. Unable to save a file

      • Confirm write permission for the destination folder.
      • Ensure sufficient free disk space.

    3. Printout is blank

      • Select the correct printer and verify that the driver is up to date.
      • Preview the document to ensure it contains data before printing.

    Helpline: 0800‑555‑1234 (Mon‑Fri 08:00‑18:00) or email support@example.com

  14. Frequently Asked Questions (FAQ)

    • Q: Can data be imported from Excel?

      A: Yes – save the workbook as CSV and use the “Import CSV” function.

    • Q: Is a mobile version available?

      A: A responsive web version can be accessed via a tablet or smartphone browser.

    • Q: How often are backups performed?

      A: Automatic backups run nightly at 02:00 am; users may also trigger a manual backup.

  15. Glossary of Terms

    TermDefinition
    Primary KeyUnique identifier for a record in a database table.
    CSVComma‑Separated Values – plain‑text format for tabular data.
    GUIGraphical User Interface – visual elements that allow users to interact with software.
    Log FileFile that records system events, errors and user actions for diagnostics.
    Validation RoutineProgrammed checks that ensure data entered meet required criteria (type, range, format, etc.).
    Change‑over MethodTechnique used to move from the old system to the new one (direct, parallel, phased, pilot).


7.5.2 Technical Documentation – Components (required for the syllabus)

  1. Program Listing / Source Code – annotated code or pseudo‑code showing the logical flow.
  2. Flowcharts / Algorithms – visual representation of each process (e.g., “Add Student Record”).
  3. System Flowchart – shows interaction between modules, databases and external devices.
  4. File Structure Diagram – tables, fields, data types and relationships.
  5. List of Variables – name, data type, purpose and initial value.
  6. Validation Routines – description of each check (range, type, length, format, presence, check‑digit) with example test data.
  7. Test Plan

    • Test‑case table (example below).
    • Expected results and actual outcomes.

  8. Change‑over Plan – steps for the chosen implementation method (e.g., parallel run schedule).
  9. Evaluation Report – analysis of how well the final system meets the original specification, identified limitations and user feedback.

Example Test‑Case Table (Development & Testing)

Test IDInput DataType of DataExpected ResultActual ResultPass/Fail
T001Student ID = “S12345”, DOB = “2008‑04‑15”NormalRecord added successfullyRecord added successfullyPass
T002Student ID = “12345” (no leading “S”)Abnormal (format)ERR003 – “Record already exists” or format errorERR003 displayedPass
T003DOB = “15‑04‑2008”Abnormal (date format)ERR001 – “Invalid date format.”ERR001 displayedPass
T004Phone = “+44‑123‑4567‑890” (too many digits)Extreme (length)ERR004 – “Invalid phone number format.”ERR004 displayedPass


Alignment with Cambridge Syllabus (Section 7)

  • 7.1 Analysis – research methods and specification are listed at the start of the note.
  • 7.2 Design – file structures, input/output formats, validation routines and flowcharts are explicitly covered.
  • 7.3 Development & Testing – source code, variable list, validation description and a full test‑case table are provided.
  • 7.4 Implementation – change‑over methods and a troubleshooting guide are included.
  • 7.5 Documentation – complete user and technical documentation components are detailed.
  • 7.6 Evaluation – evaluation report component and a reminder to compare the final system with the original specification are mentioned.