Technical Project Documentation
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Technical Project Documentation as PDF for free.
More details
- Words: 1,523
- Pages: 8
Project Name Technical Specification
Name
Signature
Author Date of Submission Reviewer 1 Date of Review 1 Reviewer 2 (if applicable) Date of Review 2 (if applicable) Approved by Date of Approval
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 1 of 8
Change History Version No.
Revision No.
Description
Approval Date
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 2 of 8
Table of Contents Introduction.......................................................................................................................... ..5 Determine System Design Strategy................................................................................. ......5 Develop Conversion Specifications.............................................................. .........................5 Develop Program Specifications........................................................................................ ....6 Develop Physical Database Design................................................................................. ......6 Develop File / Report Format............................................................................................... ..7 Determine Backup, Recovery and Fallback Design..................................................... ..........7
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 3 of 8
Documents and Reference Materials (State reference documents and materials here)
Terminology and Convention (State the Terminology and Convention here)
Mandatory Sections 1, 2, 4, 7, as well as sections 5 and/or 6 are mandatory. The mandatory sections are not applicable to Technical Specifications prepared by external parties in outsourced project, or by internal staff to meet external customer’s requirements, but it will serve as a reference guide. Enter project name: Select ‘Project Name’ and press SHIFT+[F9]. Replace ‘Project Name’, in between the double quotes, with the project name and then press [F9] to update. Update version number in footer: Select the version number on the right side of the footer and press [F9] to update. This section serves as an instruction to the author and should not be included in the Technical Specification.
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 4 of 8
Introduction Determine System Design Strategy •
Document the System Design Strategy in this section. (System Design Strategy is mainly concerned with the high-level decisions about how the programs and files would be constructed.)
•
List the programs (existing and new) against the system functions defined in the Preliminary Design Specification stage. List also the files and databases used. Highlight interface files or programs which are from other system.
•
Describe in detail the flow of programs, screens, reports and files and how they interface with each other to form the new system. From the technical design viewpoint, highlight the order (if any) in which programs, screens, reports and files would need to be constructed.
•
Batch flow diagrams, system structure chart, screen hierarchy diagram or physical data flow diagram or a combination of flowcharting and diagramming techniques could be used.
If conversion of an old system’s data / software to the new proposed system’s data format / software is required, proceed to step 2, otherwise proceed to Step 3.
Develop Conversion Specifications •
Confirm the scope of conversion by listing the data elements and programs if any) to be converted. Specify also the cut-off date and the estimated total number of records to be converted.
•
Define the conversion approach. Consider the following: a. Conversion Files: Specify the file type and layout for input and output files used in conversion. b. Data Preparation: List the activities required to prepared the input data before loading into the new system. c.
Data Entry / Loading: Describe the method used to enter conversion input data into the new system and the reason for selecting the method.
d. Data Verification / Correction: List the verification criteria and control points for checking and correcting data entered or loaded. •
Specify the person(s) responsible for the conversion activities (e.g. data collection, data loading, verification, error correction etc.) outlined in the conversion approach.
•
State the manpower, software package and hardware required for the conversion. Highlight if acquisition needs to be done and the cost involved.
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 5 of 8
Develop Program Specifications •
Determine the following program attributes: - Project name - System / subsystem name - Program ID - Program title - Program version number - Programming language used - Program execution mode (e.g. online, batch, real time etc.) - Author
•
Provide a description of the program - Highlight the main functions and results of the program. (Note: Program logic should not be described here; they should be explored during the “Development” stage). - Provide information of database and non-database files used by the program (e.g. file name, description, data elements, sorting sequence etc.) - Provide information on the screen layout, field attributes and mapping of screen fields to database fields / program variables / derived values. - Provide information on the reports produced by the program. Include report layout with information such as report identification, title, headings, field positioning.
•
Other considerations to take note when developing the program specification - Limitations of software used - Optimal access path to files / resources - Handling of system error - Interface with other programs - Standardization of common messages - Use of design of reusable subroutines. - Program specification should meet existing programming standards and the requirements of the Functional Specifications.
Develop Physical Database Design •
Define the data structure a. Logical and/or Physical Schema Design - Prepare a graphical presentation showing how the entities of logical data model is transformed into database files (physical schema). That is from the normalized logical data model (3rd normal form), develop a first-cut physical database design. - The type of file structure should be clearly demonstrated. b. Consider combining multiple files into 1 physical file (especially for files with low record, low processing volume, or which use the same key and are always assessed together) c.
Consider splitting 1 entity into many files if the entity consists of too many fields which can be logically grouped together and the frequency of concurrent group access is low (Vertical Partitioning), or if the record volume is too high and the records can be grouped according to the value of some fields and the frequency of concurrent group access is low (Horizontal Partitioning).
d. Search keys used Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 6 of 8
Define the simple or concatenated keys that are used for the search or sorting criteria. •
Describe the database access technique - Briefly describe the access method – e.g. use of pointer to access the record; use of ODBC bridge to connect to the database etc.
•
Define the data dictionary Include the file name / description, field definition and the views used.
•
Determine the database capacity - Estimate the volume and growth rate of each database file based on the transaction volume
•
Determine the data retention period (e.g. all financial related data must be kept for a minimum of 7 years before they can be destroyed).
Develop File / Report Format •
For non-DBMS file, include the description of the following items: - File name, description, purpose and source of the file - Record sample layout including name, description, length, format, and position of the fields - File size - Retention period for the file / records.
•
For report, include the description of the following items: - Report name, description, purpose, and the name of the program / script that is generating the report. - Report sample layout including name, description, length, format and position of the fields. - Timing of reports: the time in which the report is expected to be generated (e.g. settlement reports must be generated at 0300hrs daily) - Mode of Reports Delivery (electronically via email, ftp, web-based application; manually via courier etc.)
Determine Backup, Recovery and Fallback Design •
Document the Backup, Recovery and Fallback Design in this section (organized into 3 sub sections – Backup, Recovery and Fallback).
•
If normal site procedures are to be used, it is sufficient to make reference to the site backup, recovery and fallback document for details.
•
If special software or procedures need to be developed for the system, provide the software design specifications and procedures in this document.
•
Consider whether the backup, recovery and fallback specifications need to be implemented at the: - System, Sub system or function level - Files, database level - Program level
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 7 of 8
-
Data Conversion level
•
For data backup, consider: - What data to backup - Frequency of backup - Media to backup to (e.g. tape, CD-ROM) - How to verify backup (i.e. ensure backup tapes contain valid data) - Retention period for backup data
•
For Recovery and Fallback, consider: - Whether plan fits in with organization wide DRP (Disaster Recovery Plan) - Roles and responsibilities of staff involved in the recovery and fallback plans - Hot, warm and cold standby concepts
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 8 of 8
Name
Signature
Author Date of Submission Reviewer 1 Date of Review 1 Reviewer 2 (if applicable) Date of Review 2 (if applicable) Approved by Date of Approval
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 1 of 8
Change History Version No.
Revision No.
Description
Approval Date
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 2 of 8
Table of Contents Introduction.......................................................................................................................... ..5 Determine System Design Strategy................................................................................. ......5 Develop Conversion Specifications.............................................................. .........................5 Develop Program Specifications........................................................................................ ....6 Develop Physical Database Design................................................................................. ......6 Develop File / Report Format............................................................................................... ..7 Determine Backup, Recovery and Fallback Design..................................................... ..........7
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 3 of 8
Documents and Reference Materials (State reference documents and materials here)
Terminology and Convention (State the Terminology and Convention here)
Mandatory Sections 1, 2, 4, 7, as well as sections 5 and/or 6 are mandatory. The mandatory sections are not applicable to Technical Specifications prepared by external parties in outsourced project, or by internal staff to meet external customer’s requirements, but it will serve as a reference guide. Enter project name: Select ‘Project Name’ and press SHIFT+[F9]. Replace ‘Project Name’, in between the double quotes, with the project name and then press [F9] to update. Update version number in footer: Select the version number on the right side of the footer and press [F9] to update. This section serves as an instruction to the author and should not be included in the Technical Specification.
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 4 of 8
Introduction Determine System Design Strategy •
Document the System Design Strategy in this section. (System Design Strategy is mainly concerned with the high-level decisions about how the programs and files would be constructed.)
•
List the programs (existing and new) against the system functions defined in the Preliminary Design Specification stage. List also the files and databases used. Highlight interface files or programs which are from other system.
•
Describe in detail the flow of programs, screens, reports and files and how they interface with each other to form the new system. From the technical design viewpoint, highlight the order (if any) in which programs, screens, reports and files would need to be constructed.
•
Batch flow diagrams, system structure chart, screen hierarchy diagram or physical data flow diagram or a combination of flowcharting and diagramming techniques could be used.
If conversion of an old system’s data / software to the new proposed system’s data format / software is required, proceed to step 2, otherwise proceed to Step 3.
Develop Conversion Specifications •
Confirm the scope of conversion by listing the data elements and programs if any) to be converted. Specify also the cut-off date and the estimated total number of records to be converted.
•
Define the conversion approach. Consider the following: a. Conversion Files: Specify the file type and layout for input and output files used in conversion. b. Data Preparation: List the activities required to prepared the input data before loading into the new system. c.
Data Entry / Loading: Describe the method used to enter conversion input data into the new system and the reason for selecting the method.
d. Data Verification / Correction: List the verification criteria and control points for checking and correcting data entered or loaded. •
Specify the person(s) responsible for the conversion activities (e.g. data collection, data loading, verification, error correction etc.) outlined in the conversion approach.
•
State the manpower, software package and hardware required for the conversion. Highlight if acquisition needs to be done and the cost involved.
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 5 of 8
Develop Program Specifications •
Determine the following program attributes: - Project name - System / subsystem name - Program ID - Program title - Program version number - Programming language used - Program execution mode (e.g. online, batch, real time etc.) - Author
•
Provide a description of the program - Highlight the main functions and results of the program. (Note: Program logic should not be described here; they should be explored during the “Development” stage). - Provide information of database and non-database files used by the program (e.g. file name, description, data elements, sorting sequence etc.) - Provide information on the screen layout, field attributes and mapping of screen fields to database fields / program variables / derived values. - Provide information on the reports produced by the program. Include report layout with information such as report identification, title, headings, field positioning.
•
Other considerations to take note when developing the program specification - Limitations of software used - Optimal access path to files / resources - Handling of system error - Interface with other programs - Standardization of common messages - Use of design of reusable subroutines. - Program specification should meet existing programming standards and the requirements of the Functional Specifications.
Develop Physical Database Design •
Define the data structure a. Logical and/or Physical Schema Design - Prepare a graphical presentation showing how the entities of logical data model is transformed into database files (physical schema). That is from the normalized logical data model (3rd normal form), develop a first-cut physical database design. - The type of file structure should be clearly demonstrated. b. Consider combining multiple files into 1 physical file (especially for files with low record, low processing volume, or which use the same key and are always assessed together) c.
Consider splitting 1 entity into many files if the entity consists of too many fields which can be logically grouped together and the frequency of concurrent group access is low (Vertical Partitioning), or if the record volume is too high and the records can be grouped according to the value of some fields and the frequency of concurrent group access is low (Horizontal Partitioning).
d. Search keys used Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 6 of 8
Define the simple or concatenated keys that are used for the search or sorting criteria. •
Describe the database access technique - Briefly describe the access method – e.g. use of pointer to access the record; use of ODBC bridge to connect to the database etc.
•
Define the data dictionary Include the file name / description, field definition and the views used.
•
Determine the database capacity - Estimate the volume and growth rate of each database file based on the transaction volume
•
Determine the data retention period (e.g. all financial related data must be kept for a minimum of 7 years before they can be destroyed).
Develop File / Report Format •
For non-DBMS file, include the description of the following items: - File name, description, purpose and source of the file - Record sample layout including name, description, length, format, and position of the fields - File size - Retention period for the file / records.
•
For report, include the description of the following items: - Report name, description, purpose, and the name of the program / script that is generating the report. - Report sample layout including name, description, length, format and position of the fields. - Timing of reports: the time in which the report is expected to be generated (e.g. settlement reports must be generated at 0300hrs daily) - Mode of Reports Delivery (electronically via email, ftp, web-based application; manually via courier etc.)
Determine Backup, Recovery and Fallback Design •
Document the Backup, Recovery and Fallback Design in this section (organized into 3 sub sections – Backup, Recovery and Fallback).
•
If normal site procedures are to be used, it is sufficient to make reference to the site backup, recovery and fallback document for details.
•
If special software or procedures need to be developed for the system, provide the software design specifications and procedures in this document.
•
Consider whether the backup, recovery and fallback specifications need to be implemented at the: - System, Sub system or function level - Files, database level - Program level
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 7 of 8
-
Data Conversion level
•
For data backup, consider: - What data to backup - Frequency of backup - Media to backup to (e.g. tape, CD-ROM) - How to verify backup (i.e. ensure backup tapes contain valid data) - Retention period for backup data
•
For Recovery and Fallback, consider: - Whether plan fits in with organization wide DRP (Disaster Recovery Plan) - Roles and responsibilities of staff involved in the recovery and fallback plans - Hot, warm and cold standby concepts
Technical Specification Template & Guide
Notion Age Pte. Ltd. Copyright © 20012008 Notion Age Pte. Ltd. All Rights Reserved.
Page: 8 of 8
Related Documents
Technical Project Documentation
October 2019 15
Project+documentation
December 2019 26
Project Documentation
April 2020 20
Ejtk Technical Documentation
December 2019 38
Documentation Of Technical Seminar.docx
October 2019 13