System Design Document Template

The System Design Document is a required document for every project. It should include a high level description of why the System Design Document has been created, provide what the new system is intended for or is intended to replace and contain detailed descriptions of the architecture and system components.

If you like this System Design Document Template be sure to let your friends know.
We like to be Liked.

1 1 1 1 1 1 1 1 1 1 Rating 4.27 (13 Votes)

SYSTEM DESIGN DOCUMENT TEMPLATE

Introduction

This section should include a high level description of why this System Design Document has been created. It should also provide what the new system is intended for or is intended to replace. More detailed descriptions of the architecture and system components will be described throughout subsequent sections of the document.

This System Design Document has been created to outline the proposed system design for new Acme Corporation Maintenance Management System (MMS). The MMS is intended to replace the legacy maintenance tracking system currently used by Acme Corp. By designing, testing, and deploying the MMS, Acme Corp. will improve its capabilities in maintenance management, tracking, and reporting. This document and the technical specifications listed herein comply with all Acme Corp. technical standards and infrastructure.

Purpose

This section should provide a high-level description of the purpose of the System Design Document. This may include a description of how the System Design Document relates to organizational goals and/or objectives and how the new system will meet those goals and objectives.

The purpose of this System Design Document is to provide a description for how the new MMS will be constructed. The Systems Design Document was created to ensure that the MMS design meets the requirements specified in the MMS project requirements documentation as well as the Acme Corporation’s Executive Bulletin referencing improvements to existing maintenance management practices and tools. The System Design Document provides a description of the system architecture, software, hardware, database design, and security.

System Overview

This section should describe the basic system design goals, functionality and architecture. It may include a high level description of the approach used to develop the system design. It may also include high-level descriptions of the system’s hardware, software, database, and security components. Depending on the complexity of the system this section may also include component and/or contextual diagrams of the system and system components.

Acme Corporation has historically faced many challenges and shortcomings in managing fleet maintenance metrics, tracking, and reporting. The proposed MMS tool will utilize existing Acme infrastructure and hardware to provide an enterprise tool which will standardize and improve the efficiency of Acme’s maintenance management capabilities.

The MMS is designed as an enterprise software tool which is compatible with and leverages existing Acme hardware and infrastructure. Additionally, MMS is compliant with all internal Acme Corporation network security protocols and policies as well as industry regulatory policies.

The MMS tool is also compatible with existing Acme software suites to include MS Office applications and SharePoint, as well as SAP. The MMS tool will provide various user interfaces which will allow data entry, updates, tracking, and report generation. It will also allow users to export data to various existing software tools like MS Excel and SharePoint for various uses.

One of the primary benefits of the MMS tool over the legacy system is its ability to consolidate all maintenance data and generate real-time reports and analysis of fleet status, problem areas, chronic maintenance problems, and various other metrics. Until now Acme Corp. has relied upon legacy software with various reporting and data constraints and limited user interfaces which has resulted in poor reporting, tracking, and management as well as a general lack of continuity among the users.

The new MMS tool will provide the following capabilities:

  • Pre-designed automated reporting at various time intervals as well as manually generated reports
  • Integration of all maintenance data which allows for real-time report generation and simplifies management of all maintenance activities
  • Enhanced and additional user interfaces which provide users with much simpler data entry, updates, queries, and other capabilities
  • Data export capabilities which allow users to export data to various software tools for simplified reporting and presentation capability

Design Constraints

This section should describe the constraints associated with the system design. Constraints are the result of various conditions beyond the scope of the project that affect and limit the system design. These may be due to hardware, software, business processes, organizational/industry standards, or other conditions which affect the system design. This section should provide a description of what the constraints are and how they affect or limit the system design.

The MMS Project Team identified several constraints which will impact and limit the design of the tool. These constraints are beyond the scope of the MMS Project but must be carefully factored into the system design. To date, the following constraints have been identified:

  1. MMS must be compatible with existing Acme Corp. infrastructure to include network tools and applications, security requirements, server capabilities, and network management hardware. This constraints will impact the design because the team must ensure the MMS coding and formats meet the capabilities of the infrastructure will limit the MMS in certain areas—although the capabilities will still far exceed those of the legacy maintenance management system.
  2. MMS must comply with all Acme Corp. and industry regulatory policies and guidelines. These policies and guidelines will impact the tool by requiring certain standards of coding, user interfaces, security, and management of the tool.
  3. The MMS tool must be compatible with existing user software suites. This will require the team to design and code the MMS in a manner in which data can be seamlessly imported and exported between the MMS and existing software tools.

Roles and Responsibilities

System design can cross many different groups within an organization to ensure requirements are gathered and met for all stakeholders. As such, a roles and responsibilities section may be necessary to provide the team with clarification on who performs various roles. This section also serves as a list of points of contact for the team and stakeholders should issues and concerns arise which need to be addressed.

The following table defines the MMS System Design roles and responsibilities. This matrix also serves as the list of points of contact for issues and concerns relating to the MMS System Design.

Name Role Phone Email
A. White Project Manager (777) 555-1212 This email address is being protected from spambots. You need JavaScript enabled to view it.
B. Black Lead Designer - User Interface (777) 555-1213 This email address is being protected from spambots. You need JavaScript enabled to view it.
C. Gray Lead Designer - Architecture (777) 555-1214 This email address is being protected from spambots. You need JavaScript enabled to view it.
D. Blue Lead Designer - Security (777) 555-1215 This email address is being protected from spambots. You need JavaScript enabled to view it.

Project References

This section should describe what references exist which guide the system design. These references may be internal or external. Examples of references include white papers. System analyses, organizational standards, industry standards, meeting minutes/summaries, and findings. This section should provide a list of such references but the descriptions should be general and not include much detail since the documents on the list can be referred to individually if more information is needed.

The MMS tool is designed in accordance with several organizational guidelines, standards, analyses, and findings. These references serve as the basis for the requirement of a new maintenance management system. The following is a list of references. It should be noted that some of these documents are periodically updated and if more detailed information is needed, they should be referred to individually.

  • Acme Corp. IT Security Policies and Guidelines, Oct 10, 20xx
  • Acme Corp. Hardware and Software Catalog, Jun 2, 20xx
  • Acme Corp. Program Management Office (PMO) Policies and Guidelines Feb 7, 20xx
  • Acme Corp. Legacy Maintenance Management White Paper Jul 8, 20xx
  • Acme Corp. 20xx Strategic Goals and Objectives Dec 27, 20xx
  • Acme Corp. 20xx Network Architecture Guidelines Jan 3, 20xx
  • Acme Corp. 20xx Network Architecture Design Document, Jan 2, 20xx

System Architecture

This section should describe the architecture necessary to achieve the system design for the project. This will usually consist of both hardware and software architecture. Additionally, it may be that the existing architecture (either hardware or software) is already in place, in which case the requirements should still be documented. The description of the architecture should include a list and summary of each component and, depending on the complexity of the design, it may be beneficial to include diagrams showing the relationship/connectivity between these components.

Hardware:

The MMS design is based on existing hardware architecture already deployed across the Acme Corp. enterprise. This hardware consists of the following components:

  • ABC Quadrant Server Array consisting of
    - 8GHz Server Suite
    - RAM: 16 GB Fully Buffered
    - Array Controller
    - 4x 80GB 15,000 RPM Hard Drive
    - 4x Giga Network Adapters
  • Cisco CSS 11500 Content Services Switch series
  • 4 TB SAN Storage Devices
  • Dell P3000 Workstations

Software:

The MMS design is based on the individual design of various components in which users will enter and query data. The software architecture is designed to incorporate all data entries and modifications into an integrated database which tracks maintenance data in real-time as it’s manipulated. The components which comprise the software architecture include:

  • • User Data Entry Module: This component provides the user interfaces for all maintenance data entry. This component consists of several sub-components to include:
    - New System Data
    - Existing System Maintenance Updates
    - System Location Updates
    - System History
  • Automated Reporting Module: This component provides all of the pre-built automated reporting capabilities. These are reports that are generated regularly and repetitively at known intervals.
  • Manual Reporting Module: This component provides a list of all searchable fields in which the user can create a report as the need arises

Database Design

This section should describe the design of the database or data hosting environment. The database is the repository where all of the data utilized by the system resides. It is important that the design achieves interoperability between the user facing portion of the system and the background data. This section should describe how the database is designed/configured to achieve this. Depending on the complexity of the system, diagrams showing the database design and/or the relationship between the database and the user interface may be helpful. It is also possible that this section references another document(s) which may contain more detailed technical data.

The MMS tool will incorporate existing maintenance data in the legacy database into a new enhanced database with additional capabilities such as searchable and sortable fields and various enhanced reporting functions. The MMS database will also have the capability of importing and exporting data from/to MS Office applications.

Structured data stored in the database will be searchable and sortable in order to meet both automated and manual reporting requirements. As such, the database field names are consistent with all fields built into the User Data Entry Module, Automated Reporting Module, and Manual Reporting Module.

Additional fields have also been added to the MMS database to include:

  • Coordinates (lat./long.) of assets in the fleet
  • Property management fields to capture and update personnel responsible for various assets
  • Fault category identification to provide greater visibility into maintenance failures

Additional technical specifications of the database design can be found in the MSS database management system (DBMS) addendum to the Project Plan.

Hardware and Software Detailed Design

This section should describe the design of the hardware and software in more detailed terms. In the event that system utilizes the existing design of the hardware or software, it may not be necessary to restate the existing design in detailed terms. Again, like many other sections, the contents of this section may depend upon the complexity of the system design. The more complex, generally the more explanation and detail is required to communicate the design. Systems with a high level of complexity may require diagrams and/or conceptual illustrations to more easily convey understanding.

Hardware:

The MMS solution leverages existing Acme Corp. hardware architecture and design. No additional hardware design is required for the MMS. Existing hardware detailed design can be found in the Acme Corp. 20xx Network Architecture Design Document, dated January 2, 20xx.

Software:

The MMS software design is coded by Acme Corp. IT Engineers to provide customized functionality specific to the operations of Acme Corp. It was determined through various analyses and studies that there is not an existing commercial-off-the-shelf (COTS) product with the ability to capture specific business operations unique to Acme Corp. As such, detailed requirements were gathered from the legacy maintenance system’s user population and these requirements were used to develop the concept for the MMS design. The concept was then broken down into modules in order to segregate and compartmentalize various functionality.

User Data Entry Module: Several partitions are coded into the User Data Entry Module depending on the type of maintenance transaction the user seeks to perform. These partitions help ensure users enter the appropriate sub-module (listed below) for their data entry activities.

  • New System Data – This sub-module is coded to contain specific fields required for entering new assets/equipment into the database for the first time
  • Existing System Maintenance Updates - This sub-module is coded to contain specific fields required for adding, removing, or editing data which already exists in the maintenance database
  • System Location Updates - This sub-module is coded to contain fields specific to geographic locations to include site, city, state, zip code, latitude, and longitude. As assets/equipment are relocated, this sub-module allows users to update locations accordingly
  • System History - This sub-module is coded to contain fields specific for reference past maintenance activities. Coding includes various search fields by location, serial number, part number, or asset/equipment type

Automated Reporting Module: This module includes coding which provides users with a selection of pre-built automated reports. The coding allows the user to select a report and uses this input to initiate a pre-built database query to pull the appropriate data from the data base in response to the user’s selection.

Manual Reporting Module: This module includes coding which provides users the ability to modify various reporting criteria such as search dates, locations, sites, systems, and serial numbers. These user inputs then initiate the database query to execute the desired search algorithm.

System Security and Integrity Controls

This section should describe the measures included in the system design to ensure the system is secure and that the integrity of the system and data are maintained. This is an important consideration in the design of the system as failure to secure and control the system and its data can result in significant loss of time, money, and other resources.

The MMS tool design incorporates several security and integrity controls to ensure that the system and its data are continually protected. This is done through a multi-tiered approach to ensuring data integrity is achieved through only authorized user functions and assignments.

The first design consideration is user authorization or permissions. All MMS users will be assigned an authorization level and permissions within which they will operate. These users will be unable to perform any MMS transactions outside of their assigned areas. Managers will provide authorization levels and operating boundaries for each of their assigned users.

The next design consideration is to establish control points. As the MMS is a network tool, firewalls will be placed to partition the functions each group within Acme Corp. is able to perform within the MMS. The purpose of this is to reinforce assigned work areas, permissions, and access with physical barriers to prevent any duplication, unintentional changes, or malicious changes of maintenance data.

The MMS design also incorporates an audit trail capability not available in the legacy maintenance system. This capability will allow Acme Corp. IT personnel to track the history of all MMS users in order to provide history, error identification, and accountability for system users.

The next design consideration is data backup. The MMS database will be backed up in accordance with Acme Corp. IT Security Policies and Guidelines dated Oct. 10, 20xx. This will provide a fail-over capability to revert to in the event of a database corruption or system failure. The MMS was also designed to perform in degraded modes of operation should maintenance need to be performed on a particular module.

Acme Corp.’s IT group will also have the capability, in the event of a catastrophic system failure, to revert back to the legacy system until such time that the MMS system can be restored.