2.120.2 Technical Solution Process

Manual Transmittal

August 15, 2017

Purpose

(1) This transmittal revised IRM 2.120.2 Engineering - Technical Solution Process Description (PD) and Procedure.

Material Changes

(1) Revised the entire document with updated IPM Process Description and Procedure Templates

Effect on Other Documents

IRM 2.120.2 dated October 20, 2015 is superseded.

Audience

This process description is applicable to all project following the Enterprise Life Cycle (ELC).

Effective Date

(08-15-2017)

SRI Rao
Director, Enterprise Service Solution Engineering

Program Scope and Objectives

  1. This document describes the formal process for implementing the requirements of the Technical Solution process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome.

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

Process Description
  1. This Technical Solution process description describes what happens within the Technical Solution process and provides an operational definition of the major components of the process. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, and behavior characteristics of the Technical Solution process.

Goal
  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.
    The goal of this document, roles such as Solution Designer, Developer, etc. are provided to describe the following set of responsibilities for performing a particular set of related activities.

    • Solution is selected from alternative solutions

    • Solution designs are developed

    • Solution, and associated support documentation, are implemented from the design

Objectives
  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Simplified Design Specification Report (SDSR)

    • Interface control documents (ICD)

    • End-user training materials

    • User's manual

    • Operator's manual

    • Maintenance manual

    • Online help

Purpose of Procedure

  1. This document defines the step-by-step instructions on how to conduct the activities used to implement the Technical Solution process in the Solution Engineering. The purpose of a procedure document is to institutionalize and formalize the preferred method of performing tasks that staff is using. The objective is to have everyone using the same tools and techniques and follow the same repeatable steps so that the organization can quantify how well the procedure is working and train future staff members who may not currently know the routine. Ensuring consistency is a critical component for ensuring optimum efficiency

Workflow

  1. A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. Technical Solution Process Diagram

    Figure 2.120.2-1

    This is an Image: 59977000.gif

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Approved System Requirements System requirements are used in determining what the solution to be implemented is required to do. BSR
    Allocated Customer Requirements Allocated requirements are used to give context to the system requirements. BSR
    Operation Concept Concept of operation is used to give context to the system and allocated customer requirements Solution Concept, BSR
    Functional Architecture Functional architecture is used to give context to the system requirements BSR
    Design Constraints Constraints are used to limit design and implementation alternatives Solution Engineering Software Engineering Practice Group

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Simplified Design Specification Report (SDSR) SDSR is used to present the design of the solution, document design decisions and their rationale, and the relationship of the solution components to requirements.
    • Alternative solution screening criteria

    • Evaluation reports of new technologies

    • Alternative solutions

    • Selection criteria for final selection

    • Evaluation reports of COTS products

    • Solution component selection decisions and rationale

    • Documented relationships between requirements and solution components

    • Documented solutions, evaluations, and rationale

    • Solution architecture

    • Interface specification criteria

    • Criteria for design and Solution component reuse

    • Make-or-buy analyses

    • Guidelines for choosing COTS Solution components

    • Implemented design

    • Solution component designs

    • Rationale for selected interface design

    • Interface design specifications

    Verification and Validation processes
    Interface control documents (ICD) ICD is used to document agreements on interfaces between the responsible organizations or groups Product Integration Process
    Implemented design Implemented design is the implemented solution to the requirements, usually an IT system System Integrator
    End-user training materials These are materials used for training of end users about the solution. Users
    User's manual This is the reference material on the use of the solution aimed at the end user Users
    Operator's manual This is the reference material on the operation of the solution aimed at the operations staff Operators
    Maintenance manual This is the reference material on how to maintain the solution aimed at the maintenance staff Maintenance
    Online help These are the help screens available to users of the system to assist them in the use of the system Users

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    TS 1.0 Develop Alternative Solutions and Selection Criteria, and Select Solution To determine possible alternative solutions that meet requirements, define criteria to select the solution, and to select the components to be used in the solution.
    • Evaluate if a formal selection is needed

    • Identify screening criteria

    • Develop selection criteria

    • Identify candidate COTS products

    • Identify technologies

    • Identify re-usable solution components or applicable architecture patterns

    • Generate alternative solutions

    • Obtain a complete requirements allocation for each alternative

    • Evaluate each alternative solution

    • Identify and resolve issues with the alternative solutions and requirements

    • Asses the adequacy of the selection criteria

    • Select the best alternative solution

    • Allocate the functional and quality attribute requirements for the selected components

    • Identify the solution components to be reused or acquired

    • Identify and resolve issues with Component Requirements

    • Establish and maintain documentation

    TS 2.0 Perform Make, Buy, or Reuse Analyses To ensure that components and design patterns are reused when appropriate and ensures that reuse of components and design patterns conform to organization and project policy.
    • Develop criteria for the reuse of solution component designs and guidelines for use of COTS

    • Review Criteria for reuse of Solution Components

    • Analyze designs to determine if solution components should be developed, reused, or purchased including common designs and components

    • Analyze implications for maintenance when considering purchased or non-developmental (e.g., COTS, government off the shelf, and reuse) items

    • Consult with Performance Engineering Process to determine what if any performance implications there are

    • Review analysis and decide which components are to be developed, re-used, and purchased

    TS 3.0 Establish (/Update) a Simplified Design Specification Report (SDSR) To collect all documentation into a single package and to determine the level of detail to be retained.
    • Evaluation reports of selected new technologies

    • Evaluation reports of selected COTS products

    • Solution component selection decisions and rationale

    • Documented relationships between requirements and selected solution components

    • Documented solutions, evaluations, and rationale

    • Solution architecture

    • Solution component designs

    • Criteria for design and solution component reuse

    • Make-or-buy analyses

    • Guidelines for choosing COTS solution components

    TS 4.0 Design Interfaces Using Criteria To ensure interfaces are designed and agreed upon.
    • Define interface criteria

    • Identify interfaces associated with other solution components

    • Identify interfaces associated with external items

    • Identify interfaces between solution components and the solution-related lifecycle processes

    • Identify performance and capacity parameters for critical interfaces in consultations with the Performance Engineering process

    • Develop alternative interface design alternatives

    • Apply the criteria to the interface design alternatives

    • Select interface design from alternatives using interface criteria

    • Review, revise and concur with interface design

    • Document the selected interface designs and the rationale for the selection in the Design Specification Report

    TS 5.0 Design the Solution or Solution Component To literately design the solution and its sub-components. During the early iteration a logical / preliminary design is produced. During later iterations the detailed design is produced.
    • Establish and maintain criteria against which the design can be evaluated

    • Identify, develop, or acquire the design methods appropriate for the solution

    • Ensure that the design adheres to applicable design standards and criteria

    • Ensure that the design adheres to allocated requirements

    • Consult with the Performance Engineering Process to ensure design supports performance requirements and constraints

    • Design the solution / set of solution components

    • Document Current level of design

    • Review Design

    • Revise design and documentation as needed

    TS 6.0 Develop System Support Documentation To produce the documentation that the users, operators, and maintainers of the system need.
    • Develop preliminary versions of the installation, operations and maintenance documentation

    • Review preliminary versions with stakeholders, revise as needed

    • Review the requirements, design, solution, and test results

    • Adhere to the applicable documentation standards

    • Use effective methods to develop the installation, operation, and maintenance documentation

    • Conduct reviews of the installation, operation, and maintenance documentation

    • Revise the installation, operation, and maintenance documentation as necessary

    TS 7.0 Implement the Design To build a solution component.
    • Use the Software Development process to develop application elements of the solution

    • Use effective methods to implement the Solution components

    • Adhere to applicable standards and criteria

    • Use Software Testing Standards & Procedures process for unit testing and per reviews

    • Revise the Solution component as necessary

    • Use Product Integration process to integrate the solution components and the Solution into target environments

Roles

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Solution Designer
    • Selection of the Solution design

    • Identification of Solution components

    • Identification of component interfaces both internal and external

    • Ensuring all standards are followed

    • Ensuring requirements are allocated to components and sub-components

    • Developing all required documentation Solution Design

    Component Designer
    • Selection of the Solution design

    • Identification of Solution components

    • Identification of component interfaces both internal and external

    • Ensuring all standards are followed

    • Ensuring requirements are allocated to components and sub-components

    • Developing all required documentation Solution Design

    Developer
    • Creating and /or modifying code

    • Documenting code

    • Ensuring that all development work products are completed.

    Analyst
    • Performing studies

    • Modeling

    • Formal evaluations

    Performance Engineer
    • Allocation of performance requirements to components and sub-components

    • Providing guidance to designers and developers on performance related areas

    • Assessing the performance of the solution as designed and implemented

    • Developing any performance models and benchmarks needed to support the other responsibilities

    Stakeholders
    • These are the specific people or groups who have a stake, or an interest, in the outcome of the project

    • The stakeholders may be different for each step or activity.

    Higher Authority
    • Allocate additional resources, if required

    • Discuss the AEDAR results with the Lead Analyst

    Decision Making Authority
    • Receive the documented evaluation results

    • Assess the risks associated with implementing the recommended solution

    • Select solution(s)

    • Document and communicate to relevant stakeholders the results and rationale for the recommended solution.

    Quality Assurance (QA)
    • Verification of the execution of each of the process steps and the work products produced by them

Process Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Engineering Policy (Directive) Completion of Engineering Process The project will include in its engineering plan either by inclusion or reference, planning materials specifying how the following will be accomplished:
    • Execution Engineering Process

    • Obtaining needed resources to perform Engineering Process

    • Control of work products required by the Management Process

    • Engagement of stakeholders affected by the Data Management Process

    • Monitoring and Controlling of the Management Process

    • Collection of Management Process measures

    • Review of Management Process status with high level of management

    • Establishment of the Management Process within the project's defined processes

    • Submission of lesson learned and process improvement suggestions from the execution of Management Process.

    Scope All projects following the ELC will the Technical Solution process which will be used to select, design, and implement solutions to requirements and associated activities in accordance with this policy.

Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.
    Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Technical Solution process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

Policies

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management

    Statement: The Technical Solution process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.

    People

    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Technical Solution process will not be successful.

    Process

    Statement: Modifications to the Technical Solution process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.

    Technology and Tools

    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. The selected tools must support heterogeneous platforms. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following:
    • Design tools or methods

    • Testing tool

    • Documentation tool

    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Technical Solution Process owner.

  2. Step 1: Develop Alternative Solutions, Selection Criteria and Select Solution; may be tailored out when a project is a maintenance project whose design is dictated by the existing system or the design of the system is fully constrained by the Enterprise Architecture. If this step is tailored out, the following work products are not required:

    • Alternative solution screening criteria

    • Evaluation reports of new technologies

    • Alternative solutions

    • Selection criteria for final selection

    • Evaluation reports of COTS products

    • Solution component selection decisions and rationale

    • Documented relationships between requirements and solution components

    • Documented solutions, evaluations, and rationale

  3. Step 2: Perform Make, Buy, or Reuse Analyses; may be tailored out when the project is a maintenance project whose design is dictated by the existing system or the design of the system is fully constrained by the Enterprise Architecture. If this step is tailored out, the following work products are not required:

    • Criteria for design and solution component reuse

    • Make-or-buy analyses

    • Guidelines for choosing COTS solution components

  4. Step 3: Establish (/Update) a Simplified Design Specification Report (SDSR); may be tailored when the project is a maintenance project whose design is dictated by the existing system, no significant change is made to the systems logical design, and approved equivalent documentation exists. Updates to the equivalent documentation may be substituted and the activities modified as needed to support the updating of the documentation. The list of approved equivalent documentation is available on the IPM PAL. If the work product Documented Solutions, Evaluations, and Rationale is tailored out, references to existing requirements and traceability matrixes must be substituted.

  5. Step 4: Design Interfaces Using Criteria; may be tailored out when the project is a maintenance project that is not affecting any interfaces. If this step is tailored out, the following are not required:

    • Interface design specifications

    • Interface control documents

    • Interface specification criteria

    • Rationale for selected interface design

  6. Step 5: Design the Solution or Solution Component; may not be tailored out. If the work product Documented Solutions, Evaluations, and Rationale is tailored out then references to the enterprise Architecture or to existing design documentation must be substituted.

  7. Step 6: Develop System Support Documentation; may not be tailored out.

  8. Step 7: Implement the Design; may not be tailored out.

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Technical Solution process training class

Procedure

  1. A procedure provides the step by step instructions, or tasks, in how to perform each activity in the process and usually applies to a single role that will be responsible in performing the task.

Develop Alternative Solutions and Selection Criteria

  1. This step is to determine possible alternative solutions that meet requirements, define criteria to select the solution, and to select the components to be used in the solution

    ID Task Name and Description Role RACI* Duties
    TS 1.1 Consult with Performance Engineering process to identify any performance issues
    This is a call procedure to evaluate performance requirements for any issues
    Performance Engineer RC
    • Identify performance issues

    TS 1.2 Evaluate if a formal selection is needed
    This task is to decide if a formal evaluation is needed by reviewing project policy, and if a formal evaluation is needed execute the Engineering Decision Analysis and Resolution Procedure
    Designers RA
    • Obtain current approved requirements using the Requirement engineering process

    • Review Project policy on when to do a formal evaluation

    • Decide if a formal evaluation is needed by reviewing project policy

    • If a formal evaluation is needed execute the Engineering Decision Analysis and Resolution Procedure and skip steps 3 through 8

    TS 1.3 Identify screening criteria to select a set of alternative solutions for consideration
    Screening criteria are used to narrow down the list of alternatives to those consistent with business objectives. In this context business objectives include both IRS enterprise business objectives as well as the objectives of the project. Costs, operational impacts, and adherence to IRS policies such as the enterprise architecture need to be considered is identifying the screening criteria. Screening criteria are high level; they are a coarse screening tool. In general an alternative that fails any of the criteria is eliminated from consideration unless there is a compelling reason to retain it.
    Designers R
    • Identify screening criteria (consider)

      • Business objectives

        • Business / Customer requirements

      • Scope

      • End state operation concepts

      • Constraints

        • Design constraints

          • Project

          • Enterprise Architecture

        • Cost constraints

        • Risk analysis

        • Performance Issues

      • Alternative solution Impact on current IT operations

      • Alternative solution Impact on End users

    • Generate a list of screening criteria

    • Review with stakeholders

    • Update screening criteria as needed

    • Document the criteria

    TS 1.4 Develop the criteria for selecting the best alternative solution
    Selection criteria provide the basis for evaluating the alternative solutions. Criteria are ranked so that the highest ranked criteria exert the most influence on the evaluation. Unlike screening criteria selection criteria are meant to show the relative differences between alternatives not an absolute in or out determination
    Designers A
    R
    • Identify selection criteria (consider)

      • Satisfaction of Requirements (business, system, component)

      • Performance

      • Maintainability

      • Conformance to the Enterprise Architecture

      • Security

      • Level of Risk

      • Schedule Impact

      • Life Cycle Cost

      • Performance Issues

    • Generate a list of selection criteria

    • Assign weight to criteria

    • Review with appropriate stakeholders

    • Update selection criteria and weights as needed

    • Document the criteria

    TS 1.5 Identify candidate COTS products that satisfy the requirements
    Identify Possible COTS products through Research industry report, white papers, Enterprise Architecture, and the use of screening criteria to eliminate unlikely candidate technologies
    Designers AR
    • Identify Possible COTS products

      • Research industry report, white papers, etc..

      • Enterprise Architecture

      • Use screening criteria to eliminate unlikely candidate technologies

    • Use screening criteria to eliminate unlikely candidate COTS

    • Identify product functionality and quality.

      • Collect IRS experiences with products

      • Check industry reports / white papers

      • Vendor demonstrations

      • IF needed test product in house

    • Identify gaps between products’ functionality and requirements

    • Identify issues with products meeting non-functional requirements

    • Identify maintenance, support and upgrade service

    TS 1.6 Identify technologies currently in use and new Solution technologies for competitive advantage- efficiency
    Identify technologies applied to current products and processes and new technologies for competitive advantage
    Designers AR
    • Identify technologies applied to current products and processes

      • Research current applications using Enterprise Architecture assets.

    • Identify new technologies for competitive advantage

      • Research industry report, white papers, etc..

      • Use screening criteria to eliminate unlikely candidate technologies

    • Use screening criteria to eliminate unlikely candidate technologies

    TS 1.7 Identify re-usable solution components or applicable architecture patterns
    Identify the current system components that can be used for a solution and verify that they meet allocated requirements.
    Designers AR
    • Identify the current system components that can be used for a solution.

      • Check Enterprise Architecture

      • Check IRS experiences with candidate system components / architecture

        • Trouble tickets

        • Interview users / administrators

    • Verify that the identified components / architecture patterns can meet allocated requirements

    TS 1.8 Generate alternative solutions
    Generate alternative solutions for review
    Design Team A
    R
    • Generate for consideration

      • Generate for consideration

    • Generate a system diagram that depicts solution components for each alternative

    • Review with appropriate stakeholders

    TS 1.9 Obtain a complete requirements allocation for each alternative
    Put together a complete documentation for each alternative
    Design Team A
    R
    • Annotate each component depicted in the alternative solution with applicable requirements.

    • Add documentation developed in the previous activities about the selected components.

    • Review with stakeholders

    TS 1.10 Evaluate each alternative solution
    Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts and scenarios
    Design Team A
    R
    • Develop operating concepts for each alternative

    • Develop timeline scenarios for product operation and user interaction for each alternative solution

    • Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts and scenarios

    TS 1.11 Identify and resolve issues with the alternative solutions and requirements
    Identify issues with the alternative solutions and requirements and resolve issues
    Design Team A
    R
    • Identify issues with the alternative solutions and requirements

      • Identify gaps

    • Resolve issues with the alternative solutions and requirements

      • Update allocated requirements as needed

      • Update alternative solutions as needed

    TS 1.12 Assess the adequacy of the selection criteria
    Re-evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts and scenarios
    Design Team A
    R
    • Based on the evaluation of the alternatives, assess the adequacy of the selection criteria

    • Update selection criteria as necessary

    • Re-evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operating concepts and scenarios

    TS 1.13 Select the best alternative solution
    Select the best alternative solutions that satisfy the established selection criteria
    Design Team A
    R
    • Select the best alternative solutions that satisfy the established selection criteria

      • Score using criteria and associated weights

    • Document results

    TS 1.14 Allocate the functional and quality attribute requirements for the selected components
    Follow requirement management process to establish the requirements in a formal repository
    Design Team A
    R
    • Check requirements

    • Derive requirements for each component

    • Review with appropriate stakeholders

    • Follow requirement management process to establish the requirements in a formal repository

    TS 1.15 Identify the solution components to be reused or acquired
    Perform Make, Buy, or Reuse Analyses
    Design Team A
    R
    • Use procedure for TS process procedure for ETS step 2 - Perform Make, Buy, or Reuse Analyses

    • Document results

    • Check nonfunctional requirements

    TS 1.16 Identify and resolve issues with Component Requirements
    Identify issues with component requirements and resolve issues
    Design Team A
    R
    • Identify issues with component requirements

      • Identify gaps

    • Resolve issues with the components and requirements

      • Update allocated requirements as needed

    TS 1.17 Establish and maintain documentation
    Document the solutions, evaluations, and rationale according to the applicable sections of the applicable ELC DID or approved functional equivalent
    Design Team A
    R
    • Document the solutions, evaluations, and rationale according to the applicable sections of the applicable ELC DID or approved functional equivalent

    • Use the TS procedure for step 3 - Establish (/Update) a Simplified Design Specification Report (SDSR)

    • Update approved requirements using the requirement engineering process

    • Go to the Perform Make Buy or Reuse Analysis

    Note:

    *RACI is a responsibility matrix that describes the participation by various roles in completing the tasks or deliverable for a project or business process. RACI is derived from the four key responsibilities typically used:

    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

Cross-Functional Diagram
  1. Figure 2.120.2-2

    This is an Image: 59977001.gif

    Please click here for the text description of the image.

Perform Make, Buy, or Reuse Analyses

  1. This step is to ensure that components and design patterns are reused when appropriate and ensures that reuse of components and design patterns conform to organization and project policy

    TS 2.1 Develop criteria for the reuse of Solution components and guidelines for use of COTS
    Criteria are developed to be used to determine if an existing component design should be reused. Additionally criteria are developed for deciding whether components should be developed, reused, or bought
    Solution Designer, Component Designer AR
    • Existing component/design functionality meets requirements

    • Design constraints

    • Cost of implementing/acquiring/reusing

    • Schedule impact of implementing/acquiring/reusing

    • Operational impacts

    • Impact on users


    TS 2.2 Review criteria for reuse of Solution components
    The criteria for the reuse of solution criteria are review with stakeholders
    Solution Designer, Component Designer, Stakeholders ARI
    • Review with applicable stakeholder

    TS 2.3 Analyze designs to determine if solution components should be developed, reused or purchased
    The designs are analyzed to develop recommendation on which solution components are to be developed reused or purchased
    Solution Designer, Component Designer, Stakeholders ARI
    • Identify candidate existing or common designs

    • Identify candidate existing or common components

    • Identify candidate COTS solutions

    • Evaluate identified solutions against criteria

    • Evaluate development of component against criteria

    • Develop recommendation on whether to make, buy or reuse component

    • Document recommendation

    TS 2.4 Analyze implications for maintenance when considering purchase or non-developmental items
    Determine any issues with the maintenance of the components and if any of these issues make it necessary to reconsider the make, buy, or reuse decision. If necessary, revise the decision
    Solution Designer, Component Designer A
    R
    • Evaluate effect of make, buy or reuse recommendation Consider: Compatibility with future releases of COTS products, Creditability of vender, Configuration management of supplier changes, Defects in the non-developmental items and their resolution, and Unplanned obsolescence

    • Document evaluation

    TS 2.5 Review analysis and decide which components are to be developed, re-used, and purchased
    Based on the recommendation determine which components are to be developed, re-used, and purchased
    Design Team AR
    • Review recommendation on whether to make, buy or reuse component and evaluation on implications for maintenance.

    • Decide whether to make, buy or reuse component.

    • Document the decision and rationale.

    • Perform activities in ET process step 3 Establish / Update a Technical Data Package

    • Go to ET process step 4 Design Interfaces using Criteria

Cross-Functional Flow Diagram
  1. Figure 2.120.2-3

    This is an Image: 59977002.gif

    Please click here for the text description of the image.

Establish (/Update) a Simplified Design Specification Report (SDSR)

  1. To collect all documentation into a single package and to determine the level of detail to be retained.

    TS 3.1 Determine the number of levels of design and the appropriate level of documentation for each design level
    Following the Design Specification Reported (SDSR) DID, determine the level of detail needed to be included in the SDSR to adequately describe the design for stakeholder reviews and for the implementation of the design
    Solution Designer, Component Designer AR
    • Follow guidance contained in Simplified Design Specification Reported (SDSR) DID

    • Decide on the level of detail to describe the solution design for stakeholders and implementers

    TS 3.2 Determine the views to be used to document the architecture
    The views to be used in documenting the architecture are determined
    Solution Designer AR
    • Follow guidance contained in Simplified Design Specification Reported (SDSR) DID or equivalent

    • Specify views to be used

    TS 3.3 Review level of documentation to be maintained
    The views to be used in documenting the architecture are determined
    Design Team C
    • Review ELC guidance

    • Review DIDs to be followed

    • Determine and document level of design to be used

    TS 3.4 Base detailed design descriptions on the allocated solution component requirements, architecture and higher level designs
    The documentation of the design should be consistent across all levels of design documentation
    Component Designer A
    R
    • Ensure detailed design documentation reflects the components allocated requirements

    • Ensure the component design documentation is consistent with the design of its parent component documentation

    • Ensure the component design documentation is consistent with the solution architecture documentation

    TS 3.5 Document the key Decisions made including their rationale
    Documentation of the key decisions and their rationale is kept
    Solution Designer, Component Designer AR
    • Identify key decisions that significantly effected cost, schedule, or design

      • Architecture design

      • Make, buy, or reuse

      • Component design

    • Collect existing documentation on identified decisions. Format and insert decision documentation in appropriate section of SDSR

    TS 3.6 Document the design in the Design Specification Report, revise as needed
    SDSR should be kept up to date as the design progresses and revisions to the design are needed
    Solution Designer, Component Designer, Design Team (only performs activity steps 7 and 8) AR
    I
    • Review for correctness

    • Review when changes to design occur

    • Review when requirements change

    • Update as necessary

    • Wait for level of design to be complete

    • Perform TS process step 6 (Develop System Support Documentation)

    • Perform external process Enterprise Life Cycle Review

    • Go to TS Process step 7 Implement the design and if appropriate external process software Development

Cross-Functional Diagram
  1. Figure 2.120.2-4

    This is an Image: 59977003.gif

    Please click here for the text description of the image.

Design Interfaces Using Criteria

  1. To ensure interfaces are designed and agreed upon

    TS 4.1 Define Interface Criteria
    Interface criteria is defined
    Solution Designer AR
    • Consider the following parameters:

      • Origination

      • Destination

      • Stimulus

      • Protocol

      • Efficiency

      • Response times

      • Error rate

      • Error detection

      • Data characteristics for software

      • Electrical and mechanical characteristics for hardware

      • Availability

      • Reliability

      • Scheduled times

    • Consult with Performance Engineering process to identify performance criteria

    • Identify and document interface criteria

    TS 4.2 Define Interface Criteria
    Identify interfaces associated with other solution components.
    Solution Designer AR
    • Identify all interfaces with other solution components (internal interfaces)

      • Check for source of needed inputs

      • Check for destinations of outputs

      • Check component functional requirements

      • Check interface requirements

    TS 4.3 Identify interfaces associated with external items
    Interfaces external to the Solutions are identified
    Solution Designer AR
    • Identify all interfaces with external components (external interfaces)

      • Check for source of needed inputs

      • Check for destinations of outputs

      • Check component functional requirements

      • Check interface requirements

    TS 4.4 Identify interfaces between solution components and the solution-related lifecycle processes
    Interfaces to the various environments and processes that the solution will encounter during its lifecycle are identified. These may include testing environments, integration environments, production environments, and operational procedures
    Solution Designer A
    R
    • The documentation of the design should be consistent across all levels of design documentation

      • Integration environment

      • Testing environments

      • Production environment

      • Production processes

      • Development environment

      • Maintenance environment

    TS 4.5 Develop interface design alternatives
    For each identified interface alternative designs are developed
    Design Team R
    • Consider design constraints

    • Examine existing interfaces

    • Develop interface design alternatives

      • 3 alternatives for consideration are preferred

      • Reuse and design constraints may limit design options

    • Ensure all alternatives meet interface requirements

    • Consult with Performance Engineering process verify all alternatives meet performance requirements

    TS 4.6 Apply the criteria to the interface design alternatives
    Evaluate the interface alternative designs against criteria
    Design Team R
    • Determine if design supports the parameters defined in the criteria

    • Determine if design supports the parameter values defined in the criteria

    • Identify any interface requirement gaps for the design

    • Rank the designs

      • Consider support for criteria

      • Cost

      • Schedule

    TS 4.7 Select interface designs from alternatives using interface criteria
    Select a best interface design alternative
    Design Team R
    • Consider ranking of alternatives

    • Consider impact on interfacing component

    • Select design

    • Update criteria as needed

    TS 4.8 Apply the criteria to the interface design alternatives
    Apply the criteria for weighing and scoring purposes.
    External System Owner CI
    • Review Interface Design

    • Revise as necessary

    • Concur with the interface design, sign completed ICD

    TS 4.9 Document the selected interface designs and the rationale
    Document the result and rationale
    Design Team R
    • Document the selected interface design in the Simplified Design Specification Report (SDSR)

    • Document The rationale for the selection in the Simplified Design Specification Report (SDSR)

    • Develop ICD if external interface

      • Coordinate with owner of external system / component

    • Revise ICD as needed

Cross-Functional Diagram
  1. Figure 2.120.2-5

    This is an Image: 59977004.gif

    Please click here for the text description of the image.

Design the Solution or Solution Component

  1. To outline the activities required to design the solution and its sub-components. During the early iteration a logical / preliminary design is produced. During later iterations the detailed design is produced

    TS 5.1 Establish and maintain criteria against which the design can be evaluated
    Identify all design criteria
    Solution Designer AR
    • Identify the attributes for the criteria such as performance, simplicity, maintenance, portability, reliability, security, scalability, and reusability of coding standards

    • Identify Enterprise Architecture constraints • Identify architecture standards

    • Identify acceptable design patterns

    • Identify coding standards

    • Consult with Performance Engineering process to Identify Performance criteria

    • Establish criteria against which the design can be evaluated

    • Update criteria as necessary for the design criteria

    TS 5.2 Identify develop or acquire the design methods appropriate for the solution
    Interfaces internal to the Solution are identified
    Solution Designer AR
    • Identify appropriate design methods for the solution

    • Consider tools availability to support the design methods

    • Select the design methods that provide:

      • The designer efficient methods to specify the design

      • The designer with efficient methods to verify the design (modeling, prototypes, ops concepts, scenarios, etc.)

      • Easy and complete documentation of the design

      • Methods and tools that match the complexity of the solution

    • Develop or acquire design methods Consider:

      • Use of methods and tools already

      • Training on selected method / tools

    • Decide whether to develop or acquire design methods

    TS 5.3 Ensure the design adheres to applicable design standards and criteria
    Usage of appropriate design tools for the design.
    Design Team R
    • Design the Solution or Solution component using appropriate design tools

    TS 5.4 Ensure the design adheres to allocated requirements
    Ensure all design components meet requirements
    Solution Designer R
    • Ensure all developed or existing solution components meet the allocated and derived requirements

    • Ensure all COTS solution components meet the allocated and derived requirements

    • Consult with Performance Engineering Process to ensure all components meet performance requirements

    • Conduct peer reviews of design

    TS 5.5 Design the solution / set of solution components
    Designing of the solution
    Design Team R
    • Design the Solution or Solution component using appropriate design tools

    TS 5.6 Document the current level of design
    Capturing design level documentation
    Design Team R Rank the designs
    • Document the design in the Simplified Design Specification Report (SDSR)

      • See Technical Solution Procedure for Process Step 3 Establish / Update a Technical Data Package

      • Generate Government Equipment List (GEL) as needed

    TS 5.7 Review Design
    Identify all design criteria
    Stakeholders CI
    • Review the design and document comments

    TS 5.8 Revise design and documentation as needed
    Revise the design and update documentation as necessary
    Design Team R
    • Revise the design as needed

    • Document the revised design

Cross-Functional Flow Diagram
  1. Figure 2.120.2-6

    This is an Image: 59977005.gif

    Please click here for the text description of the image.

Develop System Support Documentation

  1. To outline the activities required to produce the documentation that the users, operators, and maintainers of the system need

    TS 6.1 Develop Preliminary versions of the installation, operations and maintenance documentation
    Develop draft versions of the support documentations
    Developer R
    • Prepare annotated outlines of the required support documentation

    TS 6.2 Review, revise, and concur with installation, operations and Maintenance documentation outline
    Review and modify the documentation outlines
    Operations Team R
    • Review and revise annotated outlines

    TS 6.3 Review requirements, design, solution and test results
    Review design and test results
    Developer R
    • Review:

      • Requirements

      • Design

      • Product

      • Test results

    • Identify all issues that need to be reflected in the following artifacts:

      • Installation manual

      • User’s manual

      • Operation manual

      • Maintenance manual

    TS 6.4 Adhere to applicable documentation standards
    Ensure all documentations are following the standards
    Developer R
    • Review documents to ensure documentation in conformance with applicable documentation standards

    TS 6.5 Use effective methods to develop the installation, operations and maintenance documentation
    Usage of effective methods to develop and maintain documentations
    Developer R
    • Identify effective methods for developing:

      • Installation instructions

      • End-user training materials

      • User's manual

      • Operator's manual

      • Maintenance manual

      • Online help

    • Consider existing documentation methods

    • Documentation should contain the following:

      • Objective

      • Author(s)

      • Products and services

      • Policies

      • Systems

      • Document specific information

    • Develop or acquire documentation methods if there is no existing documentation methods:

      • Decide whether to develop or acquire documentation methods.

      • Identify and acquire tools if necessary

    TS 6.6 Review installation, operations and Maintenance documentation
    Review and comment on installation, operations and Maintenance documentation
    Operations Team C
    • Review and comment on installation, operations and Maintenance documentation

    TS 6.7 Revise the installation, operation, and maintenance documentation as necessary
    Revise support documentations as necessary
    Developer R
    • Revise the installation, operation, and maintenance documentation as necessary

Cross-Functional Flow Diagram
  1. Figure 2.120.2-7

    This is an Image: 59977006.gif

    Please click here for the text description of the image.

Implement the Design

  1. To build a solution component. This procedure is iterated until all components of the solution have been implemented

    TS 7.1 Use effective methods to implement the solution components
    Use effective methods to implement the solution components
    Developer R
    • Use effective methods to implement the solution components

    TS 7.2 Adhere to applicable standards
    Adhere to applicable standards
    Developer R
    • Adhere to applicable standards

    TS 7.3 Revise components as necessary
    Revise Components as needed and retest
    Developer R
    • Using Software Testing Standards & procedures test components

    • Revise Components as needed and retest

    • Submit Components to Product Integration process

    • Revise Components as needed

Cross-Functional Flow Diagram
  1. Figure 2.120.2-8

    This is an Image: 59977007.gif

    Please click here for the text description of the image.

Appendix

  1. Appendix

Acronyms

Acronyms Definition
AEDAR Enterprise Architecture & Engineering Decision Analysis & Resolution
BSR Business System Report
CMMI Capability Maturity Model Integration
COTS Commercial Off The Shelf
ELC Enterprise Life Cycle
ES Enterprise Services
ESC Executive Steering Committee
ICD Interface Control Document
IPM Integrated Process Management
IRM Internal Revenue Manual
IRS Internal Revenue Service
IT Information Technology
ITIL Information Technology Infrastructure Library
ITSM Information Technology Service Management
PAL Process Asset Library
PD Process Description
PMI Project Management Institute
QA Quality Assurance
SDSR Simplified Design Specification Report
SE Solution Engineering
SEPM Solution Engineering Process Maturity
TS Technical Solution
XML Extensible Markup Language

Glossary

Term Definition
Bidirectional vertical requirements traceability Associations between a requirement and its subordinate requirements that are discernible in either direction
Customer requirement The result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product’s relevant stakeholders in a way that is acceptable to the customer.
Entry Criteria The elements and conditions (state) necessary to trigger the beginning of a process step
Exit Criteria The elements or conditions (state) necessary to trigger the completion a process step.
Technical Solution process The process used to select, design, and implement solutions to requirements.
Implemented design A component that has been developed and tested following its design and component.