Purpose:

Product or product component solutions are selected from alternative solutions.

Objective:

<?>

Description:

Alternative solutions and their relative merits are considered in advance of selecting a solution. Key requirements, design issues, and constraints are established for use in alternative solution analysis. Architectural choices and patterns that support achievement of quality attribute requirements are considered. Also, the use of commercial off-the-shelf (COTS) or Software as a Service (SaaS) product components are considered relative to cost, schedule, performance, and risk. COTS or SaaS alternatives can be used with or without modification. Sometimes such items can require modifications to aspects such as interfaces or a customization of some of the features to correct a mismatch with functional or quality attribute requirements, or with architectural
designs.

One indicator of a good design process is that the design was chosen after comparing and evaluating it against alternative solutions. Decisions about architecture, custom development versus off the shelf, and product component modularization are typical of the design choices that are addressed. Some of these decisions can require the use of a formal evaluation process.

Sometimes the search for solutions examines alternative instances of the same requirements with no allocations needed for lower level product components. Such is the case at the bottom of the product architecture. There are also cases where one or more of the solutions are fixed (e.g., a specific solution is directed or available product components, such as COTS or SaaS, are investigated for use).

In the general case, solutions are defined as a set. That is, when defining the next layer of product components, the solution for each of the product components in the set is established. The alternative solutions are not only different ways of addressing the same requirements, but they also reflect a different allocation of requirements among the product components comprising the solution set. The objective is to optimize the set as a whole and not the individual pieces. There will be significant interaction with processes associated with the Requirements Development process area to support the provisional allocations to product components until a solution set is selected and final allocations are established.

Product related lifecycle processes are among the product component solutions that are selected from alternative solutions. Examples of these product related lifecycle processes are the manufacturing, delivery, and support processes.

Entrance Criteria:

  • <?>

Exit Criteria:

  • <?>

Process and Procedures:

Tailoring Guidelines:

  • None

Process Verification Record(s):

  • Alternative solution screening criteria
    • Stored By: <?>
  • Evaluation reports of new technologies
    • Stored By: <?>
  • Alternative solutions
    • Stored By: <?>
  • Selection criteria for final selection
    • Stored By: <?>
  • Evaluation reports of COTS or SaaS products
    • Stored By: <?>
  • Product component selection decisions and rationale
    • Stored By: <?>
  • Documented relationships between requirements and product
    components
    • Stored By: <?>
  • Documented solutions, evaluations, and rationale
    • Stored By: <?>

Measure(s):

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