General rules of creating documentation

• Exactness, e.g. statements like "appropriate", "small/large", "optimal", etc. should be changed to indicate the actual values, parameter range, criterion, etc.
• Completeness, e.g. all project functions are described
• Verifiability, e.g. avoid expressions like "works better", "it is well adjusted", etc.
• Consistency, e.g. the same aspect should not be described in different way in various parts of documentation
• Modifiability, e.g. since programs "live", a good documentation should reflect correctly the program last version
• References, e.g. documentation must provide references or attachments to all the related documents (datasheets, RFC documents, legal acts, source codes and open libraries, and executable software

What MUST be included in the project documentation

1. Authors' names, student ID numbers, indicated team leader.
2. Each Author's responsibility (who did what?) together with tasks delegated by the team leader. Task assignment and realization will be verified. It is recommended to distribute tasks evenly.
3. User guide.
4. Algorithm description - one should also cover the issues related to accuracy, timing choices, message format, etc.
   If the program implements a standard functionality, then there is no use describing it. Instead, one should refer to appropriate document (e.g. RFC). If the implementation of standardized functionality is incomplete, differences and motives for reduced implementation should be stated.
5. Proof of the correct program operation (printscreens, pictures, packet analyzer logs, etc.).
6. In the documentation one should provide FMEA/FMECA (Failure Mode and Effect Analysis/Failure Mode and Criticality Analysis). This analysis should cover situations leading to incorrect system behavior, occurrence probability, detection modes, potential reactions, etc. One may apply the following table:

   Risk	Probability	Gravity	(Auto)Detectability	Multiplicity	Reaction
   Malfunction of DNS server	0.3	Critical (10)	Straightforward (1). Detected via periodic polling (every 10 min) of the DNS servers about a common address or a service.	3	Usage of 3 different DNS servers, including one free-access google server. Storing critical (for system operation) addresses in a private location (specify the list of addresses ), log record, visual alarm for the user.
   ...	...	...	...	...	...

   Critical risks (the biggest gravity) should be marked (e.g. by a different color) - those are the demanding reaction. For the risks of lesser gravity, providing reaction scenario is not absolutely necessary. The purpose of the analysis is to determine which risks demand reaction and corrective steps, and which can possibly be neglected.