Information Technology Reference
In-Depth Information
The performance description in some cases will overlap with the non-functional
requirements. This is okay as the sections are somewhat similar. The performance
description should cover a more distant view of the system, where the non-func-
tional requirements should cover specific performance issues. This section should
cover hardware requirements, as well as architecture and the specialized pro-
cessing units required. Both minimum and recommended system setups should be
listed if appropriate.
This, in many cases, will become a very lengthy section. Each possible
exception should be documented here. Exceptions should be grouped in a standard
way to make their reference easier as this section may encompass a large number
of pages. Each error should be listed, as well what action will take place. Some
common groupings are:
• By error type (file, interface, user invoked).
• Catastrophic (complete system failure).
• By modules (what module did the error occur in).
Acceptance criteria are the items by which the deliverables will be accepted or
rejected. This section can pose technical dilemmas for software engineers and may
contain legal jargon as pertinent to faults and accident liability, but an attempt
should be made to make some important points clear and concise. The main points
of this section are:
• Important deliverable deadlines.
• Required uptime of implemented system.
• Throughput or load of the system.
• Fault tolerance.
• Content of deliverables.
13.2.2 Change Management
Any good development team will find issues with the specification document at
some point during the development process. This is perfectly acceptable and
desired as it promotes review and scrutiny of the concepts and design. This process
of discovery and revision needs careful and well documented control in order to
assure that only desirable changes are implemented, and that changes are not being
made to make up for a lack of experience or effort by the development teams. A
good change request form should cover the following:
• Who it was requested by.
• When it was requested.
• Why it was requested.
• What the change entails.
• Whether the change was accepted or rejected.
• Who approved or rejected the change.
