Description
The Design Phase seeks to develop detailed specifications that emphasize the physical solution to the user's information technology needs. The system requirements and logical description of the entities, relationships, and attributes of the data that were documented during the Requirements Analysis Phase are further refined and allocated into system and database design specifications that are organized in a way suitable for implementation within the constraints of a physical environment (e.g., computer, database, facilities).

A formal review of the high-level architectural design is conducted prior to detailed design of the automated system/application to achieve confidence that the design satisfies the system requirements, is in conformance with the enterprise architecture and prescribed design standards, to raise and resolve any critical technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or business risks affecting continued detailed design and subsequent lifecycle activities. During the Design Phase, the initial strategy for any necessary training is also begun. Estimates of project expenses are updated to reflect actual costs and estimates for future phases. In addition, the work planned for future phases is redefined, if necessary, based on information acquired during the Design Phase.

For COTS products, some tasks and activities may have been performed by the vendor and vendor documentation may be appropriate to meet some documentation requirements. This is acceptable as long as each required activity is performed and each required deliverable is available.

Responsibilities
Business Owner: The Business Owner may participate in the Preliminary Design Review.

Project Manager: The Project Manager is responsible and accountable for the successful execution of the Design Phase. The Project Manager is responsible for leading the team that accomplishes the phase activities and deliverables.

Integrated Project Team: The Integrated Project Team members (regardless of the organization of permanent assignment) are responsible for accomplishing assigned tasks as directed by the Project Manager.

Contracting Officer: The Contracting Officer is responsible and accountable for preparing solicitation documents under the guidance of the Project Manager.

Critical Partners: The Critical Partners participate in a Design Review to ensure compliance with policies in their respective areas and to make any necessary tradeoff decisions if conflicting goals have arisen during the Design.

Enterprise Architecture: Conduct a formal review of the high-level architectural design to achieve confidence that the design satisfies the system requirements, is in conformance with the Enterprise Architecture and prescribed design standards.

• Security: Establish that Security documents (C&A, Privacy Impact Assessment, System of Record Notice, and Computer Match Agreement) are reviewed for completeness and accuracy and that Contingency/Disaster Recovery Plan includes complete procedures, arrangements and responsibilities. Verify that project security risks are identified and mitigation plans are made.

• Acquisition: Verify that contracts are being fulfilled according to award or approved changes.

• Budget: Guarantee that the budget is sufficient to meet the needs of the project. Determine if project business risks are identified and mitigation plans are made.

• Finance: Guarantee that estimates of project expenses have been updated to reflect actual costs and estimates for future phases. Determine if project business risks are identified and mitigation plans are made.

• HR: Confirm that issues related to staffing, workforce, or other HR areas have been addressed.

• Section 508: Establish that any new or further requirements that have been discovered that are necessary to accommodate individuals with disabilities have been added to the Requirements Document and the Design documents. Confirm that there are test cases which incorporate Section 508 standards.

• CPIC: Make sure that the Design is fully documented.

• Performance: Determine if project technical risks are identified and mitigation plans are made. Verify that performance goals are agreed upon.

IT Governance Organization: The IT governance organization conducts the Preliminary Design Review to achieve agreement and confidence that the design satisfies the functional and non-functional requirements and is in conformance with the enterprise architecture.

Activities
The following tasks are performed during the Design Phase.

The Design Document is developed by the Project Manager and Integrated Project Team, identifying the steps used in the design of the application/system. The prerequisites for this phase are the Business Case, Project Management Plan, and Requirements Document. The Project Manager and Integrated Project Team identify/specify the target environment, the development environment and the design environment. The business organization, roles and procedures for designing this system/application are articulated. The Design Document is a deliverable of the Design Phase. Documents from the previous phases are revised as necessary during the Design Phase.

In the system design, first the general system characteristics are defined. The data storage and access for the database layer are designed. The user interface at the desktop layer is designed. The business rules layer or the application logic is designed. The interfaces from application to application and application to database also are designed and documented.

Based on the Privacy Impact Assessment, developed during the Planning Phase, a System of Record Notice (SORN) is prepared, if required, to inform the public of any information collection by the Business Product about citizens. A Computer Match Agreement (CMA) is also prepared, if needed, to establish the conditions, safeguards, and procedures under which HHS agrees to disclose data where there is a computerized comparison of two or more automated System of Records (SORs).

A Contingency/Disaster Recovery Plan is developed containing emergency response procedures; backup arrangements, procedures and responsibilities; and post-disaster recovery procedures and responsibilities. It is included in this phase because many of these factors will affect the design of the system. During the Design Phase, a final draft Test Plan is also prepared. The Test Plan describes the test cases and test environment specifications, and includes a Requirements Traceability Matrix that maps requirements to the specific tests to be conducted in the Test Phase. This final draft Test Plan will be used in the Development Phase to test components as they are built and integrated.

The system user community is included in Design Phase actions as needed. New or further requirements might be discovered that are necessary to accommodate individuals with disabilities. If so, these requirements are added to the RD and the design documents.

Exit Criteria
Objective: To determine if the design process will create a Business Product that meets the requirements within a specified project budget and schedule.

Phase Specific Exit Criteria:

• No outstanding concerns among stakeholders regarding design adequacy or feasibility.

• Design is adequately documented to allow effective and efficient development.

• Contingency/Disaster Recovery plans are adequately documented to provide clear procedures and responsibilities

• Security Documents are as complete and accurate as possible.

Generic Exit Criteria:

• Variances from baselines have been identified and mitigated. [Cost and schedule variances and scope changes are identified, significant variances are explained, and Corrective Action Plans (CAPs) or rebaseline requests are in place as appropriate.]

• Investment baselines have been reviewed and revised as appropriate. [Should this investment continue as-is, be modified, or be terminated based on current knowledge?]

• The Project Management Plan and component plans have been reviewed and appropriately updated. [This includes Risk Management, Acquisition Strategy, Change Management, Configuration Management, Project Categorization, Requirements Management, Communication Plan, WBS/Schedule, IV&V Planning, Quality Assurance, Records Management, Staff Development Plan and Security Approach.]

Project Review
The Detailed Design Review (DDR) is conducted subsequent to a PDR to achieve confidence that the individual design components (units/modules) of an automated system/application, and how they interface with one another, have been completely defined and documented in sufficient detail such that the design of the automated system/application is complete, fully integrated, and ready to move to the Development Phase. Upon successful completion of this review, the Design Document and other adjunct documents are baselined.

The DDR should identify and resolve open issues regarding any of the following:

• The system-wide or subsystem-wide design decisions.

• The architectural design of a software system or subsystem.

• The software-wide design decisions.

• The architectural design of a software item.

The detailed design of a software item or portion thereof (such as a database).

Stage Gate Review
The Preliminary Design Review (PDR) is a formal inspection of the high-level architectural design of an automated system, its software and external interfaces, which is conducted to achieve agreement and confidence that the design satisfies the functional and non-functional requirements and is in conformance with the enterprise architecture. Overall project status, proposed technical solutions, evolving software products, associated documentation, and capacity estimates are reviewed to determine completeness and consistency with design standards, to raise and resolve any technical and/or project-related issues, and to identify and mitigate project, technical, security, and/or business risks affecting continued detailed design and subsequent development, testing, implementation, and operations & maintenance activities. This review is one of the four Stage Gate Reviews that cannot be delegated by the IT governance organization.