Once information has been gathered it is time to place all of the accrued knowledge into a single document. This document will then provide not only the basis for design but also a fundamental reference for all of the other phases, most notably the evaluation phase. The document itself must be written in a very specific way after all there is no point doing all of the previous analysis if you do not fully document it.

In order to ensure that the documentation is correct it is essential to follow some form of template. This template may change from company to company and from methodology to methodology. However the fundamentals will always be consistent. Below is a sample template, adapted from the IEEE standard 830-1998 : -

• Introduction
• Purpose
• Scope
• Definitions / abbreviations
• References
• Overview
• Overall description
• Product perspective
• Product functions
• User characteristics
• Constraints
• Assumptions and dependences
• Specific Requirements
• Interface requirements
• Functional requirements
• Performance requirements

Although, for the purpose of the course, it is not important to understand exactly how a requirement specification is written it is useful to be aware of it. There are a number of key elements to the template which are necessary for understanding its purpose.

Purpose and scope - Every project must have a scope. Putting it simply, if a project is unbounded then how will you know when you have finished? By stating exactly what the expected outcomes and limitations of the new system you can prevent misunderstandings on what the project can do. The purpose of the system is also crucial. If this is misunderstood by any of the stakeholders then this will cause problems when it comes to sign off. Most companies will set the legal blood hounds onto this section.

Product functions and product perspective-This is where the product lies when it is part of a larger picture or just where the product will lie in a business.

User characteristics - This is where the experience of the end user will be documented. Remember that this is key when writing the user interface requirements. If you do not produce a system which is accessible by the end user then the system will be un-useable.

Constraints- This is some of the key bounding rules which the new system must adhere to. This is very much related to scope and the feasibility study.