Purpose:
Select, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate.
Objective:
Establishes organizational expectations for addressing the iterative cycle in which product or product component solutions are selected, designs are developed, and designs are implemented.
Description:
The Technical Solution process is applicable at any level of the product architecture and to every product, product component, and product related lifecycle process. Throughout the Technical Solution process, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.
The Technical Solution process focuses on the following:
- Evaluating and selecting solutions (sometimes referred to as “design approaches,” “design concepts,” or “preliminary designs”) that potentially satisfy an appropriate set of allocated functional and quality attribute requirements
- Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or otherwise implement the design as a product or product component)
- Implementing the designs as a product or product component
Typically, these activities interactively support each other. Some level of design, at times fairly detailed, can be needed to select solutions. Prototypes or pilots can be used as a means of gaining sufficient knowledge to develop a technical data package or a complete set of requirements. Quality attribute models, simulations, prototypes or pilots can be used to provide additional information about the properties of the potential design solutions to aid in the selection of solutions. Simulations can be particularly useful for projects developing systems-of-systems.
Technical Solution specific practices apply not only to the product and product components but also to product related lifecycle processes. The product related lifecycle processes are developed in concert with the product or product component. Such development can include selecting and adapting existing processes (including standard processes) for use as well as developing new processes.
Processes associated with the Technical Solution process receive the product and product component requirements from the requirements management processes. The requirements management processes place the requirements, which originate in requirements development processes, under appropriate configuration management and maintain their traceability to previous requirements.
For a maintenance or sustainment project, the requirements in need of maintenance actions or redesign can be driven by user needs, technology maturation and obsolescence, or latent defects in the product components. New requirements can arise from changes in the operating environment. Such requirements can be uncovered during verification of the product(s) where its actual performance can be compared against its specified performance and unacceptable degradation can be identified. Processes associated with the Technical Solution process should be used to perform the maintenance or sustainment design efforts.
For product lines, these practices apply to both core asset development (i.e., building for reuse) and product development (i.e., building with reuse). Core asset development additionally requires product line variation management (the selection and implementation of product line variation mechanisms) and product line production planning (the development of processes and other work products that define how products will be built to make best use of these core assets).
In Agile environments, the focus is on early solution exploration. By making the selection and tradeoff decisions more explicit, the Technical Solution process helps improve the quality of those decisions, both individually and over time. Solutions can be defined in terms of functions, feature sets, releases, or any other components that facilitate product development. When someone other than the team will be working on the product in the future, release information, maintenance logs, and other data are typically included with the installed product. To support future product updates, rationale (for trade-offs, interfaces, and purchased parts) is captured so that why the product exists can be better understood. If there is low risk in the selected solution, the need to formally capture decisions is significantly reduced.
Entrance Criteria:
- Design Specification Tools
- Simulators and Modeling Tools
- Prototyping Tools
- Scenario Definition and Management Tools
- Requirements Tracking Tools
- Interactive Documentation Tools
Exit Criteria:
- Product, Product Component, and Interface Designs
- Technical Data Packages
- Interface Design Documents
- Criteria for Design and Product Component Reuse
- Implemented Designs
- User, Installation, Operation, and Maintenance Documentation
Process and Procedures:
Tailoring Guidelines:
Organizations may choose to purchase a technical solution process and procedures rather than to develop them. Using the Causal Analysis and Resolution process, they can tailor the process to fit their organization.
Process Verification Record(s):
- Results of the Make, Buy, or Reuse Analysis
- Results of applying new methods and tools
- Alternative solution screening criteria
- Evaluation reports of new technologies
- Alternative solutions
- Selection criteria for final selection
- Evaluation reports of COTS or SaaS products
- Product component selection decisions and rationale
- Documented relationships between requirements and product
components - Documented solutions, evaluations, and rationale
Measure(s):
- Cost, schedule, and effort expended for rework
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Percentage of requirements addressed in the product or product component design
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Size and complexity of the product, product components, interfaces, and documentation
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Defect density of technical solutions work products
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Schedule for design activities
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify screening criteria to select a set of alternative solutions for consideration.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify technologies currently in use and new product technologies for competitive advantage.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify candidate COTS or SaaS products that satisfy the requirements.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify re-usable solution components or applicable architecture patterns.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Generate alternative solutions.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Obtain a complete requirements allocation for each alternative.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Develop the criteria for selecting the best alternative solution.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Evaluate each alternative solution/set of solutions against the selection criteria established in the context of the operational concepts and scenarios.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Based on the evaluation of alternatives, assess the adequacy of the selection criteria and update these criteria as necessary.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify and resolve issues with the alternative solutions and requirements.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Select the best set of alternative solutions that satisfy the established selection criteria.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Establish the functional and quality attribute requirements associated with the selected set of alternatives as the set of allocated requirements to those product components.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Identify the product component solutions that will be reused or acquired.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Establish and maintain the documentation of the solutions, evaluations, and rationale.
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
References:
When your employees have questions, they want immediate answers. And when different needs arise during the workday, employees are motivated to learn at the moment.
In-the-flow learning delivers real-time education when your employees need it most and unleashes opportunities to:
- Identify skills that need to be developed
- Implement practical approaches to support learning
- Discover how to better support skills development
Here are the training modules for Technical Solution:
This is a test