System documentation is information about built solution and acts as a reference for future maintenance or update efforts. A description of a program after it has been developed. It is organized based on system functionality rather than when changes were made to the system, making it easier for people who maintain the solution to find the information they need quickly. It includes wide range of technical and non-technical manuals, books, diagrams and descriptions relating to the use and operation of the developed system. System documentation represents documents that describe the system itself and its parts. It includes requirements documents, design decisions, architecture descriptions, program source code, and FAQs
Features of Effective System Documentation:
Effective system documentation should possess the following characteristics:
i. It must be clearly stated in the language that is easily understood.
ii. It should be possible to refer to other documents.
iii. It should contain everything needed, so that those who are reading it carefully understand the system.
iv. It should be accessible to those for whom it is intended.
v. When the system gets modified it should be easy to update the documentation.
Purpose of System Documentation:
The formal system documentation fulfills the following objectives:
i. To provide the necessary information to develop training programme for operators and users.
ii. To create a vehicle of information to provide evidence of progress in the development process and to monitor the process i.e. it guides the development team on various stages of SDLC
iii. To make conversion of a system from one machine to another machine easier.
iv. To make system modification and implementation easier.
v. To narrow down the communication gaps among users, designers and management.
vi. To provide a means to determine in advance what will occur and when.
vii. It can be used as a backup to recover the system should anything happen during implementation
viii. It can be effectively used to provide a checklist of items to be covered during subsequent audit.
Contents of System Documentation:
The report on the system design should contain the following elements:
i. An overview of the entire project describing the general purpose of the system with the
relevant information.
ii. Documentation for every input and output used in the system. Each document should accompany each design and explain the purpose and use of each form.
iii. Documentation of every file of the system, creating and update sequences of the file should be there.
iv. System flowchart describing the series of steps used in the processing of data.
v. A financial analysis of the proposed and existing systems, providing present and future costs with potential cost savings.
vi. A description of the computer system and its peripheral equipment’s.
Levels of System Documentation:
Levels of documentation mean the persons or positions in the managerial hierarchy for whom or to whom document is useful for operation purposes.
These levels are:
➢ Documentation for users – To guide users on how to use the system
➢ Documentation for management – Use documents from the past projects to plan and understand the current project.
➢ Documentation for data processing department (System Developers) – Depends on the document from the previous life cycle stages to guide in future modification and
maintenance of the system.
1. Documentation for User:
For the smooth operation of the system, it is essential that the users understand the system fully, and are aware of that is expected of him to make it work successfully.
a) The documentation should include a sample of each input document and instructions for using it.
b) It should also indicate operating schedules.
c) User’s documentation should cover files layout and file relation details.
d) The documentation for user should explain in non-technical terms all aspects of the system from users’ point of view.
e) It should also explain how the system will operate once it is fully installed.
f) It should include a sample of each output report with necessary explanation.
g) It should state the input document coding procedure, and also the coding structure for various fields and related tables.
h) Limitations of system should also be highlighted.
2. Documentation for Management:
It includes systems’ proposals covering the followings:
a) Functional Design—Functional requirements.
b) Resources required.
c) Cost benefits analysis.
d) Development schedule.
e) Concepts, architectural design.
3. Documentation for Data Processing Department:
This has been divided into following three categories:
➢ Documentation for system’s designers.
➢ Documentation for operations personnel.
➢ Documentation for programmers.
A. Documentation for System’s Designers:
It includes:
i. Layouts of master files
ii. Layouts of intermediate files
iii. Controls
iv. I/O schedules
v. Output report layout
vi. System flow chart
vii. Implementation plan
viii. Copy of program specification
ix. Input from layouts.
B. Documentation for operations personnel:
This has three sub-groups:
1. Machine operations—this should include:
i. Detailed instructions for each step.
ii. File retention schedules.
iii. Interrupt/Restart procedures.
iv. Systems flow.
2. Data preparations:
The documentations should provide samples of all input documents, card layouts, record layouts, special instrument for data preparations, retention schedules for data.
3. I/O control:
i. Quality control checking procedures for each step.
ii. Dispatching (reports) details
iii. Processing schedules
iv. Document receipt details.
C. Documentation for Programmers:
For each program there should be a program folder covering the followings:
i. Source program listing.
ii. Development of system test run.
iii. Program specifications I/O layouts.
iv. Usage of any special technique
v. Test results
vi. Test data listing
vii. Program logic flowchart.
viii. Changes in specifications during program.
