Technical Spec

Project Name: Some Project

Project ID:
Project Lead:
IT Manager:
IT Director:

Table of Contents
Table of Contents.................................................................................................................................................1
1 Introduction....................................................................................................................................................4
1.1 System Objectives....................................................................................................................................4
1.2 Application Scope....................................................................................................................................4
1.2.1 In Scope............................................................................................................................................4
1.2.2 Out of Scope.....................................................................................................................................4
1.3 System Constraints and Limitations........................................................................................................4
1.3.1 Assumptions Based on These Constraints/Limitations....................................................................4
2 Architectural Principles & Technologies Employed........................................................................................5
2.1 Architectural Principles...........................................................................................................................5
2.2 Architectural Constraints.........................................................................................................................5
2.3 Technology Stack.....................................................................................................................................5
2.4 Development Standards Compliance......................................................................................................6
2.5 Approved Deviations from Standards.....................................................................................................6
3 Functional Design............................................................................................................................................6
3.1 Ecosystem................................................................................................................................................6
3.2 Basic Functionality...................................................................................................................................6
4 Technical Architecture....................................................................................................................................7
4.1 System conceptual Architecture Diagrams.............................................................................................7
4.1.1 Current Architecture State...............................................................................................................7
4.1.2 New State after Implementation.....................................................................................................7
4.1.3 Future State Architecture Diagram..................................................................................................7
4.1.4 Server Farm Diagram........................................................................................................................8

<Organization> Confidential Month dd, YYYY

 Technical Spec – Project Name

4.2 Problems & Solutions..............................................................................................................................8

4.2.1 Problems..........................................................................................................................................8
4.2.2 Solutions...........................................................................................................................................8
4.3 Functional Decomposition.......................................................................................................................9
4.3.1 Tier Architecture..............................................................................................................................9
4.3.2 Base Services and Design patterns.................................................................................................10
5 Data Design...................................................................................................................................................11
5.1 Entity Relationship Diagrams.................................................................................................................11
5.1.1 Pre-Existing Configuration..............................................................................................................11
5.1.2 NEW Structures (High-Level Design)..............................................................................................12
5.1.3 Data Auditing Tables......................................................................................................................12
5.2 Data Dictionary......................................................................................................................................12
5.3 Data Flow Diagrams...............................................................................................................................13
5.3.1 Data Integration Data Flow............................................................................................................13
5.3.2 Calls to External Systems................................................................................................................13
5.3.3 Other Data Flows Not Included in This Section..............................................................................13
6 Non-Functional Requirements Implementation...........................................................................................13
6.1 Non-Functional Design..........................................................................................................................13
6.2 Software Performance Requirements...................................................................................................13
6.2.1 Performance requirements............................................................................................................13
6.2.2 capacity requirements...................................................................................................................13
7 User Interface Design....................................................................................................................................14
8 Application Interface Design.........................................................................................................................14
9 Infrastructure Design....................................................................................................................................14
9.1 Production & Integration Infrastructure...............................................................................................14
9.2 Development Infrastructure..................................................................................................................14
10 Security Design..........................................................................................................................................14
11 Management Ready Design Standards.....................................................................................................14
12 Component Design....................................................................................................................................15
12.1.1 Application Component Detail Design...........................................................................................15
12.2 Database Components Detail Design (for SQL Server)..........................................................................17
12.2.1 Data Definition Language (DDL).....................................................................................................17

1/5/2021 <Organization> Confidential

Page | 2
 Technical Spec – Project Name

12.2.2 Data Modification Language (DML)...............................................................................................17

12.2.3 Stored Procedures..........................................................................................................................17
13 Document Purpose....................................................................................................................................19
13.1 Author and Audience.............................................................................................................................19
13.2 Disclaimer..............................................................................................................................................19
14 REQUIRED Previous Documentation.........................................................................................................19
15 Appendix...................................................................................................................................................20
16 Related Documents...................................................................................................................................20
17 Glossary.....................................................................................................................................................20
18 Revision History.......................................................................................................................................20
19 Approval Tracking...................................................................................................................................20

1/5/2021 <Organization> Confidential

Page | 3
 Technical Spec – Project Name

Introduction
System Objectives
Due to lack of support and maintenances, the XXX system requires upgrades…..

Application Scope
In Scope
1. Provide ..
2. Provide ..
3. Flexible support for..
4. Programmatic interfaces (APIs) to be available for ..
5. Review & re-factor or redesign ..
6. Create an effective ..

Out of Scope
1. This project only addresses ..
2. All non-user related functions are out of scope..
3. not responsible for maintaining historical data related to ..

System Constraints and Limitations

Due to enterprise level dependency with this project, the system will keep the current interface
end point with exactly same signature.
Because of the above constraint, the existing Web Service interface cannot adequately be
'fixed' within the scope of this project to meet all project requirements; this would require
signature modifications that imply a mass change involving a large number of applications.

Assumptions Based on These Constraints/Limitations

 On day one after go-live, the system will ..

 all existing data will be (and needs to be) accessible and accurate via Web Services
interface as is today whether the solution is technical or non-technical, the current data
access will be addressed; ..

1/5/2021 <Organization> Confidential

Page | 4
 Technical Spec – Project Name

Architectural Principles & Technologies Employed

Architectural Principles
Please refer to the following links to Architectural documents that apply to entire
application development.
<links>

Architectural Constraints
Only the approved technology stack of .NET C# for new development, and <xxxx>
functionalities used for development (see 2.3).

Technology Stack
Purpose Software
Operating System Microsoft Windows Server 20xx and
Microsoft Windows 10 <version> for
Development environment
Runtime Framework .NET Framework x.x
Entity Framework Version x.x
IDE Visual Studio 20xx
Eclipse xx.x
Database SQL Server 20xx Enterprise
Languages C# (.NET)
Java J2EE runtime
Web Server Internet Information Services xx.xx
QA & Defect Tracking HP Quality Center xx.xx
Browser Google Chrome xx+, Edge xx+,
FireFox xx+
Exception, Data Access, Logging Microsoft enterprise library x.x

Development Standards Compliance

Please refer to the following document that applies across the enterprise:
<link>

Approved Deviations from Standards

This section proposal has been approved by the <Solution Architecture> Team

1/5/2021 <Organization> Confidential

Page | 5
 Technical Spec – Project Name

The following recommendation is in pending approval from Solution Architecture

Team. The goal of this solution is to provide the following functionalities to the
applications.
To provide the service to technology ubiquitous interface to many different
applications, the following Authorization application framework will be used

<Name, describe or reference the Authorization (security) framework system>

Due to constraints and limitations of certain clients, the following approach is

recommended and <needs/has been> approved by the <Solution Architecture> team
for an implementation.

<Describe any approach due to limitations of clients here>

Functional Design

Ecosystem
The functional design is described in more detail in section 4.1 Conceptual Architectural
Diagram, the following is a …. Ecosystem diagram that shows the consumers of the system.

<Insert ecosystem diagram/s>

Basic Functionality
The system will provide two categories of services…
It provides following data, Services and functions.
 It provides ..
 It also provides..
 XXX Services
 YYY Services

Technical Architecture
Blah, blah ..

System conceptual Architecture Diagrams

Following diagram 4.1 shows the conceptual interfaces and modules of …. system.

1/5/2021 <Organization> Confidential

Page | 6
 Technical Spec – Project Name

Diagram 4.1

Current Architecture State

Following diagram 4.1.1 describes the current architecture settings.

Diagram 4.1.1

New State after Implementation

Following diagram 4.1.2 show the state of the system after this project is completed

Diagram 4.1.2

Future State Architecture Diagram

Finally diagram 4.1.3 represents the future state of the system.

Server Farm Diagram

Following three diagrams represent the server farm configuration; the Diagram 4.1.4.1
shows the immediate and future state configuration. The following 4.1.4.2 shows the
detail configuration of the production servers.

Diagram 4.1.4.1

Problems & Solutions

Problems
This section describes the issues and problems found in current. Following list of
issues has been identified.
1. data may be inaccurate due to lack of support for the ...
2. Currently, there is no published SLA uptime requirement for services.
3. Current system doesn’t provide the flexible organization structure and
consumes coupled architecture which may prevent the scalability of the
functions and adaptable data provisioning.
4. Lack of security and limited architecture to support for related data.

1/5/2021 <Organization> Confidential

Page | 7
 Technical Spec – Project Name

5. Lack of framework functionalities to support scalability of the application.

Solutions
In order to address the issues of lack of functionality support and limitation of
current architecture, following approaches and design decisions have been
considered and provided.
The first bullet point emphasizes on the overall goal of the new framework and
intention. The rest of the bulleted points describe the features and solutions to
address the issues that are described above Problems section.
1. Create a scalable and easily adaptable framework to support not only for
the current functionalities and data store but also for any other industry
standard third party products which may be purchased when needs arise
in future.
2. The framework will provide the transparency of the functionality to
current subscribing applications regardless of platform and any flavor of
the current subsystem.
3. Implement Service oriented Architecture to provide ubiquitous interfaces
to any implemented applications which are implemented with different
technologies.
4. Provide published SLA to Application to ensure and promote the stability
and accuracy of the data. This is obtained by analyzing performance log
data that is scheduled to be implemented in production during early
stage of development. The data is however limited to the period that is
implemented to gather the performance data.
5. The framework will provide sufficient security implementation to comply
with security standard.
6. Provide horizontally and vertically scalable architecture framework to
support the both direction of growth in IT community.
7. Enhance and fix all the current services to sustain the current application
implementations.
8. Provide a WIKI document that explains how to easily implement the new
services in their applications.

Functional Decomposition
Tier Architecture

Framework is implemented with following tier implementation.

Following diagram represents the n-tier setup for the all WCF services.

1/5/2021 <Organization> Confidential

Page | 8
 Technical Spec – Project Name

 WCF Service interface configuration with data contract

o WCF will be configured to expose the web services with basicHTTP Binding
configuration
 Service Layer
o Coarse functions that represent and hides the internal complexity and promotes the
decoupling and reuse of the codes throughout the services
 Business Logic Layer
o Domain specific models that support the smaller entities. These will be granular and
cohesive enough to be reused and flexible services to Service Layer
 Data Access Layer
o Interacts with data source.
 Cross cutting concerns
o Operational services, functions and configuration to support security, logging, audit &
etc…
<diagrams>

Base Services and Design patterns

WCF Services
Diagram 4.3.1

Diagram 4.3.2

Security Service
Figure 4.1 Web Service sequence Diagram

Following list describes all the aspects of the security requirements.

1. All subscribing applications will need its provisioned AD Service account.
2. web service calls require secure transport layer communications via HTTPS.
3. All Web Service calls will require Application specific AD Service account in
username & password.
4. Applications are required to be registered with ..
5. All …

1/5/2021 <Organization> Confidential

Page | 9
 Technical Spec – Project Name

Auditing

Exception Handling

Unit testing framework with mock data

Creating a test framework to validate the data & functions with mock data is a crucial
to this project.
Currently, due to lack of performance environment, a framework needs to be built to
support the following functionalities.
These services will be used to validate the SLA requirements in controlled environment.
The following tests will mimic the performance measurement but will not represent the
true production performance.
This framework will be run during the development, QA and staged Production phase.
 Preparing the Data

 All methods in services will use example data that is provided by use case
scenarios from BA/QA team and create multiple instances with different
variations for data validation and basic performance measurement.
 Data Driven client request test to services for data validation
 Bulk Data Driven request test to measure performance

Data Design
Entity Relationship Diagrams
Pre-Existing Configuration

1/5/2021 <Organization> Confidential

Page | 10
 Technical Spec – Project Name

NEW Structures (High-Level Design)

The DB model presented in this section is intended to address the following ‘in-scope’ project
requirements to provide ..

Requirement xxx:
a.

Data Auditing Tables

Regular auditing: All UPDATE or DELETE
operations on data for which application based
auding is enabled will cause the existing
version of the record (before modification) to
be stored in audit.

Data Dictionary
Table [ ] DataType,PK,FK,Nullabl Notes
e
INT PK1
VARCHAR(50) PK2
INT PK2, FK
TINYINT

RULES:
a. ..
b. ..
c.

Table [ ] DataType,PK,FK,Nu Notes

llable
INT PK1
VARCHAR(50)
PK2
VARCHAR(200)
TINYINT

RULES:

1/5/2021 <Organization> Confidential

Page | 11
 Technical Spec – Project Name

a. ..
b. ..

Data Flow Diagrams

Data Integration Data Flow
This diagram includes data flows involving the move of data to or from ..
…

Calls to External Systems

This functionality is in use by at least a couple of systems to perform ..

Other Data Flows Not Included in This Section

 ...

Non-Functional Requirements Implementation

Non-Functional Design
Application shall have an uptime target of 99.9 (Platinum Service Level)
Documentation and reference implementations shall be provide for development
teams ..

Software Performance Requirements

Performance requirements

The SLA for new authorization transactions is: ..

Note: These performance requirements must be verified before deployment using
automated performance testing tools provided by QA.

capacity requirements
Note: These capacity requirements are stated in relative / tentative terms – ..
System to be capable of processing TBD authorization transactions per minute – .. This
relative number will be converted into actual numbers using the results of the
transaction logging task.
A load test will be conducted to verify that the new application can achieve these
volumes and performance.

1/5/2021 <Organization> Confidential

Page | 12
 Technical Spec – Project Name

User Interface Design

Please refer to UI section of SRS for detail information.

Application Interface Design

Each technology is detailed in both Application and DB section of the detail design decisions.
Please refer to the base service design decision section for SOAP, application interfaces and
DB design

Infrastructure Design
Production & Integration Infrastructure

<server diagrams>

Development Infrastructure
<server diagrams>

Security Design

Please refer to security section of the Architecture design and decisions.

Management Ready Design Standards

This Standard requirement promotes the higher quality of support for the system by providing
the following services.
The system shall be fully monitored and managed by the Systems Management and Data
Center Operations team. …, pro-active, complete application monitoring services are
required. Development team to work with Ops teams to implement systems management.
the system will include the following monitoring features
o Log disk space & health monitoring
o Service health check monitoring (use of synthetic transactions..
o Data base performance checks
o Exception monitoring & pro-active alerting of “error” conditions
o server heartbeat monitoring

1/5/2021 <Organization> Confidential

Page | 13
 Technical Spec – Project Name

o Monitoring for “normal” work volumes

The detail of these concepts is to be developed jointly by the project team and Operations
Support teams. The actual objects and log data location will be implemented in 12 component
design.

Component Design

The in depth component design section of this technical specification is intentionally incomplete.
The high level of the basic application framework plumbing design and approaches and list of
methods are present here. The in depth detail technical implementation of all services and detail
signature and logic along with specific sequence diagrams will be added later as a separate different
document during low level technical document phase. The detail portion of the documents can be
added here as needed. This additional design detail will be completed during the detailed low level
technical design documentation phase of the project. The sections that follow list those
components where some level of detail design has been done.

Application Component Detail Design

Techniques & Design Patterns used

Figure 12.1.1. Model Diagram

1/5/2021 <Organization> Confidential

Page | 14
 Technical Spec – Project Name

Testing Framework
This framework is required to provide the SLA data validation during development/unit testing
and QA phases.

Approach
This framework is proposed to support not only the development team to aid in unit
testing during the development but also can be utilized as a testing tool in controlled
environment.

Technical Requirement
1. The testing tool requires a sterile environment. During the testing all operations
should be halt to prevent any mal data.
2. Use Case data is collected to represent all the possible cases. This includes all
methods in all services and different data.
3. The volume of the data should be sufficient enough to make any meaningful data
from the testing. I recommend more than 5k records to run. This will play a huge
role to collect performance data addition to data validation.
4. The test has to be re-runnable.

Dependencies
1. Clean data is a key.
2. Creating data with proper referential integrity to sustain the RI error free testing.
3. Creating a proper script to create reasonable amount of volume.

Setup

Logging Services
All the exception will be logged into the database with …. Below is the configuration for
the database logging.
.

1/5/2021 <Organization> Confidential

Page | 15
 Technical Spec – Project Name

Exception Handling
All the exceptions will be handled and logged into database. And fault exception will be
thrown to the client

Database Components Detail Design (for SQL Server)

Data Definition Language (DDL)
Object Name (Script Name) Description / Change Type/Action
Database [ ]:
dbo.XXX
CREATE TABLE
(dbo.XXX.sql)

CREATE TABLE

Database [ ]:
dbo.YYY
CREATE TABLE
(dbo.YYY.sql)

Data Modification Language (DML)

Object Name (Script Name) Description / Change Type/Action

ZZZ_DML.sql
DATAMOD

Stored Procedures

NEW Stored Procedures

Object Name (Script Name) Desc / Notes Type/Action
dbo.ProcXXX User (NEW SP)

Existing Stored Procedures to Support Legacy ..

Note: No Stored Procedures are considered for existing .. because they will be replaced .

Object Name (Script Name) Desc / Notes Type/Action

1/5/2021 <Organization> Confidential

Page | 16
 Technical Spec – Project Name

dbo.ProcYYY (1) Review existing

SPs for adjustment
to new Structure
vs. deprecation
(NEW or MODIFY)

Utility and Internal Logic Components for Application Functionality

Object Name (Script Name) Desc / Notes Type/Action
Database [ ]:
VERIFY

Database [ ]:
MODIFY PROC

Data Interfaces Components

Object Name (Script Name) Notes Type/Action
Database [ ]:
dbo.XXX CREATE TABLE

Database [ ]:
dbo.YYY CREATE PROC

Server Objects
REVIEW if
ZZZ
needed

SQL DB Regression Testing Components

This table list SQL DB components that are Not anticipated to change but should be regression tested during
QA. This list will be updated as new components are discovered.
Object Name (Script Name) Notes Type/Action
<Server or Database:>
SQL Process (T-
XXX
SQL)

1/5/2021 <Organization> Confidential

Page | 17
 Technical Spec – Project Name

<Server or Database>:
SQL Process
YYY
(SSIS, T-SQL)

1/5/2021 <Organization> Confidential

Page | 18
 Technical Spec

Document Purpose

This document describes the list of standard & guideline to help to understand
the …
The information in this document is intended to be used as a high level design
and its solutions to help both in-house and contract developers.
 Design decisions
 Technical Guideline
 Conceptual design
 Object model design

Author and Audience

This document is written to be consumed primarily by architects, technical leads,
development staff & System Analyst to assist them with understanding the
technical & design requirements.

Disclaimer
This document is meant to be updated on a regular basis as additional decisions
are made or the components of the system are altered. The long-term value of
this document as anasset is directly related to the accuracy and relevance of the
content.

REQUIRED Previous Documentation

This technical design document assumes that the project team has read and is familiar
with the following project documentation; this documentation may be referenced at any
time in this design document:
Required Document Location
Business Requiremements Document (BRD) … <link>
Software Requirements Specs (SRS) <link>

<Organization> Confidential Month dd, YYYY

 Technical Spec – Project Name

Appendix
Related Documents
Glossary

Revision History

Version Primary Authors Description of Version / Date

Reason for Change Completed

Approval Tracking

Signoff received via emails should be documented by inserting the email below this
grid.
Signoff received via steering meeting should be documented by reference to a
published meeting recap that indicates who gave the approval.
Verbal approvals should always be documented via email or recap note.
Approved Name Signature Date Approved

1/5/2021 <Organization> Confidential

Page | 20