Know and understand input formats including data capture forms

Systems Life Cycle – Input Formats & Data Capture Forms

Objective

By the end of this lesson students will be able to:

• List and describe the eight stages of the Systems Life Cycle (SLDC) and the key activities in each stage (AO3).
• Identify and evaluate different input formats used to capture data.
• Design a data‑capture form that meets the requirements of the analysis and design phases.
• Explain how testing, implementation, documentation, maintenance and evaluation fit into the SLDC.
• Apply e‑safety, data‑protection and audience‑analysis principles when creating input solutions.

1. The Systems Life Cycle (SLDC)

2. Analysis (Stage 2)

Output Checklist for Analysis (AO1)

• Requirements list (functional & non‑functional).
• Process map / flow‑chart of the current system.
• Preliminary data‑dictionary (field names, types, lengths).
• Stakeholder & audience analysis summary.

3. Design (Stage 3)

3.1 File / Data Structures

• Decide field names, data types (text, numeric, date, Boolean), field length, coding (e.g., “Y/N”).
• Produce a full data‑dictionary (see example below).

Sample Data‑Dictionary

3.2 Input Format Selection

• Paper questionnaire
• Online web form
• Barcode / QR scanner
• OCR (scanner + software)
• Voice / speech recognition
• Touchscreen / pen input

3.3 Validation Routines

• Mandatory field (required)
• Data‑type check (numeric, date, Boolean)
• Range check (e.g., 0‑100)
• Length check (exact or maximum characters)
• Format check (e.g., email pattern, postcode format)

Validation Rule – AO2 Mapping

3.4 Usability Considerations

• Logical field order and grouping.
• Clear, concise labels and help text.
• Tab order for keyboard navigation.
• Colour contrast and font size for readability.
• Accessibility tags (e.g., label elements) for screen readers.

4. Development / Construction (Stage 4)

4.1 Building a Form in a Mainstream Office Suite (LibreOffice Writer)

1. Open LibreOffice Writer → View → Toolbars → Form Controls.
   
2. Insert a Text Box for each data field (e.g., First Name, Last Name). Right‑click → Control → set Name, Maximum Length, and Mandatory properties.
3. Insert a Combo Box for “Course Selection” and define the list entries (ICT, Mathematics, Science).
4. Add a Date Field for Date of Birth and set the required format (YYYY‑MM‑DD).
5. Place a Push Button labelled “Submit”. In the Events tab, assign a macro that validates the fields and writes the data to a CSV file.
6. Save the document as .odt for editing and export as .pdf for distribution if a static form is required.

4.2 Creating an HTML Web Form (quick reference)

<form action="register.php" method="post">
<fieldset>
<legend>Personal Details</legend>
<label for="fname">First name:</label>
<input type="text" id="fname" name="first_name" required maxlength="30"><br>
<label for="lname">Last name:</label>
<input type="text" id="lname" name="last_name" required maxlength="30"><br>
<label for="dob">Date of birth:</label>
<input type="date" id="dob" name="dob" required><br>
</fieldset>
<fieldset>
<legend>Course Selection</legend>
<label for="course">Choose a course:</label>
<select id="course" name="course">
<option value="ICT">ICT</option>
<option value="MATH">Mathematics</option>
<option value="SCI">Science</option>
</select>
</fieldset>
<input type="submit" value="Submit">
</form>

5. Testing (Stage 5)

Testing checklist for a data‑capture form

1. Prepare normal test data that satisfies all validation rules.
2. Prepare abnormal data (e.g., letters in a numeric field, missing mandatory fields).
3. Prepare extreme data (e.g., maximum field length, dates far in the past/future).
4. Execute each test case, record the system’s response and any error messages.
5. Confirm that valid data is stored correctly in the database or file.
6. Log defects, correct them, and retest until all cases pass.

6. Implementation (Stage 6)

• Direct change‑over – switch off the old system and start the new one immediately.
• Parallel – run old and new systems side‑by‑side for a defined period.
• Pilot – introduce the new system to a small, representative group first.
• Phased – roll out the system module by module or site by site.

7. Maintenance (Stage 7)

• Monitor system performance (response times, error logs).
• Fix bugs and apply security patches or software updates.
• Implement minor enhancements (e.g., adding a new drop‑down option).
• Maintain version control – keep a change‑log and archive previous releases.
• Update technical and user documentation to reflect changes.
• Example: Applying a monthly patch to a school‑management system to address a newly discovered SQL‑injection vulnerability.

8. Documentation (Stage 8)

• Technical documentation – data‑dictionary, field specifications, validation rules, hardware configuration, installation guide.
• User documentation – step‑by‑step guide, screenshots, FAQs, troubleshooting tips.
• Store both securely (e.g., on the school intranet) and keep them up‑to‑date after maintenance.

9. Evaluation (Stage 9)

Assess the input solution against the three AO3 criteria:

10. Safety, Security & Data Protection

• Use strong passwords; encrypt stored data where appropriate.
• Apply access controls – only authorised staff may view or edit captured data.
• Comply with data‑protection legislation (GDPR‑style principles): obtain consent, keep data only as long as necessary, provide a privacy notice.
• Validate input to prevent injection attacks or malformed data.
• Back‑up data regularly and store backups securely (off‑site or cloud).

11. Audience Analysis & Communication

• Identify primary users (age, language, technical skill, accessibility needs).
• Adapt form language, layout and input devices accordingly (e.g., larger fonts for older users, pictograms for young learners).
• Choose appropriate communication media when presenting the solution – email, intranet posting, printed hand‑outs – and observe netiquette.
• Include copyright statements for any reused graphics or code.

12. Input Formats – How Data Is Captured

13. Data Capture Forms

13.1 Types of Forms

• Static paper forms – pre‑printed, used where electronic devices are unavailable or impractical.
• Dynamic electronic forms – built with HTML, XML, or specialised form‑building tools; can include client‑side validation, auto‑complete and conditional fields.

13.2 Elements of a Good Form

• Clear headings and logical sections.
• Logical field order that follows the natural flow of information.
• Appropriate field types (text box, drop‑down, radio button, check‑box, date picker).
• Input validation (required, data‑type, range, format).
• Instructions, examples and tool‑tips to reduce ambiguity.
• Accessibility features – label tags, tab order, high‑contrast colour scheme, screen‑reader friendly markup.
• Consistent naming convention for fields (e.g., student_id, dob).

13.3 Example: Simple Student Registration Form (HTML)

<form action="register.php" method="post">
<fieldset>
<legend>Personal Details</legend>
<label for="fname">First name:</label>
<input type="text" id="fname" name="first_name" required maxlength="30"><br>
<label for="lname">Last name:</label>
<input type="text" id="lname" name="last_name" required maxlength="30"><br>
<label for="dob">Date of birth:</label>
<input type="date" id="dob" name="dob" required><br>
</fieldset>
<fieldset>
<legend>Course Selection</legend>
<label for="course">Choose a course:</label>
<select id="course" name="course">
<option value="ict">ICT</option>
<option value="math">Mathematics</option>
<option value="science">Science</option>
</select>
</fieldset>
<input type="submit" value="Submit">
</form>

13.4 Testing the Form (Development & Testing Stage)

1. Enter valid data – confirm that the form submits and data is stored correctly.
2. Leave a required field blank – verify that an error message appears.
3. Enter a non‑numeric value in a numeric field – verify format validation.
4. Enter data that exceeds the maximum length – check that the system truncates or rejects it.

14. Choosing the Right Input Format

Use the following decision‑making criteria during analysis and design:

1. Volume of data – High volume → scanners, barcode readers, OCR.
2. Accuracy required – Critical accuracy → validation, barcodes, OCR with verification.
3. Cost & resources – Low budget → paper forms; higher budget → electronic solutions.
4. User skill level & audience – Choose devices familiar to the target group.
5. Environment – Mobile/field work → handheld scanners or voice input.
6. Security & privacy – Sensitive data → encrypted online forms, restricted access.

15. Advantages & Disadvantages Summary