Chapter 5: Product Realization

The product realization side of the SE engine is where the rubber meets the road. In this portion of the engine, five interdependent processes result in systems that meet the design specifications and stakeholder expectations. These products are produced, acquired, reused, or coded; integrated into higher level assemblies; verified against design specifications; validated against stakeholder expectations; and transitioned to the next level of the system.

This effort starts with the technical team taking the output from the system design processes and using the appropriate crosscutting functions, such as data and configuration management, and technical assessments to make, buy, or reuse subsystems. Once these subsystems are realized, they must be integrated to the appropriate level as designated by the appropriate interface requirements. These products are then verified through the Technical Assessment Process to ensure they are consistent with the technical data package and that “the product was built right.” Once consistency is achieved, the technical team will validate the products against the stakeholder expectations that “the right product was built.”

This is an iterative and recursive process. Early in the life cycle, paper products, models, and simulations are run through the five realization processes. As the system matures and progresses through the life cycle, hardware and software products are run through these processes. It is important to catch errors and failures at the lowest level of integration and early in the life cycle so that changes can be made through the design processes with minimum impact to the project.

Product implementation is used to generate a specified product of a project or activity through buying, making/coding, or reusing previously developed hardware, software, models, or studies to generate a product appropriate for the phase of the life cycle. The product must satisfy the design solution and its specified requirement. Implementing the product can take one of three forms: Purchase/buy, Make/code, or Reuse. Regardless of what implementation form was selected, all work products from the make/buy/reuse process should be captured, including design drawings, design documentation, code listings, model descriptions, procedures used, operator manuals, maintenance manuals, or other documentation as appropriate.

The purpose of the Product Integration Process is to systematically assemble the higher level product from the lower level products or subsystems (e.g., product elements, units, components, subsystems, or operator tasks); ensure that the product, as integrated, functions properly; and deliver the product. Product integration is required at each level of the system hierarchy. The Product Integration Process applies not only to hardware and software systems but also to service-oriented solutions, requirements, specifications, plans, and concepts. The ultimate purpose of product integration is to ensure that the system elements will function as a whole.

An integration strategy is developed, as well as supporting documentation, to identify optimal sequence of receipt, assembly, and activation of the various components that make up the system. The optimal sequence of assembly is built from the bottom up as components become subelements, elements, and subsystems, each of which must be checked prior to fitting into the next higher assembly.

Integration occurs at every stage of a project’s life cycle. In the Formulation phase, the decomposed requirements need to be integrated into a complete system to verify that nothing is missing or duplicated. In the Implementation phase, the design and hardware need to be integrated into an overall system to verify that they meet the requirements and that there are no duplications or omissions.

The emphasis on the recursive, iterative, and integrated nature of systems engineering highlights how the product integration activities are not only integrated across all of the phases of the entire life cycle in the initial planning stages of the project, but also used recursively across all of the life-cycle phases as the project product proceeds through the flow down and flow up conveyed by the SE engine.

The Product Verification Process is the first of the verification and validation processes conducted on a realized end product. Realization is the act of verifying, validating, and transitioning the realized product for use at the next level up of the system structure or to the customer. It is essential to confirm that the realized product is in conformance with its specifications and design description documentation (i.e., verification).

Verification test outcomes can be unsatisfactory for several reasons. Many systems successfully complete verification but then are unsuccessful in some critical phase of the validation process, delaying development and causing extensive rework and possible compromises with the stakeholder. Developing a solid ConOps in early phases of the project (and refining it through the requirements development and design phases) is critical to preventing unsuccessful
validation.

The Product Validation Process is the second of the verification and validation processes conducted on a realized end product. While verification proves whether “the system was done right,” validation proves whether “the right system was done.” In other words, verification provides objective evidence that every “shall” statement was met, whereas validation is performed for the benefit of the customers and users to ensure that the system functions in the expected manner when placed in the intended environment. Validation confirms that realized end products at any position within the system structure conform to their set of stakeholder expectations captured in the ConOps, and ensures that any anomalies discovered during validation are appropriately resolved prior to product delivery.

[Note from Wikipedia]

Verification is intended to check that a product, service, or system (or portion thereof, or set thereof) meets a set of initial design requirements, specifications, and regulations. Validation is intended to check that development and verification procedures for a product, service, or system (or portion thereof, or set thereof) result in a product, service, or system (or portion thereof, or set thereof) that meets initial requirements, specifications, and regulations. It is sometimes said that validation can be expressed by the query "Are you building the right thing?"[1] and verification by "Are you building it right?" "Building the right thing" refers back to the user's needs, while "building it right" checks that the specifications are correctly implemented by the system.

[/Note]

Verification Testing: Verification testing relates back to the approved requirements set (such as an SRD) and can be performed at different stages in the product life cycle.
Validation Testing: Validation relates back to the ConOps document. Validation testing is conducted under realistic conditions (or simulated conditions) on any end product for the purpose of determining the effectiveness and suitability of the product for use in mission operations by typical users

There are five major steps in the validation process: (1) validation planning (prepare to implement the validation plan), (2) validation preparation (prepare for conducting validation), (3) conduct planned validation (perform validation), (4) analyze validation results, and (5) capture the validation work products.

The Product Transition Process is used to transition a verified and validated end product that has been generated by product implementation or product integration to the customer at the next level in the system structure for integration into an end product or, for the top-level end product, transitioned to the intended end user. Product transition occurs during all phases of the life cycle.