Internal Revenue Manual Part 2. Information Technology

Official source: Internal Revenue Manual (https://www.irs.gov/irm/part2/irm_02-120-007), retrieved 2026-10-03. U.S. Government work (17 U.S.C. § 105).

---

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

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

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

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

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

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.

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

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

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

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.

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.

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

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)

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

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

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.

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

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.

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

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.

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

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

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

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

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.

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.

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

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

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

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

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.

Solution Design Process Diagram

Figure 2.120.7-1

Please click here for the text description of the image.

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

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

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”

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.

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

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

Figure 2.120.7-2

Please click here for the text description of the image.

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

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

Figure 2.120.7-3

Please click here for the text description of the image.

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

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

Figure 2.120.7-4

Please click here for the text description of the image.

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”

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

Figure 2.120.7-5

Please click here for the text description of the image.

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

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

Figure 2.120.7-6

Please click here for the text description of the image.

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

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

Figure 2.120.7-7

Please click here for the text description of the image.

More Internal Revenue Manual

Share

Facebook

Twitter

Linkedin

Print