Process ID

SYS.1

Process name

Requirements Elicitation

Process purpose

The purpose of the Requirements Elicitation Process is to gather, process, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products.

Process outcomes

As a result of successful implementation of this process:

1) continuing communication with the stakeholder is established;

2) agreed stakeholder requirements are defined and baselined;

3) a change mechanism is established to evaluate and incorporate changes to stakeholder requirements into the baselined requirements based on changing stakeholder needs;

4) a mechanism is established for continuous monitoring of stakeholder needs;

5) a mechanism is established for ensuring that customers can easily determine the status and disposition of their requests; and

6) changes arising from changing technology and stakeholder needs are identified, the associated risks assessed and their impact managed.

Base practices

SYS.1.BP1: Obtain stakeholder requirements and requests. Obtain and define stakeholder requirements and requests through direct solicitation of customer input and through review of customer business proposals (where relevant), target operating and hardware environment, and other documents bearing on customer requirements. [OUTCOME 1, 4]

NOTE 1: Requirements elicitation may involve the customer and the supplier.

NOTE 2: The agreed stakeholder requirements and evaluation of any change may be based on feasibility studies and/or cost and time analyzes.

NOTE 3: The information needed to keep traceability for each customer requirement has to be gathered and documented.

SYS.1.BP2: Understand stakeholder expectations. Ensure that both supplier and customer understand each requirement in the same way. [OUTCOME 2]

NOTE 4: Reviewing the requirements and requests with the customer supports a better understanding of customer needs and expectations. Refer to the process SUP.4 Joint Review.

SYS.1.BP3: Agree on requirements. Obtain an explicit agreement from all relevant parties to work on these requirements. [OUTCOME 2]

SYS.1.BP4: Establish stakeholder requirements baseline. Formalize the stakeholder's requirements and establish them as a baseline for project use and monitoring against stakeholder needs. The supplier should determine the requirements not stated by the stakeholder but necessary for specified and intended use and include them in the baseline. [OUTCOME 2, 3]

SYS.1.BP5: Manage stakeholder requirements changes. Manage all changes made to the stakeholder requirements against the stakeholder requirements baseline to ensure enhancements resulting from changing technology and stakeholder needs are identified and that those who are affected by the changes are able to assess the impact and risks and initiate appropriate change control and mitigation actions. [OUTCOME 3, 6]

NOTE 5: Requirements change may arise from different sources as for instance changing technology and stakeholder needs, legal constraints.

NOTE 6: An information management system may be needed to manage, store and reference any information gained and needed in defining agreed stakeholder requirements.

SYS.1.BP6: Establish customer-supplier query communication mechanism. Provide means by which the customer can be aware of the status and disposition of their requirements changes and the supplier can have the ability to communicate necessary information, including data, in a customer-specified language and format. [OUTCOME 5]

NOTE 7: Any changes should be communicated to the customer before implementation in order that the impact, in terms of time, cost and functionality can be evaluated.

NOTE 8: This may include joint meetings with the customer or formal communication to review the status for their requirements and requests; Refer to the process SUP.4 Joint Review.

NOTE 9: The formats of the information communicated by the supplier may include computer-aided design data and electronic data exchange.

Output work products

08-19 Risk management plan 08-20 Risk mitigation plan

→

→

[Outcome 6]

[Outcome 6]

13-04 Communication record

→

[Outcome 1, 4]

13-19 Review record

→

[Outcome 4, 5]

13-21 Change control record

→

[Outcome 3, 4]

15-01 Analysis report

→

[OUTCOME 2, 3, 6]

17-03 Stakeholder Requirements

→

[Outcome 1, 2]

Process ID

SYS.2

Process name

System Requirements Analysis

Process purpose

The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system.

Process outcomes

As a result of successful implementation of this process:

1) a defined set of system requirements is established;

2) system requirements are categorized and analyzed for correctness and verifiability;

3) the impact of system requirements on the operating environment is analyzed;

4) prioritization for implementing the system requirements is defined;

5) the system requirements are updated as needed;

6) consistency and bidirectional traceability are established between stakeholder requirements and system requirements;

7) the system requirements are evaluated for cost, schedule and technical impact; and

8) the system requirements are agreed and communicated to all affected parties.

Base practices

SYS.2.BP1: Specify system requirements. Use the stakeholder requirements and changes to the stakeholder requirements to identify the required functions and capabilities of the system. Specify functional and non-functional system requirements in a system requirements specification. [OUTCOME 1, 5, 7]

NOTE 1: Application parameter influencing functions and capabilities are part of the system requirements.

NOTE 2: For changes to the stakeholder's requirements SUP.10 applies.

SYS.2.BP2: Structure system requirements. Structure the system requirements in the system requirements specification by e.g.

 grouping to project relevant clusters,

 sorting in a logical order for the project,

 categorizing based on relevant criteria for the project,

 prioritizing according to stakeholder needs.

[Outcome 2, 4]

NOTE 3: Prioritizing typically includes the assignment of functional content to planned releases. Refer to SPL.2.BP1.

SYS.2.BP3: Analyze system requirements. Analyze the specified system requirements including their interdependencies to ensure correctness, technical feasibility and verifiability, and to support risk identification. Analyze the impact on cost, schedule and the technical impact. [OUTCOME 1, 2, 7]

NOTE 4: The analysis of impact on cost and schedule supports the adjustment of project estimates. Refer to MAN.3.BP5.

SYS.2.BP4: Analyze the impact on the operating environment. Identify the interfaces between the specified system and other elements of the operating environment. Analyze the impact that the system requirements will have on these interfaces and the operating environment. [OUTCOME 3, 7]

SYS.2.BP5: Develop verification criteria. Develop the verification criteria for each system requirement that define the qualitative and quantitative measures for the verification of a requirement. [OUTCOME 2, 7]

NOTE 5: Verification criteria demonstrate that a requirement can be verified within agreed constraints and is typically used as the input for the development

of the system test cases or other verification measures that ensures compliance with the system requirements.

NOTE 6: Verification which cannot be covered by testing is covered by SUP.2.

SYS.2.BP6: Establish bidirectional traceability. Establish bidirectional traceability between stakeholder requirements and system requirements. [OUTCOME 6]

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

SYS.2.BP7: Ensure consistency. Ensure consistency between stakeholder requirements and system requirements. [OUTCOME 6]

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

SYS.2.BP8: Communicate agreed system requirements. Communicate the agreed system requirements and updates to system requirements to all relevant parties. [OUTCOME 8]

Output work products

13-04 Communication record →

13-19 Review record →

[Outcome 8]

[Outcome 6]

13-21 Change control record →

[Outcome 1]

13-22 Traceability record →

[Outcome 6]

15-01 Analysis report →

[OUTCOME 2, 3, 4, 7]

17-08 Interface requirements specification →

[Outcome 1, 3]

17-12 System requirements specification →

[Outcome 1, 5]

17-50 Verification criteria →

[Outcome 2]

Process ID

SYS.3

Process name

System Architectural Design

Process purpose

The purpose of the System Architectural Design Process is to establish a system architectural design and identify which system requirements are to be allocated to which elements of the system, and to evaluate the system architectural design against defined criteria.

Process outcomes

As a result of successful implementation of this process:

1) a system architectural design is defined that identifies the elements of the system;

2) the system requirements are allocated to the elements of the system;

3) the interfaces of each system element are defined;

4) the dynamic behavior of the system elements is defined;

5) consistency and bidirectional traceability are established between system requirements and system architectural design; and

6) the system architectural design is agreed and communicated to all affected parties.

Base practices

SYS.3.BP1: Develop system architectural design. Develop and document the system architectural design that specifies the elements of the

system with respect to functional and non-functional system requirements.

[Outcome 1]

NOTE 1: The development of system architectural design typically includes the decomposition into elements across appropriate hierarchical levels.

SYS.3.BP2: Allocate system requirements. Allocate the system requirements to the elements of the system architectural design. [OUTCOME 2]

SYS.3.BP3: Define interfaces of system elements. Identify, develop and document the interfaces of each system element. [OUTCOME 3]

SYS.3.BP4: Describe dynamic behavior. Evaluate and document the dynamic behavior of the interaction between system elements. [OUTCOME 4]

NOTE 2: Dynamic behavior is determined by operating modes (e.g. start-up, shutdown, normal mode, calibration, diagnosis, etc.).

SYS.3.BP5: Evaluate alternative system architectures. Define evaluation criteria for the architecture. Evaluate alternative system architectures according to the defined criteria. Record the rationale for the chosen system architecture. [OUTCOME 1]

NOTE 3: Evaluation criteria may include quality characteristics (modularity, maintainability, expandability, scalability, reliability, security realization and usability) and results of make-buy-reuse analysis.

SYS.3.BP6: Establish bidirectional traceability. Establish bidirectional traceability between system requirements and elements of the system architectural design. [OUTCOME 5]

NOTE 4: Bidirectional traceability covers allocation of system requirements to the elements of the system architectural design.

NOTE 5: Bidirectional traceability supports coverage, consistency and impact analysis.

SYS.3.BP7: Ensure consistency. Ensure consistency between system requirements and the system architectural design. [OUTCOME 1, 2, 5, 6]

NOTE 6: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

NOTE 7: System requirements typically include system architectural requirements. Refer to BP5.

SYS.3.BP8: Communicate agreed system architectural design. Communicate the agreed system architectural design and updates to system architectural design to all relevant parties. [OUTCOME 6]

Output work products

04-06 System architectural design → [OUTCOME 1, 2, 3, 4, 5]

13-04 Communication record → [OUTCOME 6]

13-19 Review record → [OUTCOME 5]

13-22 Traceability record → [OUTCOME 5]

17-08 Interface requirements specification → [OUTCOME 3]

Process ID

SYS.4

Process name

System Integration and Integration Test

Process purpose

The purpose of the System Integration and Integration Test Process is to integrate the system items to produce an integrated system consistent with the system architectural design and to ensure that the system items are tested to provide evidence for compliance of the integrated system items with the system architectural design, including the interfaces between system items.

Process outcomes

As a result of successful implementation of this process:

1) a system integration strategy consistent with the project plan, the release plan and the system architectural design is developed to integrate the system items;

2) a system integration test strategy including the regression test strategy is developed to test the system item interactions;

3) a specification for system integration test according to the system integration test strategy is developed that is suitable to provide evidence for compliance of the integrated system items with the system architectural design, including the interfaces between system items;

4) system items are integrated up to a complete integrated system according to the integration strategy;

5) test cases included in the system integration test specification are selected according to the system integration test strategy and the release plan;

6) system item interactions are tested using the selected test cases and the results of system integration testing are recorded;

7) consistency and bidirectional traceability between the elements of the system architectural design and test cases included in the system integration test specification and bidirectional traceability between test cases and test results is established; and

8) results of the system integration test are summarized and communicated to all affected parties.

Base practices

SYS.4.BP1: Develop system integration strategy. Develop a strategy for integrating the system items consistent with the project plan and the release plan. Identify system items based on the system architectural design and define a sequence for integrating them. [OUTCOME 1]

SYS.4.BP2: Develop system integration test strategy including regression test strategy. Develop a strategy for testing the integrated system items following the integration strategy. This includes a regression test strategy for re-testing integrated system items if a system item is changed. [OUTCOME 2]

SYS.4.BP3: Develop specification for system integration test. Develop the test specification for system integration test including the test cases for each integration step of a system item according to the system integration test strategy. The test specification shall be suitable to provide evidence for compliance of the integrated system items with the system architectural design. [OUTCOME 3]

NOTE 1: The interface descriptions between system elements are an input for the system integration test cases.

NOTE 2: Compliance to the architectural design means that the specified integration tests are suitable to prove that the interfaces between the system items fulfill the specification given by the system architectural design.

NOTE 3: The system integration test cases may focus on

 the correct signal flow between system items

 the timeliness and timing dependencies of signal flow between system items

 the correct interpretation of signals by all system items using an interface

 the dynamic interaction between system items

NOTE 4: The system integration test may be supported using simulation of the environment (e.g. Hardware-in-the-Loop simulation, vehicle network simulations, digital mock-up).

SYS.4.BP4: Integrate system items. Integrate the system items to an integrated system according to the system integration strategy. [OUTCOME 4]

NOTE 5: The system integration can be performed step wise integrating system items (e.g. the hardware elements as prototype hardware, peripherals (sensors and actuators), the mechanics and integrated software) to produce a system consistent with the system architectural design.

SYS.4.BP5: Select test cases. Select test cases from the system integration test specification. The selection of test cases shall have sufficient coverage according to the system integration test strategy and the release plan. [OUTCOME 5]

SYS.4.BP6: Perform system integration test. Perform the system integration test using the selected test cases. Record the integration test results and logs. [OUTCOME 6]

NOTE 6: See SUP.9 for handling of non-conformances.

SYS.4.BP7: Establish bidirectional traceability. Establish bidirectional traceability between elements of the system architectural design and test cases included in the system integration test specification.

Establish bidirectional traceability between test cases included in the system integration test specification and system integration test results. [OUTCOME 7]

NOTE 7: Bidirectional traceability supports coverage, consistency and impact analysis.

SYS.4.BP8: Ensure consistency. Ensure consistency between elements of the system architectural design and test cases included in the system integration test specification. [OUTCOME 7]

NOTE 8: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

SYS.4.BP9: Summarize and communicate results. Summarize the system integration test results and communicate them to all affected parties. [OUTCOME 8]

NOTE 9: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

Output work products

08-50 Test specification → [OUTCOME 3, 5]

08-52 Test plan → [OUTCOME 1, 2]

11-06 System → [OUTCOME 4]

13-04 Communication record → [OUTCOME 8]

13-19 Review record → [OUTCOME 7]

13-22 Traceability record → [OUTCOME 7]

13-50 Test result → [OUTCOME 6, 8]

Process ID

SYS.5

Process name

System Qualification Test

Process purpose

The purpose of the System Qualification Test Process is to ensure that the integrated system is tested to provide evidence for compliance with the system requirements and that the system is ready for delivery.

Process outcomes

As a result of successful implementation of this process:

1) a system qualification test strategy including regression test strategy consistent with the project plan and release plan is developed to test the integrated system;

2) a specification for system qualification test of the integrated system according to the system qualification test strategy is developed that is suitable to provide evidence for compliance with the system requirements;

3) test cases included in the system qualification test specification are selected according to the system qualification test strategy and the release plan;

4) the integrated system is tested using the selected test cases and the results of system qualification test are recorded;

5) consistency and bidirectional traceability are established between system requirements and test cases included in the system qualification test specification and between test cases and test results; and

6) results of the system qualification test are summarized and communicated to all affected parties.

Base practices

SYS.5.BP1: Develop system qualification test strategy including regression test strategy. Develop a strategy for system qualification test consistent with the project plan and the release plan. This includes a regression test strategy for re-testing the integrated system if a system item is changed. [OUTCOME 1]

SYS.5.BP2: Develop specification for system qualification test. Develop the specification for system qualification test including test cases based on the verification criteria according to the system qualification test strategy. The test specification shall be suitable to provide evidence for compliance of the integrated system with the system requirements. [OUTCOME 2]

SYS.5.BP3: Select test cases. Select test cases from the system qualification test specification. The selection of test cases shall have sufficient coverage according to the system qualification test strategy and the release plan. [OUTCOME 3]

SYS.5.BP4: Test integrated system. Test the integrated system using the selected test cases. Record the system qualification test results and logs. [OUTCOME 4]

NOTE 1: See SUP.9 for handling of non-conformances.

SYS.5.BP5: Establish bidirectional traceability. Establish bidirectional traceability between system requirements and test cases included in the system qualification test specification. Establish bidirectional traceability between test cases included in the system qualification test specification and system qualification test results. [OUTCOME 5]

NOTE 2: Bidirectional traceability supports coverage, consistency and impact analysis.

SYS.5.BP6: Ensure consistency. Ensure consistency between system requirements and test cases included in the system qualification test specification. [OUTCOME 5]

NOTE 3: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

SYS.5.BP7: Summarize and communicate results. Summarize the system qualification test results and communicate them to all affected parties. [OUTCOME 6]

NOTE 4: Providing all necessary information from the test case execution in a summary enables other parties to judge the consequences.

Output work products

08-50 Test specification

08-52 Test plan

→

→

[Outcome 2, 3]

[Outcome 1]

13-04 Communication record

→

[Outcome 6]

13-19 Review record

→

[Outcome 5]

13-22 Traceability record

→

[Outcome 5]

13-50 Test result

→

[Outcome 4, 6]