NH Department of Health And

<APPLICATION NAME>

NH Department of XXXXXX

System Design Phase Technical Design

<Application Name>

System Design Phase

Technical Design Document

02.18.2005

Version 1.0

TABLE OF CONTENTS

1.INTRODUCTION

1.1Using this Document

1.2Purpose

1.3Owners and Contacts

1.4Signoffs

1.5Revision History

1.6Referenced Documents

1.7Definitions, Acronyms and Abbreviations

2.PROJECT OVERVIEW:

3.ASSUMPTIONS, CONSTRAINTS AND SCOPE:

4.SOLUTION DESCRIPTION

5.DESIGN CONSIDERATIONS

5.1Resources and Schedule

5.2System Environment

5.3Design Methodology

5.4Risk and Volatile Areas

5.5Security

5.6Performance and Response Time

6.ARCHITECTURE

6.1Design Overview

6.2Design Details

6.2.1Hardware Layer

6.2.2Software Layer

6.3Data

6.3.1Structure

6.3.2Conversions

6.3.3Archive and Purge

6.3.4Interfaces

6.4Backup and Recovery

7.SYSTEM DESIGN

7.1Application Controls

7.2Design Module ABC (1..n)

7.2.1Screen ABC

7.2.2Report ABC

7.3Design Module XYZ (1..n)

7.3.1Screen XYZ

7.3.2Report XYZ

7.4Scheduled and Automatic Processes

8.OTHER CONSIDERATIONS

8.1Testing

8.1.1Unit Testing

8.1.2Integration Testing

8.1.3System Testing

8.2Acceptance

8.3Training

8.4Implementation / Hand-off / Maintainance

9.ISSUES LOG

1.INTODUCTION

1.1Using this Document

This template serves as a basis for a Software Design Specification.

<The text enclosed in the less-than/greater-than symbols is included for the benefit of the person writing the document and should be removed before the document is finalized.>

Designs for software systems should be customized to the needs of the project building the system. This template is one of many documents related to this software development project. Thus although it is organized such that it can be a single stand-alone document, the material in this template is intended to be repackaged into multiple documents, reorganized and augmented for the needs of the project. Please refer to Section 1.6 Referenced Documents for a listing of additional project-specific documentation.

1.2Purpose

The purpose of this document is to serve as a basis for defining the details of the Technical Design of the solution alternative selected by the Customer during the Functional Design Phase. The Technical Design is to be composed by DOIT/Technical team. The information within this document explains how the requirements of the chosen solution will be met.

1.3Owners and Contacts

Name / Email / Phone / Role
John Doe / / 303-471-8344 / Project Manager
Joe Tester / System Test Lead
Jane ProdSupport / Production Support Mgr
Jim UserMgr / User Test Lead
Jose Developer / Developer – Presentation Tier
Joan Developer / Developer – Business Tier
John DBA / Data Base Administrator
Jill Tester / Tester
Jazz Tester / Tester
Jack Customer / Department VP
June Customer / Department Mgr
Jake Customer / Product Support

1.4Signoffs

Name / Date / Signature
John Doe, PM/DM / xx/xx/xx
Joe Tester, System Test Lead
Jane ProdSupport, Production Support Mgr
Jack User Mgr, UM
Jim Customer, Customer

1.5Revision History

Date / Reason for change(s) / Author(s)
07/01/2004 / First Draft / John Doe
07/12/2004 / Revision based on project launch committee meeting / Gotta Changit

1.6Referenced Documents

Document / Version/Date / Author(s)
Project Concept Document / 1/7/2004 / John User
Functional Design Phase Business Requirements / 7/12/2004 / Jane Function
Functional Design Phase Functional Design / 9/20/2004 / Sam Retired
Functional Design Phase Solution Alternatives / 11/1/2004 / Joe Technical

1.7Definitions, Acronyms and Abbreviations

<This section contains definitions, acronyms and abbreviations referred to within this document that may need to be clarified to assist the reader in understanding the meaning and or intent of the information contained within this document. Some examples are shown below. Please populate this section based on the specific content you provide for the Business Requirements for your project.>

<Back-endThat portion of an application that the users do not interact with directly, relative to the client/server computing model, a front-end is likely to be a client and a back-end to be a server.>

<Back-officeThe internal business functions of a company such as finance, accounting, legal, human resources and operations.>

<CustomerA user, technical or non-technical, of the system. The customer can be either an agency constituent or a state employee.>

<DesktopWorkstations and laptop computers with industry-standard accessories and peripherals, including but not limited to: monitors, processor, components, disk drives, storage devices, speakers, network interfaces cards, printers and scanners.>

2.PROJECT OVERVIEW:

<Document an overview of this project. Information may include a narrative regarding the business needs that will be met through this project, the Stakeholders/Customers that will be impacted, a description of the reasons this project is being performed, an impact statement, and other relevant project level information. You may want to copy and modify the Project Overview from one of the Referenced Documents.>

3.ASSUMPTIONS, CONSTRAINTS AND SCOPE:

<Describe any assumption, background or dependencies of the software, its use, the operational environment, or significant project issues. Describe any constraints of the technical design that have a significant impact on the business requirements and/or project in general. Describe any constraints on the system that have a significant impact on the design of the system. (e.g. technology constraints, performance, requirements, end user characteristics, validations requirements, project constraints, etc.)>

<Examples include:

Assumption: Payroll Service Companies will be able to use CD or Floppy disk to mail the data files

Constrain: Legal is still working on the mechanism that will be used to allow Payroll Services to send the Tax and Wage reports in without the authorizing signatures. When legal works out this problem there may be design changes needed.

Scope: Only Payroll Service Companies with at least 1000 clients will be invited to use the new electronic filing method.

Scope: Electronic Tax and Wage filing will not be extended directly to businesses who file on their own.>

4.SOLUTION DESCRIPTION

Include a summary of the chosen solution as defined within the Solution Alternatives Document.>

5.DESIGN CONSIDERATIONS

5.1Resources and Schedule

<Describe the team skills needed for the project keeping in mind the schedule and benchmark goals.>

Personnel Needs / Hours Estimated
Management / 1,200
Administrative Support / 850
Analysts / 850
Hardware Support / 1,300
Database Administrator / 2,050
Database Programmer / 3,200
Web Programmer / 1,200
C++ Programmer / 550
Totals / 11,200

The following is a comprehensive schedule for development of the <project> assuming that the projects’ Technical Design is completed by <date>.

Process Needs / Hours Estimated
Design Finalization / 900
Prototype Arch / 900
Programming / 3,000
Test Planning / 1,000
User Doc / 500
Integration Testing / 1,350
Acceptance Testing / 500
Roll-out Preparation / 450
Production Support / 200
Roll-out / 0
Project Mgmnt / 2,000
Admin Tasks / 300
Infrastructure Support / 100
Totals / 11,200

5.2System Environment

<Describe the hardware and software with which the system must operate and interact, including development, and testing environments>

<Example: Development will begin on database TILT on server TROLL until the new equipment arrives. As soon as server TROLL2 is loaded, the development will move there. Upon roll-out, TROLL2 will become production (as it is a faster, newer server) and TROLL will become the development platform for the next project.>

5.3Design Methodology

<(Optional) Summarize the approach that will be used to create and evolve the design for this system. Cover any processes, conventions, policies, techniques or other issues which will guide design work. See Software Development Methodology Reference.>

<Example: Team development will be needed so a modular coding approach is desired. Prototyping will not be needed as the customers are already familiar with the basic screen look and feel and have already approved the screen layouts. The project will be developed in two phases; Validation and Tax and Wage Processing. Validation needs to be rolled out as soon as possible so that the Payroll Service Companies can begin their programming to accommodate the system.>

5.4Risk and Volatile Areas

<(Optional) Describe any notably volatile or risky areas of the system and any special strategies takes to mitigate risk or prepare for changes.>

<Example: Tax and Wage data filing for the Payroll Service Clients is time critical because they get charged late fees for filing late, and yet they file as late as they can in order to keep their money as long as possible. This requires us to “accept” as much data as possible, regardless of how inaccurate or corrupt it is. To reject the entire file because of one bad record would cause all the clients to file late. Therefore the Suspense system is critical and must be tested robustly. We are planning to use two new hires in development of this project. Additional training and supervision should be expected.>

5.5Security

<(Optional) Describe how security will be enforced and at what level (or groups). Address the security module, ISS security, Secure Socket Layers, Etc. if applicable.>

<Example: A new user group will need to be created with this project. A “Cashier” group that will allow cashiers (previously not users of this application) to access the deposits table.>

5.6Performance and Response Time

<(Optional) Explain how the design will minimize response time. This includes the use of Store Procedures, de-normalized data (if applicable), server configuration (size, memory, etc), programming techniques and the use of database tools such as Oracle’s Explain Plan and SQL Server’s Show Plan.>

6.ARCHITECTURE

6.1Design Overview

<This statement of work definitively describes in measurable terms the goals, capabilities and external characteristics of the project.>

<This document translates the Customer needs from business language into logical and technical system requirements by translating the business requirements into conceptual technical designs that describe the automated processes enabling both the technical stakeholders and the project team analysts to describe and model the automated behavior and characteristics of the system and attempt to verify that it satisfies the business requirements developed earlier. The stakeholders validate the proposed technical approach during which process they create a detailed description of the work for the technical implementation team and attempt to discover any technical feasibility problems.>

<Example: There are two separate and distinct processes required for tax and wage report electronic filing. The first process is the validation of the Payroll Services list of client employees. The second step is the actual submission and processing of the filings. Even if the Payroll Service does not think they will be inclined to submit Tax and Wage reports electronically, the validation process might itself be useful in assisting the Payroll Service in locating and repairing data problems with their systems.>

6.2Design Details

<Describe all design details including but not limited to Hardware, Software. This might also include Business, Maintenance and Support, Network and other layers.>

6.2.1Hardware Layer

<List all hardware requirements needed to run the system. Include server and client configurations.>

6.2.2Software Layer

<List all software used to develop the system (Visual Basic, SQL Server,, Etc.) along with any software necessary for the system to function (MS Excel, Internet Explorer, Etc.)>

6.3Data

6.3.1Structure

<Describes any input or output file, specifications, edits or format which are needed by the project or which are to be produced by the project. Also include indexes, constraints and keys.>

M_TAXABLE_WAGES
Field Name / Data Type / Precision / Edits and Formats / Description and Use
Emp_Type_Code / Alpha(2) / No spaces. Foreign key restraint to child m_employer table / Unique code assigned to each employer type (Contributory, Seasonal, Reimbursable, etc.)
Min_Taxable_Wage / Number(7,2) / Amount of minimum wages which are taxable.
Start_dt / Date / Date Format, Date Edits / Date from which the minimum taxable wages are applicable.
End_dt / Date / Date Format, Date Edits / Date from which the minimum taxable wages are applicable.

6.3.2Conversions

<Describe any programs that are used to import, convert or merge the data.>

6.3.3Archive and Purge

<Describe any programs that are used to perform special functions like purging and archiving.>

6.3.4Interfaces

<Describe how the system is to be fed from other systems. This may be via replication, BCP, SQL Loader, XML, etc. Describe the data that will flow between the systems and how often it will be updated, and who the system owners for each system are.>

6.4Backup and Recovery

<Describe the process for backing up and recovering lost data>

7.SYSTEM DESIGN

7.1Application Controls

<Detail the common behavior that all screens will have. Common look and feel details such as menus, popup menus, toolbars, status bar, title bars, grad and drop and mouse behavior should be described here. Example images of menus and toolbars may be used.>

7.2Design Module ABC (1..n)

<The notation 1..n indicates that this section is to be repeated as many times as necessary to cover all modules of the project. In this template, the first iteration contains the blank template form, the second contains an example.>

<Illustrate all major user interface screens and describe the behavior and state changes that the user will experience. A screen transition diagram or table can optionally be created to illustrate the flow of control throughout the various screens.>

7.2.1Screen ABC

< Screen Shot or image of the screen >
Description / Describe the purpose of the screen as to ensure the client and developer agrees on its functionality.
Security / List the security groups that may use the screen and/or any security issues with the data or access to it.
Data / Describe each field on the screen and how it is to be used.
Actions / Describe each action that can be performed from this screen. This usually involves command buttons, menu items, etc.

7.2.2Report ABC

Description / Describe the purpose of the report as to ensure the client and developer agree on its functionality.
Security / List the security groups that may use the report and/or any security issues with the data or access to it.
Data / Describe each field on the report and how it is to be derived.
Format / Describe the reports format, groupings, totals, filters and any other physical makeup of the report.
Export Format / Describe the export format of the report (print, preview, export file, MS Word, ASCII, etc.)

7.3Design Module XYZ (1..n)

7.3.1Screen XYZ

Description / The Loading of the Payroll Service Validation Data will be accomplished by PowerBuilder code as shown in appendix 2. It will be loaded into a table structured as shown above
Security / Supervisor level access only.
Data / The main data window is populated by m_payroll_service_valid table. This is done once the LOAD button is used.
Actions / NEW: Clears out all fields and positions the cursor on the Payroll Service Company field. The User fills in the fields Payroll Service Company, Date Received, Date Loaded and File Name.
FIND:The data in the M_Payroll_Service_Valid table for that Payroll Service Provider will be read and shown in the lower window.
LOAD: The program will search for the File Name (presumable on the A: drive directly from the floppy disk of the PRS). If not found, there will be an error message. If the file is found, the data will be checked to see that the Payroll Service Company indicated by the user is the same one that is in the file.

7.3.2Report XYZ

Description / This report is designed to inform the Payroll Service of invalid account data and the most likely correction.
Security / This report can be printed by any Contributions Clerk or Supervisor
Data / The PRS line is the data as supplied by the Payroll Service.
The NHES line is the data that is best matched from the NH Emp Security data
Format / Switches are needed to allow the report to be sorted by NH Acct or by FEIN
Export Format / The repot will be produced on the network printer LOKI

7.4Scheduled and Automatic Processes

<Describe any jobs that will run automatically or on a scheduled basis.>

<Example: Suspense accounts will be interrogated by the nightly batch process and any corrected accounts will be processed and removed from suspense.>

8.OTHER CONSIDERATIONS

8.1Testing

8.1.1Unit Testing

<Describe any significant areas of high risk which might require a more vigorous or extended testing process.>

8.1.2Integration Testing

<Describe any significant areas of high risk which might require a more vigorous or extended testing process.>

8.1.3System Testing

<Describe any significant areas of high risk which might require a more vigorous or extended testing process.>

8.2Acceptance

<Describe any significant areas of stakeholder concerns which might require a more vigorous or extended acceptance process.>

<Example: Payroll Service Companies are required to run at least two quarters worth of parallel testing (using the old system and the new system at the same time) before they will be authorized to drop the old system.>

8.3Training

<Describe any significant areas of the project which might be more difficult to master and require a higher learning curve.>

8.4Implementation / Hand-off / Maintenance

<Describe any Implementation, Handoff or Maintenance issues which may have been uncovered or may require more attention including but not limited to the initial population of the data and any data conversions.>

9.ISSUES LOG

<The issues log is a table that tracks any issues that arise after this document is approved and signed. Its purpose is to update the document while leaving the original content intact. The issues log can be maintained in an Excel worksheet and “pasted” into this Word document.

The issues log should include the following details:

• Issue Number
• Date Logged
• Requirement Number (a reference to the original requirement that is impacted)
• Issue description
• Resolution description
• Date Resolved
• Decision Made By

The issues log worksheet can also be used to track all requirements, design/development, and/or solution alternatives issues that occur after the corresponding documentation is signed. >

Office of Information Technology, Agency Software Division - <Agency>

1