Preparing a Technical Specification (Minor Projects)

Audience:

Internal

Version: Date Issued: Document Status: Prepared By:

1.0

Issue Name Title Department

Authorised by:

173501137.doc

V2.0

1/6

Change History
Version Date Author Nature of Amendment

173501137.doc

V2.0

2/6

TABLE OF CONTENTS

1 OVERVIEW......................................................................................................................................4 2 BACKGROUND/FUNCTIONAL OVERVIEW............................................................................................4 3 ASSUMPTIONS AND CONSTRAINTS.....................................................................................................4 4 TRACEABILITY MATRIX ............................................................................................................4 5 DETAILED DESIGN SPECIFICATION........................................................................................5 6 NAME OF FUNCTION ..........................................................................................................................5 7 SCHEMA CHANGES.......................................................................................................................6 8 NAME OF TABLE/COLUMN/INDEX/CONSTRAINT................................................................................6

173501137.doc

V2.0

3/6

1 Overview
2 Background/Functional Overview
This section should contain an overview of what is being proposed in the technical specification as well as a brief background of the project. For projects that do not have a functional specification it is appropriate to include functional details in this section. Process flow or functional decomposition diagrams may also be included to help provide context for the changes being proposed on the technical specification. Refer to Appendix C for examples of some of the types of figures and diagrams that can be used.

3 Assumptions and Constraints

Consider design dependencies on external projects (including Infrastructure projects) or events. Also try to document those things that may lead to a particular design now, but which may change in the future (for example, lack of disk space, time constraints etc).

4 Traceability Matrix
The traceability matrix is used to track the requirements through the various phases of the Application Development Methodology and to link the relevant sections of the Business Requirements, Function Specification and Technical Specification documents. The traceability matrix consists of Requirement Number Requirement A brief description of the requirement Business Requirement Section The section of the Business Requirement document relating to the requirement Functional Specification Section The section of the Functional Specification document relating to the requirement Technical Specification Section The section of the Technical Specification document relating to the requirement Build # The build to which the software changes relating to the requirement will be applied Associated Programs The name of the program files that will be modified or created to implement the requirement

173501137.doc 4/6

V2.0

5 Detailed Design Specification

This section is highly iterative, and is likely to be revised in subsequent activities. It describes how the design specified in technical specification will be implemented. It is necessary to identify exactly where in the system the new or changed functions will occur, though it is not necessary to show detail of the unaffected parts.

6 Name of Function
The granularity of a function can be almost anything and can vary between different technical specifications and may vary within the same technical specification. Generally, it will be up to the designer to determine the most appropriate level of granularity. Examples of different levels of granularity include A logical function that can encompass multiple program files. Eg. The function described may be to add a new benefit type. This function would most probably impact multiple Forms screens, Pro-C programs and PL/SQL packages. A single program, procedure or function. Eg. Adding a new validation item M1057 A specific section within a program, procedure or function. Eg. The CBUS specific section of the package assignment procedure. 3.1.1. Description/Purpose Describe the purpose of the function. 3.1.2. Technical Design This is where the details of how the function must accomplish its purpose are described. The detail needs to be such that the designer is confident that all design issues have been addressed. Diagrams, process flow charts and psuedo code may be used to describe the technical design. Actual code CANNOT be used in this section. Note that hard coded values may be used for description purposes but it is assumed that such values will be replaced by variables when it comes to code implementation. Designers can add their own sub headings where appropriate.

173501137.doc 5/6

V2.0

7 Schema Changes
This section describes any database schema changes. Database schema changes include Creating a new table or view Adding a new column or modifying an existing column Creating, modifying or dropping indexes Creating or modifying constraints

This is the section that will be reviewed by the Database Administrators (DBAs).

8 Name of Table/Column/Index/Constraint
4.1.1. Description/Purpose Describe the purpose of the new database object or change. 4.1.2. Design Define the design of the database object. Identify column names, column descriptions, data types, column lengths and valid values. 4.1.3. Volumes and Archiving Where applicable, describe the estimated volumes and anticipated growth factors. Indicate any deletion or archiving strategies that will be applied.

173501137.doc 6/6

V2.0