HOME TAX NOTES RESEARCH FEDERAL INTERNAL REVENUE MANUAL

Part 2. Information Technology Chapter 120. Solution Engineering

2.120.7. Solution Design Process

Part 2. Information Technology

Chapter 120. Solution 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

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)

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

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)

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

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)

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”

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)

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

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

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)

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

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)

This data was captured by Tax Analysts from the IRS website on June 07, 2024.

Copy RID