Know and understand designing file/data structures, input formats, output formats and validation routines

7. The Systems Life Cycle

Objective

Know and understand designing file/data structures, input formats, output formats and validation routines.

1. The Systems Life Cycle – Quick Overview

1. Planning – define the problem and feasibility.
2. Analysis – gather detailed requirements.
3. Design – create data structures, input & output formats, and validation rules.
4. Implementation – write code, build databases, and test.
5. Testing – verify that the system meets the specifications.
6. Maintenance – update and improve the system after deployment.

2. Designing File / Data Structures

A well‑designed data structure makes storage, retrieval and processing efficient. The key decisions are:

• Choose appropriate data types (numeric, alphanumeric, date, Boolean).
• Determine field lengths to avoid wasted space or truncation.
• Decide on a record layout – fixed‑length or variable‑length.
• Identify primary keys and any foreign keys for relational links.

Example – a simple student record file:

The total length of a fixed‑length record can be expressed as

\$L = \sum{i=1}^{n} li\$

where \$l_i\$ is the length of field \$i\$ and \$n\$ is the number of fields.

3. Input Formats

Input formats define how data is entered into the system. Considerations include:

• Source – keyboard, file upload, scanner, sensor, or external database.
• Structure – delimited (CSV, tab‑separated), fixed‑width, XML, JSON.
• Encoding – ASCII, UTF‑8, Unicode.
• Field order – must match the file structure or be mapped during import.

Typical input validation checks:

1. Presence – required fields must not be blank.
2. Data type – numeric fields contain only digits, dates follow a valid pattern.
3. Range – numbers fall within acceptable limits (e.g., 0 ≤ Score ≤ 100).
4. Length – text does not exceed the defined field length.
5. Format – email addresses contain “@”, phone numbers contain only digits and optional “+”.

4. Output Formats

Output formats present processed data to users or other systems. Choices depend on the audience and purpose:

• Screen display – tables, forms, dashboards.
• Printed reports – PDF, plain text, formatted Word documents.
• Data exchange – CS \cdot for spreadsheets, XML/JSON for web services.
• Graphical – charts, bar graphs, pie charts (described in a

  ).

5. Validation Routines

Validation routines are coded checks that enforce the rules listed above. A typical pseudo‑code routine might look like:

IF StudentID = "" THEN
DISPLAY "Student ID is required"
END IF
IF NOT ISNUMERIC(Score) THEN
DISPLAY "Score must be a number"
ELSE IF Score < 0 OR Score > 100 THEN
DISPLAY "Score must be between 0 and 100"
END IF
IF LEN(FirstName) > 20 THEN
DISPLAY "First name exceeds maximum length"
END IF

Key points for effective validation:

• Validate as early as possible – preferably at data entry.
• Provide clear error messages that tell the user what to correct.
• Use both client‑side (e.g., HTML5 pattern attributes) and server‑side checks for security.
• Log validation failures for audit trails.

6. Putting It All Together – Mini Case Study

Imagine a school wants a system to record exam results.

1. Design the file structure – as shown in the student record table.
2. Define input format – teachers upload a CS \cdot file with the same column order.
3. Write validation routines – check each row for required fields, numeric scores, and correct date format.
4. Process data – calculate total and average scores, assign grades.
5. Generate output – a printable PDF report per class and a JSON file for the school’s web portal.

7. Summary Checklist

• Identify all data items and choose suitable data types.
• Specify field lengths and decide fixed vs. variable record layout.
• Choose an input format that matches the source and is easy to parse.
• Define output formats for each stakeholder (students, teachers, administrators).
• Implement validation routines covering presence, type, range, length and format.
• Test the whole cycle – from data entry to final report – before deployment.