Information Technology Reference
In-Depth Information
Functional Specification
CRM
ERP
Financial
PPC
Fig. 4.2 Application break-down
Contents
1. General
Technical
Specifications
1.1 Objective
2. System Overview
2.1 Short Description
- Template -
2.3 Component Architecture
2.4 Object Model
2.5 Data Model
2.6 Interfaces
3. Process Control
Author:
Author or Team
4. Access Concept
5. IT Security
Subject:
Request Title
6. Quality Requirements
6.1 Operational Environment
Version:
x.y
< x: starting at 0; incremeted by 1 when the status
changes:
y: started at 1; incremeted within the same status
after updates >
6.2 Development Environment
7. Referenced Documents
8. Version History
Status:
draft
in progress
under assessment
released
Fig. 4.3 Technical specifications 1
explained the technical specifications are the basis for test scripts and thus serve as a
yardstick for the acceptance as such (as an example for their contents structure
see Figs.
4.3
,
4.4
,
4.5
,
4.6
and
4.7
).
In many cases for updates (release, service pack) several different functional
specifications may be needed: each for a specific functional change or enhancement.
These documents are sometimes cleared by completely different persons—depending
on the required professional knowledge. Furthermore these documents will not be
circulated all at the same time but one at a time. This means that the sub-project has to
provide for a tracking mechanism. The tracking management communicates between
the authors of the technical specifications from the supplier and the clearing body
from the customer. Its aim is to achieve clearance early enough so that there remains
sufficient time for realisation to keep the acceptance date. In this phase, however,
there may still be change requests from the business units coming in once they see
their requests in writing for the first time. The tracking management should then take
care about such requests and how to deal with them.
