Documentation

Up Introduction The Author Quality Specification Design Development Testing Deployment Eye Candy Client Server Thin Client Internationalisation Security Employment Real-Time Metrics Documentation Access Data Projects

The documentation required to be produced by the Developer is : 

bulletUser Manual
bulletTechnical Manual

  

Documentation to be produced by the User is :

bulletUser Procedures

It is accepted that the content of these manuals will probably overlap.

These documents should be primarily delivered as Word Documents.

User Manual

The purpose of the User Manual is to define the logic of the application and explain the purpose of the displays and controls. It may be compared with the User Manual that comes with the purchase of a car (It does not include driving instructions or explicit engineering references).

It should cover all the functionality required by the specification.

 

Technical Manual

The purpose of this manual is to provide technical information to technical personnel who may not be familiar with this application.

The Technical Manual should be considered to be an Extended User Manual.

It is important to understand what should be in this manual, and what should not.

It should explain all the major processes, not only how they are achieved, but, if necessary, why they are achieved.

It should define important, but invisible, functionality such as validation, checks and business rules.

Descriptions need not explain the obvious. Rather, descriptions should explain the technical “highlights”.

Public, Global or Shared resources such as objects and variables should be detailed, and reference made to the areas of the application that uses them.

This manual shall include the ERD, and adequate information about the underlying tables and their relationships. If fact-modelling data is available, then it should be included here.

 

User Procedures

It is the role of the User Representative to ensure that this manual is written. It is the “Driving Manual” for the application.

Considering the application as a tool, it should explain the details of the full operational scope of its use. This should also include data maintenance, imports, exports, backups and data restoration, where applicable.

 

 

Documentation Tools

A number of documentation tools exist. These include :

·         MS Access

·         Total Access Tools

·         DBAnalyser

As technical personnel will probably use these tools, or equivalents, themselves, it is important to assess the value of including such documentation output with the above-mentioned manuals.

 

MS Access

The internal Documenter is a quick useful tool during software development, but perhaps has little to offer the final documentation.

Its Access Report output does not save to a popular file format, without losing significant structure. However, the Adobe Acrobat Writer can save this output as a .PDF file.

 

Total Access Analayzer

Total Access Analyzer provides a good check of the system before completion.

Object Lists and Code Module Descriptions can be useful to include in the Technical Manual.

As with MS Access, its Access Report output does not save to a popular file format, without losing significant structure. However, the Adobe Acrobat Writer can save this output as a .PDF file.

 

DB Analyser

DBAnalyser provides detailed technical documentation in Word format. This can be cut and pasted into the Technical Manual.

However, the different types of reporting available is limited.