During the Design Phase, the system is designed to satisfy the requirements identified in the previous phases. The requirements identified in the Requirements Analysis Phase are transformed into a System Design Document that accurately describes the design of the system and that can be used as an input to system development in the next phase. Multiple-release projects require multiple iterations of the Design Phase – one for each release.
1.0: Objectives / Goals
2.0: Deliverables and Approvals
4.0: Tasks and Activities
Successful completion of the Design Phase should comprise:
The purpose of the Design Phase is to transform the requirements into complete and detailed system design specifications. Once the design is approved, the Development Team begins the Development Phase.
Back To Top
SDLC deliverables help State agencies successfully plan, execute, and control IT projects by providing a framework to ensure that all aspects of the project are properly and consistently defined, planned, and communicated. The SDLC templates provide a clear structure of required content along with boilerplate language agencies may utilize and customize. State agencies may use formats other than the templates, as long as the deliverables include all required content.
The development and distribution of SDLC deliverables:
During the development of documentation, the Development Team should:
The following is a listing of deliverables required of all projects for this phase of work. Deliverables need to be updated for each iteration of the Design Phase.
System Design Document (SDD) – specifies the construction details of the system, each system component’s interaction with other components and external systems, and the interface that allows end users to operate the system and its functions.
· Document the results of the system design process
· Describe how the system with satisfy requirements
System Development Document – establishes the hardware and network development approach including methodologies, tools, and procedures to be employed; also includes development procedures for issue tracking and configuration management and any other information that aids in the implementation of the system.
· Document all preparations related to the development of the system
· Describe development methodologies, tools, and procedures
Agency Chief Information Officer (CIO)
System Security Consensus Document (SSCD) – a single document containing all information relevant to completing the system’s Certification & Accreditation.
· Define the system’s security architecture, security policies, risk assessments, and security tests
· Consolidate all information for the C&A
Security Plan – documents the scope, approach, and resources required to assure system security.
· Describe planned activities to control access and protect the system and its information
Data Retention Plan – describes the project policies for data and records management.
· Record retention and disposition responsibilities
· Document retention and disposition requirements
· Record management process
· Document retention and disposition schedules
Disaster Recovery Plan – IT-focused plan designed to restore operability of targeted systems, applications, or a computer facility due to a natural or man-made extended interruption of an agency’s business services.
· Identify plans to restore operability in the event of extended interruption of services
· Define and document concept of operations
· Document notification procedures
· Record damage assessment procedures, recovery activities, and reconstitution procedures
Unit and Integration Test Plans (Begin) – detailed scripts used in the Development and Test Phases for evaluating the completeness and correctness of the smallest parts of the system and the components created from those parts. The test scripts are more specific than the Test Master Plan, which is high-level and more focused on processes.
· Identify detailed scripts for testing system components
Conversion Plan (Begin) – describes the strategies and approaches for migrating data from an existing system to another hardware environment. This document is only applicable for projects involving the migration of data.
· Document all planned activities to ensure a smooth data migration from a legacy system to a new environment
Implementation Plan – describes how the information system will be deployed as an operational system.
· Define all planned activities to ensure successful implementation to production operations
Operations or System Administration Manual (Begin) – The Operations Manual focuses on mainframe systems; the Systems Administration Manual is oriented for distributed (client/server) systems. Both documents provide details on system operations.
· Provide detailed instruction for system operations
Maintenance Manual (Begin) – details effective system maintenance. Appendices might document maintenance procedures, standards, or other essential information on areas such as backup, networking and connectivity, access and authentication, cabling, and critical services.
· Provide maintenance personnel with the information necessary to effectively maintain the system
Training Plan – outlines training needs for end users on the new or enhanced information system.
· Ensure that the schedule accounts for all necessary training needs to successfully implement, operate, and maintain the system
Requirements Traceability Matrix (Update) – a table that links requirements to their origins and traces them throughout the project life cycle.
· Establish a baseline for requirements change control, design, and testing
All deliverables other than those identified as Updates should be developed in this phase. Deliverables identified as Updates should be revisited and enhanced as necessary as prescribed in this phase.
Deliverables produced during this phase must be reviewed in detail and should follow the approval path as defined in the above table (for each iteration). A signature page or section should accompany each deliverable requiring approval. DoIT will periodically request copies of these documents as part of its oversight responsibilities.
The following personnel participate in the work activities of this phase:
Responsible – Describes role that executes the activities to achieve the task.
Accountable – Describes roles that own the quality of the deliverable and sign off on work that Responsible provides.
Consulted – Describes roles that provide subject matter expertise.
Informed – Describes roles that receive information about the task.
The Roles and Responsibilities page has detailed descriptions of these roles and their associated responsibilities.
The Project Manager ensures the following prerequisites for this phase are complete:
The Project Manager monitors project performance by gathering status information about:
The Project Manager also organizes and oversees systematic quality management reviews of project work as a part of monitoring the project performance.
To measure project effort at all phases of the life cycle, the Project Manager establishes timelines and metrics for success at each phase of work when planning project tasks.
The PMBOK provides additional details on controlling project work in sections 4.4 and 4.5 and on project scope control in section 5.5.
The Project Manager updates the PMP routinely (at least quarterly) to ensure the PMP reflects project performance accurately. Review project performance controls and risks for deviations from the baseline.
Information distribution is one of the most important responsibilities of the Project Manager. The Project Manager reviews and updates the Communication Management Plan at least quarterly to account for potential changes in project stakeholders. The Project Manager distributes the updated PMP and risk management information according to the revised Communication Management Plan. PMBOK, section 10 contains additional details on project communications and information distribution.
The Project Manager conducts periodic risk management activities during the Design Phase; these activities include:
These activities occur throughout the project duration to track and mitigate any new or changed project risks. The PMBOK, section 11 has details for risk management activities, particularly sections 11.2 through 11.6.
The Project Manager assembles all project documentation, including the Communication Management Plan, PMP, issue logs, and any other relevant artifacts reflecting day-to-day management of the project, each quarter and submits this information to DoIT as a quarterly update review. DoIT reviews this information, particularly differences from the previous quarter and determines whether to recommend any action.
The Development Team has several important decisions to make as the solution begins to take shape. During the process of creating the design, the Project Manager and Development Team should consult with the Maryland EA Repository for possible components to integrate into the new system, potentially saving money through reuse. Project stakeholders should be involved periodically throughout the Design Phase to ensure that the development team understands their expectations and that it develops the system in accordance with requirements.
The Development Team makes critical design decisions, including:
The Development Team should decide which design components will be implemented in each release. During the process of this decision-making, the Development Team may consult other technical resources, such as agency production operations staff to identify technical issues in the Operations and Maintenance Phase, for additional information.
The Development Team sets up a configuration management repository and establishes change management procedures to track changes to the system, ensure requirements compliance, and enhance development quality.
This effort involves three inter-related concepts:
Creating the right balance in change management is difficult but critical to system development: too much control may cause work to be impeded; too little control may cause the project to devolve into chaos.
Establishing a solid configuration management repository and clear change management processes improve requirements traceability. Requirements traceability begins in the Design Phase as the Development Team validates requirements and begins the process of creating exact specifications to meet those requirements. Managing those requirements properly increases project success.
For more information on configuration management best practices, see Related Links.
The Project Manager schedules a review of the system requirements, both functional and non-functional, to ensure the scope has not changed since the end of the Requirements Analysis Phase. This review includes project stakeholders and Development Team members and covers the SRD deliverable created in the Requirements Analysis Phase: re-validating the SRD in this phase ensures the SRD reflects the user’s perspective of the system design.
The Development Team constructs the SDD, which maps the system requirements to the technical implementation and contains details about the environment, hardware architecture, firmware architecture – including subsystems and components, and files – and internal and external interfaces.
The SDD describes the system requirements, operating environment, system and subsystem architecture, hardware components (computers, cabling, peripherals, etc.), files, input formats, output layouts, human-machine interfaces, detailed design, processing logic, external interfaces, and furniture, supplies, and equipment requirements.
The key elements of the SDD include:
For a network deployment or hardware upgrade, the SDD should emphasize the deployment of the system. The Project Manager and the Project Sponsor must ensure proper documentation to meet the requirements.
The effort to develop the SDD may iterate through several cycles from a general design to the desired level of granularity as significant architecture decisions are made and the design moves toward the target architecture.
The SDD documents the transformation of abstract business requirements to detailed system specifications for construction and assembly.
The Development Team updates the RTM after the SDD is approved. An RTM aids in moving from requirements to design and enabling the Systems Team to track problems occurring in the Operations and Maintenance Phase back through testing and design to original requirements.
The Development Team builds on the TMP created in the Requirements Analysis Phase as the system architecture and its components are specified. Refine test cases and procedures as the design process continues.
The Project Manager coordinates a comprehensive security risk assessment, which addresses threats, vulnerabilities, risks, outcomes, and security controls and documents the results in the SSCD. The risk assessment evaluates compliance with baseline security requirements, identifies threats and vulnerabilities, and assesses alternatives for mitigating or accepting residual risks.
The SSCD includes a definition of the system and its security architecture, security policies, risk assessments, and security test plans.
The key elements of the SSCD include at minimum:
The SSCD is designed to retain all information for the C&A in one document. State policy for IT systems requires that all Executive Branch agencies certify and accredit the IT systems and sites under their ownership and control. The Development Team should review the DoIT Information Technology Security Certification and Accreditation Guidelines and the project’s SSCD for any actions needed to enable the system to become certified and accredited prior to implementation. These documents are available at the DoIT State Information Technology Security Policy and Standards webpage. In addition, the Development Team should review all applicable federal government guidance to ensure relevant security requirements are addressed:
In addition to the C&A policies, the Development Team should review other DoIT security policies and standards (posted on DoIT’s website) to determine which ones apply. The Development Team adds to the SSCD a plan to implement those policies that apply and identify security controls to remediate risks and vulnerabilities discovered during the risk assessment. The SSCD needs to be updated for each design iteration.
The Development Team develops the Security Plan to address security risks identified in the SSCD.
The Security Plan documents the scope, approach, and resources required to assure system security.
The key elements of the Security Plan include at minimum:
The Development Team should create the Security Plan after the SSCD to ensure that all known vulnerabilities and requirements are addressed. The purpose of the Security Plan is to specifically identify all planned controls and activities necessary to meet security requirements. The document also outlines responsibilities of all system users. The Security Plan needs to be updated for each design iteration.
The Project Manager also coordinates with the Development Team and project stakeholders to define a Disaster Recovery Plan (DRP) for the system.
The DRP is an IT-focused plan designed to restore operability of targeted systems or a computer facility due to a natural or man-made extended interruption of an agency’s business services.
The key elements of the DRP include at minimum:
The Development Team should conduct a Business Impact Analysis (BIA) to identify IT resources, identify outage impacts and allowable times, and develop recovery priorities.
The information gathered during the BIA serves as critical input to the DRP. The DRP should also address operability risk mitigation strategies identified during the security risk assessment. The DRP needs to be updated for each design iteration. Additional DRP guidance may be found in the State of Maryland Information Technology Disaster Recovery Guidelines found on the DoIT website.
The Development Team establishes the hardware and network development approach including methodologies, tools, and procedures to be employed. The results of this planning should be documented in a System Development Document.
The Development Team begins documenting implementation procedures for the system in the target environment, including any necessary resources and information. The implementation procedures include all activities required for the deployment of the system on the integration environment. If the project requires the migration of data, the Conversion and Implementation Plans should address data migration to ensure a smooth implementation.
Identify implementation resources from the Development Team, which may be a combination of State employees and external vendors, based on the technologies and the implementation methodology. The implementation resources must have technical skills, the ability to communicate issues and changes, understanding of both the problem domain and the implementation environment, and good leadership.
The Conversion Plan, Implementation Plan, and the Training Plan should be in draft form by the end of the Design Phase. Each of the plans should address how the team will execute the multiple iterations of data conversion, implementation, and training involved in multiple releases.
The Project Manager and Development Team draft an Operations or System Administration Manual and a Maintenance Manual. The Systems Team will use these documents during the Operations and Maintenance Phase to support the system. Each release will require separate operations and maintenance planning.
Schedule a review near the end of the Design Phase to evaluate any particular operations or maintenance requirements for system administration.
The Development Team creates a formal Data Retention Plan according to the policies and standards established by the State Archivist.
The Data Retention Plan describes the project policies for data and records management.
The key elements of the Data Retention Plan include at minimum:
State of Maryland has legally mandated data retention policies that apply to all State agencies and State-created entities and any public records. The State Archivist’s website has records management guidance, including the laws, rules, and regulations, at http://www.msa.md.gov/msa/intromsa/html/record_mgmt/homepage.html. The Code of Maryland states that “The willful, unauthorized destruction or alienation of any public record is a misdemeanor subject to criminal penalties.” The State policy is that “a public record may not be disposed of without authorization from the State Archivist” and expects any part of the State, county, or local governments to follow this policy. This site provides additional guidance on how to develop a records retention schedule, which in turn helps the agency and Development Team create a Data Retention Plan for the project.
The Project Manager reviews the Data Retention Plan with the Development Team and project stakeholders to ensure acceptance and compliance.
The Project Manager oversees periodic system design reviews of the system functions, performance requirements, security requirements, and platform characteristics.
A system/subsystem design review is held at the end of each Design Phase iteration to resolve open issues regarding one or more of the following:
The Project Manager and the Development Team prepare and present a project status review for the Agency CIO, Project Sponsor, Executive Sponsor, and other project stakeholders after completion of all Design Phase tasks. This review addresses:
The Project Manager compares actual project performance to the baseline and the projected cost of the project to detect and understand any variances from the cost baseline during the phase-end review. The Project Manager also performs a comprehensive risk assessment of the project to update the Risk Register before beginning the next phase, Development.
The Project Manager must obtain deliverable approval signatures before proceeding to the Development Phase.
Update the project documentation repository upon completion of the phase-closure activities.
The Design Phase results in one of the two key elements to the project: the design. Without a detailed design, the second key element, the system, cannot be constructed, implemented, trained upon, or operated. The decisions made in this phase regarding technology, frameworks, implementation, and configuration and change management ensure a sound foundation for the project. While ambiguous requirements are the greatest source of project failure, a poor design ranks second. The approval of the Design Phase deliverables, the completion of the Design project status review, and the approval to proceed to the next phase, signify the end of the Design Phase.
100 Community Place, Crownsville, MD 21032
300-301 West Preston Street, Baltimore MD 21201
410-697-9700 - Dial 7-1-1 to place a call through Maryland Relay