Internal Revenue Manual
IRM 2.120.7 — Solution Design Process
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
Program Scope and Objectives
2.120.7.1 (05-29-2024) Program Scope and Objectives 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.
Background
2.120.7.1.1 (12-28-2022) Background A process is defined as "A set of related activities that accomplish a common goal". The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.
Process Description
2.120.7.1.1.1 (12-28-2022) Process Description 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.
Goal
2.120.7.1.1.2 (12-28-2022) Goal 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
Objectives
2.120.7.1.1.3 (12-28-2022) Objectives 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)
Authority
2.120.7.1.2 (12-28-2022) Authority All proposed changes to this document must be submitted in writing, with supporting rationale, to the Solution Engineering division.
Roles and Responsibilities
2.120.7.1.3 (12-28-2022) Roles and Responsibilities 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
Program Management and Review
2.120.7.1.4 (12-28-2022) Program Management and Review 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.
Program Control
2.120.7.1.5 (12-28-2022) Program Control Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.
Control
2.120.7.1.5.1 (12-28-2022) Control 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.
Metrics
2.120.7.1.5.2 (12-28-2022) Metrics Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the 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.
Tailoring Guidelines
2.120.7.1.5.3 (12-28-2022) Tailoring Guidelines 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.
Quality Assurance
2.120.7.1.5.4 (12-28-2022) Quality Assurance The Solution Design process may be part of a Quality Assurance review at the discretion of the Process Owner.
Terms/Definitions/Acronyms
2.120.7.1.6 (12-28-2022) Terms/Definitions/Acronyms Terms/Definitions/Acronyms
Terms and Definitions
2.120.7.1.6.1 (12-28-2022) Terms and Definitions 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."
Acronyms
2.120.7.1.6.2 (12-28-2022) Acronyms 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
Related Resources
2.120.7.1.7 (12-28-2022) Related Resources None
Training
2.120.7.1.8 (12-28-2022) Training 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
Process Workflow
2.120.7.2 (12-28-2022) Process Workflow 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.
Main Process Diagram
2.120.7.2.1 (12-28-2022) Main Process Diagram Solution Design Process Diagram Figure 2.120.7-1 Solution Design Process Description Flow DiagramThis diagram is the process diagram for Solution DesignStep 1- Develop Alternative SolutionsStep 2- Develop Selection CriteriaStep 3- Evaluate and Select SolutionStep 4- Perform Make, Buy, or Reuse AnalysisStep 5- Collect Technical DetailsStep 6- Design the Solution Components Please click here for the text description of the image.
Inputs
2.120.7.2.2 (12-28-2022) Inputs 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
Outputs
2.120.7.2.3 (12-28-2022) Outputs 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
Activities
2.120.7.2.4 (12-28-2022) Activities 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"
Procedure
2.120.7.2.5 (12-28-2022) Procedure 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.
SD 1.0: Develop Alternative Solutions
2.120.7.2.5.1 (12-28-2022) SD 1.0: Develop Alternative Solutions 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.
Cross-Functional Flow Diagram
2.120.7.2.5.1.1 (12-28-2022) Cross-Functional Flow Diagram Figure 2.120.7-2 Develop Alternative Solutions Please click here for the text description of the image.
SD 2.0: Develop Selection Criteria
2.120.7.2.5.2 (12-28-2022) SD 2.0: Develop Selection Criteria 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.
Cross-Functional Flow Diagram
2.120.7.2.5.2.1 (12-28-2022) Cross-Functional Flow Diagram Figure 2.120.7-3 Develop Selection Criteria Please click here for the text description of the image.
SD 3.0: Evaluate and Select Solution
2.120.7.2.5.3 (12-28-2022) SD 3.0: Evaluate and Select Solution 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.
Cross-Functional Flow Diagram
2.120.7.2.5.3.1 (12-28-2022) Cross-Functional Flow Diagram Figure 2.120.7-4 Evaluate and Select Solution Please click here for the text description of the image.
SD 4.0: Perform Make, Buy, or Reuse Analysis
2.120.7.2.5.4 (12-28-2022) SD 4.0: Perform Make, Buy, or Reuse Analysis 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.
Cross-Functional Flow Diagram
2.120.7.2.5.4.1 (12-28-2022) Cross-Functional Flow Diagram Figure 2.120.7-5 Perform Make, Buy, or Reuse Analysis Please click here for the text description of the image.
SD 5.0 Collect Technical Details
2.120.7.2.5.5 (12-28-2022) SD 5.0 Collect Technical Details 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.
Cross-Functional Diagram
2.120.7.2.5.5.1 (12-28-2022) Cross-Functional Diagram Figure 2.120.7-6 Collect Technical Details Please click here for the text description of the image.
SD 6.0 Design the Solution Components
2.120.7.2.5.6 (12-28-2022) SD 6.0 Design the Solution Components 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.
Cross-Functional Flow Diagram
2.120.7.2.5.6.1 (12-28-2022) Cross-Functional Flow Diagram Figure 2.120.7-7 Design the Solution Components Please click here for the text description of the image.
Source: official text