Part 2. Information Technology

Chapter 120. Engineering

Section 7. Solution Design Process

2.120.7 Solution Design Process

Manual Transmittal

May 29, 2024

Purpose

(1) This transmits a new IRM 2.120.7 Solution Engineering - Solution Design Process Description (PD) and Procedure.

Material Changes

(1) Making changes to IRM to be OneSDLC Compliant.

Effect on Other Documents

IRM 2.120.7, December 28, 2022 is superseded

Audience

This process description is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for developing IT systems.

Effective Date

(05-29-2024)


Rajiv Uppal
Chief Information Officer

2.120.7.1 (05-29-2024)

Program Scope and Objectives

  1. Overview -This IRM describes the formal process for implementing the requirements of the Solution Design process.

  2. Purpose -This IRM contains procedural steps for System Designers to successfully select and design solutions to requirements.

  3. Audience - These procedures apply to IRS Information Technology (IT) employees and contractors who are responsible for selecting and designing computer systems.

  4. Policy Owner - Associate Chief Information Officer (ACIO), Enterprise Services, is responsible for overseeing all aspects of our systems that operate the nation’s tax infrastructure.

  5. Program Owner - Solution Engineering division (SE), which is under Information Technology, Enterprise Services (ES).

  6. Primary Stakeholders - Application Development (AD), Cybersecurity, Enterprise Operations (Eops), Solution Engineering (SE), Enterprise Architecture (EA), User and Network Services (UNS).

  7. Program Goals - This IRM provides the fundamental knowledge and procedural guidance for those who design and implement computer systems.

2.120.7.1.1 (12-28-2022)

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.

2.120.7.1.1.1 (12-28-2022)
Process Description

  1. This Solution Design process description describes what happens within the Solution Design 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 Solution Design process.

2.120.7.1.1.2 (12-28-2022)
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.

    • Solution is selected from alternative solutions

    • Solution designs are developed

2.120.7.1.1.3 (12-28-2022)
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)

2.120.7.1.2 (12-28-2022)

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the Solution Engineering division.

2.120.7.1.3 (12-28-2022)

Roles and Responsibilities

  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

    • Developing all required documentation at solution level
    Component Designer

    • Ensuring all standards are followed

    • Ensuring requirements are allocated to components and sub-components

    • Developing all required documentation at component level
    Designers

    • Refers to Solution Designer and Component Designer together
    Design Team

    • All designers
    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
    Quality Assurance (QA)

    • Verification of the execution of each of the process steps and the work products produced by them

2.120.7.1.4 (12-28-2022)

Program Management and Review

  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 Solution Design 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 Solution Design process will not be successful.
    Process:  
    Statement Modifications to the Solution Design 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 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 approved 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 approved 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. 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.
    Rationale Technology and tools should be used to augment the process capabilities, not become an end themselves.

2.120.7.1.5 (12-28-2022)

Program Control

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

2.120.7.1.5.1 (12-28-2022)
Control

  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
    Solution Engineering Policy (Directive) 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 upper 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.

    • Recency of signature (every 3 years)

    • Annual reviews
    Scope All projects will follow the Solution Design process which will be used to select, design, and implement solutions to requirements and associated activities in accordance with this policy.

2.120.7.1.5.2 (12-28-2022)
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.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Solution Design 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.

2.120.7.1.5.3 (12-28-2022)
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 Solution design Process owner.

  2. Step 1: “Develop Alternative Solutions” 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

  3. Step 2: “Develop Selection Criteria” 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:

    • Define selection criteria

    • Selection criteria for final selection

  4. Step 3: “Evaluate 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:

    • Evaluate each alternatives using the defines criteria

    • Select solution design

  5. Step 4: “Perform Make, Buy, or Reuse Analysis” 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 analysis

    • Guidelines for choosing COTS solution components

  6. Step 5: “Collect Technical Details” 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.

  7. Step 6: “Design the Solution Components” 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.

2.120.7.1.5.4 (12-28-2022)
Quality Assurance

  1. The Solution Design process may be part of a Quality Assurance review at the discretion of the Process Owner.

2.120.7.1.6 (12-28-2022)

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

2.120.7.1.6.1 (12-28-2022)
Terms and Definitions

  1. Terms and Definitions
     

    Term Definition
    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.
    Solution Design process The process used to select, design, and implement solutions to requirements.
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. “The actions are: R Responsible for the action (may do the task) A Accountable for the action (including approval) C Required to be Consulted on the action I Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.”

2.120.7.1.6.2 (12-28-2022)
Acronyms

  1. Acronyms
     

    Acronyms Definition
    COTS Commercial Off The Shelf
    OneSLDC One Solution Delivery Lifecycle
    ES Enterprise Services
    IPM Integrated Process Management
    IRM Internal Revenue Manual
    IRS Internal Revenue Service
    IT Information Technology
    PAL Process Asset Library
    PD Process Description
    PMI Project Management Institute
    QA Quality Assurance
    RACI Responsible, Accountable, Consulted and Informed
    SDSR Simplified Design Specification Report
    SE Solution Engineering
    SD Solution Design
    VSA Vision, Scope and Architecture

2.120.7.1.7 (12-28-2022)

Related Resources

  1. None

2.120.7.1.8 (12-28-2022)

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. The training resources available for this process are listed below:

    • Solution Design process training

2.120.7.2 (12-28-2022)

Process Workflow

  1. A process 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.

2.120.7.2.1 (12-28-2022)

Main Process Diagram

  1. Solution Design Process Diagram

    Figure 2.120.7-1

    This is an Image: 74885001.gif

    Please click here for the text description of the image.

2.120.7.2.2 (12-28-2022)

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 determine the expected outcome of the solution. VSA (Vision, Scope, and Architecture) for Agile
    Allocated Customer Requirements Allocated requirements are used to give context to the system requirements. VSA
    Operation Concept Concept of operation is used to give context to the system and allocated customer requirements Solution Concept, , VSA
    Functional Architecture Functional architecture is used to give context to the system requirements VSA
    Design Constraints Constraints are used to limit design and implementation alternatives Solution Engineering Software Engineering Practice Group

2.120.7.2.3 (12-28-2022)

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
    Technical Details Technical Detail will document the following:

    • 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

    • Criteria for design and Solution component reuse

    • Make-or-buy analysis

    • Guidelines for choosing COTS Solution components

    • Implemented design

    • Solution component designs

    • Rationale for selected interface design

    		 Engineering Documentation Process

2.120.7.2.4 (12-28-2022)

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
    SD 1.0 Develop Alternative Solutions 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.

    • Develop screening criteria to select a set of alternative solutions for consideration

    • 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
    SD 2.0 Develop Selection Criteria To develop criteria to select the solution.

    • Develop selection criteria

    • Assess the adequacy of the selection criteria
    SD 3.0 Evaluate and Select Solution To evaluate and select solution.

    • Evaluate each alternative solution

    • Identify and resolve issues with the alternative solutions and requirements

    • Select the best alternative solution

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

    • Identify the components to be reused or acquired

    • Identify and resolve issues with Component Requirements
    SD 4.0 Perform Make, Buy, or Reuse Analysis 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

    • Review analysis and decide which components are to be developed, re-used, and purchased
    SD 5.0 Collect Technical Details To collect all technical details:

    • 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 analysis

    • Guidelines for choosing COTS solution components
    SD 6.0 Design the Solution Components 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 applicable design standards and criteria

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

    • Ensure that the design adheres to allocated requirements

    • Design the solution / set of solution components

    • Perform interface design via “Interface Design” process

    • Perform hardware analysis & design/system configuration validation via “Hardware Analysis & Design/System Configuration Validation” process

    • Perform Data analysis via ”Data Management” process

    • Document the current level of technical details via SD Step 5.0 “Collect Technical Details”

    • Check for “all components designed”

    • If yes and all components at all levels are completed, then

      • Review design

      • revise design as needed, and document the changes via SD Step 5.0: Collect Technical Details

      • Go to external interface to “Engineering Documentation” process

    • If no and there are remaining components at same level, then go to activity SD Step 6.4 “Design the solution / set of solution components”

    • If no and need to go to next level of design details, then go to activity SD Step 1.0 “Develop Alternative Solutions”

2.120.7.2.5 (12-28-2022)

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.

2.120.7.2.5.1 (12-28-2022)
SD 1.0: Develop Alternative Solutions

  1. This step is to determine possible alternative solutions that meet requirements

    ID Task Name and Description Role RACI* Duties
    SD 1.1 Develop 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 RA

    • Consider following criteria:

    • Business objectives

    • Scope

    • End state operation concepts

    • Constraints (Design, Cost, Risk)

    • Alternative solution impact on current IT operations

    • Alternative solution impact on End Users
    SD 1.2 Identify candidate COTS products that meet the requirements
    This task is to identify possible candidate COTS products that meet the requirements    		 Designers RA

    • 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.
    SD 1.3 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 RA

    • 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
    SD 1.4 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 RA

    • 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
    SD 1.5 Generate alternative solutions
    Generate alternative solutions for review    		 Design Team RA

    • Generate alternative solutions for consideration

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

    • Review with appropriate stakeholders
    SD 1.6 Obtain a complete requirements allocation for each alternative
    Allocate applicable requirements to each alternative    		 Design Team RA

    • 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

    • Document each alternative

    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.

2.120.7.2.5.1.1 (12-28-2022)
Cross-Functional Flow Diagram

  1. Figure 2.120.7-2

    This is an Image: 74885002.gif

    Please click here for the text description of the image.

2.120.7.2.5.2 (12-28-2022)
SD 2.0: Develop Selection Criteria

  1. This step is to define criteria to select the solution

    ID Task Name and Description Role RACI* Duties
    SD 2.1 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 RA

    • Identify selection criteria (consider)

      • Satisfaction of Requirements (business, system, component)

      • Maintainability

      • Conformance to the Enterprise Architecture

      • Security

      • Level of Risk

      • Schedule Impact

      • Life Cycle Cost

    • Generate a list of selection criteria

    • Assign weight to criteria

    • Review with appropriate stakeholders

    • Update selection criteria and weights as needed

    • Document the criteria
    SD 2.2 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 RA

    • 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

    • Document the assessments

    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.

2.120.7.2.5.2.1 (12-28-2022)
Cross-Functional Flow Diagram

  1. Figure 2.120.7-3

    This is an Image: 74885003.gif

    Please click here for the text description of the image.

2.120.7.2.5.3 (12-28-2022)
SD 3.0: Evaluate and Select Solution

  1. This step is to evaluate and select Solution

    ID Task Name and Description Role RACI* Duties
    SD 3.1 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 RA

    • 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
    SD 3.2 Identify and resolve issues with the alternative solutions and requirements
    Identify issues with the alternative solutions and requirements and resolve issues    		 Design Team RA

    • 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
    SD 3.3 Select the best alternative solution
    Select the best alternative solutions that satisfy the established selection criteria    		 Design Team RA

    • Select the best alternative solutions that satisfy the established selection criteria

      • Score using criteria and associated weights

    • Document results
    SD 3.4 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 RA

    • Check requirements

    • Derive requirements for each component

    • Review with appropriate stakeholders

    • Follow requirement management process to establish the requirements in a formal repository
    SD 3.5 Identify Components to be reused or acquired
    Perform Make, Buy, or Reuse Analysis    		 Design Team RA

    • Use procedure for SD Step 4.0 “Perform Make, Buy, or Reuse Analysis”
    SD 3.6 Identify and resolve issues with Component Requirements
    Identify issues with component requirements and resolve issues    		 Design Team RA

    • Identify issues with component requirements

      • Identify gaps

    • Resolve issues with the components and requirements

      • Update allocated requirements as needed

    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.

2.120.7.2.5.3.1 (12-28-2022)
Cross-Functional Flow Diagram

  1. Figure 2.120.7-4

    This is an Image: 74885004.gif

    Please click here for the text description of the image.

2.120.7.2.5.4 (12-28-2022)
SD 4.0: Perform Make, Buy, or Reuse Analysis

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

    SD 4.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 RA

    • Existing component/design functionality meets requirements

    • Design constraints

    • Cost of implementing/acquiring/reusing

    • Schedule impact of implementing/acquiring/reusing

    • Operational impacts

    • Impact on users
    SD 4.2 Review criteria for reuse of Solution components
    The criteria for the reuse of solution criteria are review with stakeholders    		 Design Team, Stakeholders RAI

    • Review with applicable stakeholder
    SD 4.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 RAI

    • 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
    SD 4.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 RA

    • 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
    SD 4.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, Stakeholders RA

    • 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.

    • Use the SD procedure for Step SD 5.0 “Collect Technical Details”

    • Go to Step SD 6.0 “Design the Solution Components”

    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.

2.120.7.2.5.4.1 (12-28-2022)
Cross-Functional Flow Diagram

  1. Figure 2.120.7-5

    This is an Image: 74885005.gif

    Please click here for the text description of the image.

2.120.7.2.5.5 (12-28-2022)
SD 5.0 Collect Technical Details

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

    SD 5.1 Collect Technical Details
    Collect all technical details    		 Solution Designer, Component Designer RA

    • Collect the following technical details:_
       

    • 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 Analysis

    • Guidelines for choosing COTS solution components

    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.

2.120.7.2.5.5.1 (12-28-2022)
Cross-Functional Diagram

  1. Figure 2.120.7-6

    This is an Image: 74885006.gif

    Please click here for the text description of the image.

2.120.7.2.5.6 (12-28-2022)
SD 6.0 Design the Solution Components

  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

    SD 6.1 Establish and maintain applicable design standards and criteria
    Identify all design criteria    		 Solution Designer RA

    • Identify the attributes for the criteria such as simplicity, maintenance, portability, reliability, security, scalability, and reusability of coding standards

    • Identify Enterprise Architecture constraints • Identify architecture standards

    • Identify acceptable design patterns

    • Establish criteria against which the design can be evaluated

    • Update criteria as necessary for the design criteria
    SD 6.2 Ensure the design adheres to the design standards and criteria
    Follow the established design standards and criteria .    		 Solution Designer RA

    • Design the Solution or Solution component according to the design standards and criteria
    SD 6.3 Ensure the design adheres to allocated requirements
    Ensure all design components meet requirements    		 Solution Designer RA

    • Ensure all developed or existing solution components meet the allocated and derived requirements

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

    • Conduct peer reviews of design
    SD 6.4 Design the solution / set of solution components
    Designing of the solution    		 Design Team RA

    • Design the Solution or Solution component

    • Ensure integration for all solution components

    • Perform “Interface Design” process to perform interface design analysis

    • Perform “Hardware Analysis and Design/Configuration Validation” process to perform Hardware Analysis and Design/Configuration Validation analysis

    • Perform “Data Management” process to perform data management analysis

    • Use the SD Step 5.0 “Collect Technical Details” to document technical details
    SD 6.4.1 Check for “All components designed?”
    Check whether all components are being designed    		 Design Team RA

    • If yes, go to next activity step, SD 6.5 “Review Design”

    • If no but need next level of detail, design the next level of design components by going back to SD Step 1.0 “Develop Alternative Solutions”

    • If no and there are other components at same level of details still needed, then go to SD step 6.4 “Design the solution / set of solution components”
    SD 6.5 Review Design
    Review design with stakeholders    		 Stakeholders I

    • Ensure integration for all solution components

    • Review design with stakeholders
    SD 6.6 Revise design and technical details
    Revise design and technical details as needed    		 Design Team RA

    • Revise design as needed, and document the changes via SD Step 5.0 “Collect Technical Details”

    • Go to external interface to “Engineering Documentation” process

    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.

2.120.7.2.5.6.1 (12-28-2022)
Cross-Functional Flow Diagram

  1. Figure 2.120.7-7

    This is an Image: 74885007.gif

    Please click here for the text description of the image.