Know and understand components of technical documentation including purpose of the system/program, limitations of the system, program listing, program language, program flowcharts/algorithms, system flowcharts, hardware and software requirements, fil

7. The Systems Life Cycle

Objective

Know and understand the components of technical documentation, including:

• Purpose of the system / program
• Limitations of the system
• Program listing
• Program language
• Program flowcharts / algorithms
• System flowcharts
• Hardware and software requirements
• File structures
• List of variables
• Input format
• Output format
• Sample runs / test runs
• Validation routines

What is Technical Documentation?

Technical documentation is a written record that describes a system or program in sufficient detail for developers, users, and maintainers to understand, use, and modify it. It forms a vital part of the Systems Development Life Cycle (SDLC) and is produced at various stages, especially during design, implementation and testing.

Key Components

Detailed Explanation of Each Component

1. Purpose of the System / Program

The purpose should answer the questions “Why does this system exist?” and “What does it achieve for the user or organisation?”. It is usually written in plain language and placed at the beginning of the document.

2. Limitations of the System

Identify any factors that restrict the system’s performance or applicability, for example:

• Maximum number of concurrent users.
• Supported operating systems only.
• Data size limits (e.g., file size ≤ 2 GB).

3. Program Listing

Provide the complete source code. Use consistent indentation and include comments that explain:

• Purpose of each module or function.
• Complex sections of logic.
• Any external libraries used.

4. Program Language

State the exact language and version, because syntax and available libraries can differ between versions.

5. Program Flowcharts / Algorithms

Flowcharts use standard symbols (process, decision, input/output, connector). Algorithms may be written in pseudo‑code. Both help readers follow the program logic without reading the source code.

6. System Flowcharts

A system flowchart shows the interaction between the software, hardware, users and external systems. It is useful for stakeholders who need a high‑level view.

7. Hardware and Software Requirements

Present the requirements in a table:

8. File Structures

Describe each file used by the system, for example:

• Configuration file (INI format) – stores user preferences.
• Database file (SQLite) – contains tables Customers, Orders, etc.

9. List of \cdot ariables

A typical variable table includes:

10. Input Format

Specify the exact format, for example:

Date (DD/MM/YYYY) – must be a valid calendar date.
Amount – numeric, up to two decimal places, range 0.01 – 10 000.00.

11. Output Format

Describe layout, headings, column alignment, and any special characters. Example of a report header:

-------------------------------------------------
Monthly Sales Report – March 2025
-------------------------------------------------

12. Sample Runs / Test Runs

Provide at least three test cases:

1. Normal case: Valid input produces expected output.
2. Boundary case: Input at the limit of allowed range.
3. Error case: Invalid input triggers appropriate error message.

13. Validation Routines

Include pseudo‑code or actual code that checks each input field. Example in Python:

def validatedate(datestr):
try:
datetime.strptime(date_str, "%d/%m/%Y")
return True
except \cdot alueError:
return False

How the Components Fit into the Systems Life Cycle

Technical documentation is produced and refined at several stages:

1. Analysis: Initial purpose statement and high‑level system flowchart.
2. Design: Detailed system flowcharts, hardware/software specs, file structures, and variable lists.
3. Implementation: Program listing, language details, and validation routines.
4. Testing: Sample runs, test runs, and documentation of any limitations discovered.
5. Maintenance: Updated documentation reflecting changes, added features, or resolved limitations.

Checklist for a Complete Technical Document

• Clear purpose and scope.
• All limitations are listed.
• Full, commented source code.
• Correct language and version noted.
• Both program and system flowcharts included.
• Accurate hardware/software requirements.
• Comprehensive file structure description.
• Complete variable table.
• Detailed input and output specifications.
• Representative sample runs with expected results.
• Robust validation routines.
• Version control information (date, author, revision number).