Process ID

SYS.1

Process name

Requirements Elicitation

Process purpose

The purpose is to gather, analyze, and track evolving stakeholder needs and requirements throughout the lifecycle of the product and/or service to establish a set of agreed requirements.

Process outcomes

1) Continuing communication with the stakeholder is established.

2) Stakeholder expectations are understood and requirements are defined and agreed.

3) Stakeholder requirements changes arising from stakeholder needs are analyzed to enable associated risk assessment and impact management.

4) Determination of stakeholder requirements status is ensured for all affected parties.

Base practices

SYS.1.BP1: Obtain stakeholder expectations and requests. Obtain and define stakeholder expectations and requests through direct solicitation of stakeholder input, and through review of stakeholder business proposals (where relevant) and other documents containing inputs to stakeholder requirements, and consideration of the target operating and hardware environment.

Note 1: Documenting the stakeholder, or the source of a stakeholder requirement, supports stakeholder requirements agreement and change analysis (see BP3 and BP4).

SYS.1.BP2: Understand stakeholder expectations. Ensure that all affected parties understand each requirement in the same way.

Note 2: Examples of affected parties are customers, suppliers, design partners, joint venture partners, or outsourcing parties.

SYS.1.BP3: Agree on requirements. Formalize the stakeholder’s expectations and requests into requirements and obtain an explicit agreement from all affected parties to work on these requirements.

Note 3: The agreed stakeholder requirements may be based on feasibility studies and/or cost and schedule impact analysis.

SYS.1.BP4: Analyze stakeholder requirements changes. Analyze and manage all changes made to the stakeholder requirements against the agreed stakeholder requirements. Assess the impact and risks and initiate appropriate change control and mitigation actions.

Note 4: Requirements changes may arise from different sources as for instance changing technology, stakeholder needs, or legal constraints.

Note 5: Refer to SUP.10 Change Request Management, if required.

SYS.1.BP5: Communicate requirements status. Ensure all affected parties can be aware of the status and disposition of their requirements including changes and can communicate necessary information and data.

SYS.1 Requirements Elicitation

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Output Information Items

15-51 Analysis Results

X

13-52 Communication Evidence

X

X

17-00 Requirement

X

17-54 Requirement Attribute

X

X

X

Base Practices

BP1: Obtain stakeholder expectations and requests

X

BP2: Understand stakeholder expectations

X

BP3: Agree on requirements

X

BP4: Analyze stakeholder requirements changes

X

BP5: Communicate requirements status

X

X

Process ID

SYS.2

Process name

System Requirements Analysis

Process purpose

The purpose is to establish a structured and analyzed set of system requirements consistent with the stakeholder requirements.

Process outcomes

1) System requirements are specified

2) System requirements are structured and prioritized

3) System requirements are analyzed for correctness and technical feasibility

4) The impact of system requirements on the operating environment is analyzed

Base practices

SYS.2.BP1: Specify system requirements. Use the stakeholder requirements to identify and document the functional and non-functional requirements for the system according to

defined characteristics for requirements.

Note 1: Characteristics of requirements are defined in standards such as ISO IEEE 29148, ISO 26262- 8:2018, or the INCOSE Guide For Writing Requirements.

Note 2: Examples for defined characteristics of requirements shared by technical standards are verifiability (i.e. verification criteria being inherent in the requirements formulation), unambiguity/comprehensibility, freedom from design and implementation, and not contradicting any other requirement.

SYS.2.BP2: Structure system requirements. Structure and prioritize the system requirements.

Note 3: Examples for structuring criteria can be grouping (e.g. by functionality) or product variants identification.

Note 4: Prioritization can be done according to project or stakeholder needs via e.g. definition of release scopes. 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 to support project management regarding project estimates.

Note 5: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.

Note 6: Technical feasibility can be evaluated based on e.g. platform or product line, or by means of prototype development or product demonstrators.

SYS.2.BP4: Analyze the impact on the system context. Analyze the impact that the system requirements will have on elements in the relevant system context.

SYS.2.BP5: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between system requirements and stakeholder requirements.

Note 7: Bidirectional traceability supports consistency, facilitates impact analyses of change requests, and supports the demonstration of coverage of stakeholder requirements.

SYS.2.BP6: Communicate agreed system requirements and impact on the system context. Communicate the agreed system requirements, and results of the impact analysis on the system context, to all affected parties.

SYS.2 System Requirements Analysis

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Output Information Items

17-00 Requirement

X

X

17-54 Requirement Attribute

X

X

15-51 Analysis Results

X

X

13-51 Consistency Evidence

X

13-52 Communication Evidence

X

Base Practices

BP1: Specify system requirements

X

BP2: Structure system requirements

X

BP3: Analyze system requirements

X

BP4: Analyze the impact on the system context

X

BP5: Ensure consistency and establish bidirectional traceability

X

BP6: Communicate agreed system requirements and impact on the system context

X

Process ID

SYS.3

Process name

System Architectural Design

Process purpose

The purpose is to establish an analyzed system architecture consistent with the system requirements.

Process outcomes

1) A system architecture is designed including a definition of the system elements with their behavior, their interfaces, their relationships, and their interactions.

2) The system architecture is analyzed against defined criteria, and special characteristics are identified.

3) Consistency and bidirectional traceability are established between system architecture and system requirements.

4) The agreed system architecture and the special characteristics are communicated to all affected parties.

Base practices

SYS.3.BP1: Specify static aspects of the system architecture. Specify and document the static aspects of the system architecture with respect to the functional and nonfunctional system requirements, including external interfaces and a defined set of system elements with their interfaces and relationships.

SYS.3.BP2: Specify dynamic aspects of the system architecture. Specify and document the dynamic aspects of the system architecture with respect to the functional and nonfunctional system requirements including the behavior of the system elements and their interaction in different system modes.

Note 1: Examples of interactions of system elements are timing diagrams reflecting inertia of mechanical components, processing times of ECUs, and signal propagation times of bus systems.

SYS.3.BP3: Analyze system architecture. Analyze the system architecture regarding relevant technical design aspects related to the product lifecycle, and to support project management regarding project estimates, and derive Special Characteristics for hardware elements.

Document a rationale for the system architectural design decision.

Note 2: See MAN.3.BP3 for project feasibility and MAN.3.BP5 for project estimates.

Note 3: Examples for product lifecycle phases are production, maintenance & repair, decommissioning.

Note 4: Examples for technical aspects are manufacturability for production, suitability of pre-existing system elements to be reused, or availability of system elements.

Note 5: Examples for methods being suitable for analyzing technical aspects are prototypes, simulations, and qualitative analyses (e.g. FMEA approaches)

Note 6: Examples of design rationales are proven-in-use, reuse of a product platform or product line), a make-or-buy decision, or found in an evolutionary way (e.g. set-based design).

SYS.3.BP4: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between the elements of the system architecture and the system requirements that represent properties or characteristics of the physical end product.

Note 7: Bidirectional traceability further supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

Note 8: There may be non-functional system requirements that the system architectural design does not trace to. Examples are development process requirements. Such requirements are still subject to verification.

SYS.3.BP5: Communicate agreed system architecture. Communicate the agreed system architecture, including the special characteristics, to all affected parties.

SYS.3 System Architectural Design

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Output Information Items

04-06 System Architecture

X

13-51 Consistency Evidence

X

13-52 Communication Evidence

X

15-51 Analysis Results

X

17-57 Special Characteristics

X

Base Practices

BP1: Specify static aspects of system architecture

X

BP2: Specify dynamic aspects of system architecture

X

BP3: Analyze the system architecture

X

BP4: Ensure consistency and establish bidirectional traceability

X

BP5: Communicate agreed system architecture

X

Process ID

SYS.4

Process name

System Integration and Integration Verification

Process purpose

The purpose is to integrate systems elements and verify that the integrated system elements are consistent with the system architecture.

Process outcomes

1) Verification measures are specified for system integration verification of the integrated system elements based on the system architecture, including the interfaces of, and interactions between, system elements.

2) System elements are integrated up to a complete integrated system consistent with the release scope.

3) Verification measures are selected according to the release scope considering criteria for regression verification.

4) Integrated system elements are verified using the selected verification measures, and the results of the system integration verification are recorded.

5) Consistency and bidirectional traceability are established between verification measures and the elements of the system architecture.

6) Bidirectional traceability between verification results and verification measures is established.

7) Results of the system integration and integration verification are summarized and communicated to all affected parties.

Base practices

SYS.4.BP1: Specify verification measures for system integration. Specify the verification measures, based on a defined order and preconditions for the integration of system elements against the system static and dynamic aspects of the system architecture, including

 techniques for the verification measures;

 pass/fail criteria for verification measures;

 a definition of entry and exit criteria for the verification measures;

 the required verification infrastructure and environment setup.

Note 1: Examples on what a verification measure may focus are the timeliness and timing dependencies of the correct signal flow between interfacing system elements, or interactions between hardware and software.

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

SYS.4.BP2: Select verification measures. Document the selection of verification measures for each integration step considering selection criteria including criteria for regression verification. The documented selection of verification measures shall have sufficient coverage according to the release scope.

Note 2: Examples for selection criteria can be prioritization of requirements, the need for regression verification (due to e.g. changes to the system architectural design or to system components), or the intended use of the delivered product release (e.g. test bench, test track, public road etc.)

SYS.4.BP3: Integrate system elements and perform integration verification. Integrate the system elements until the system is fully integrated according to the specified interfaces and interactions between the system elements, and according to the defined order and defined preconditions. Perform the selected system integration verification measures. Record the verification measure data including pass/fail status and corresponding verification measure data.

Note 3: Examples for preconditions for starting system integration can be successful system element verification or qualification of pre-existing system elements.

Note 4: See SUP.9 for handling verification results that deviate from expected results

SYS.4.BP4: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between verification measures and the system architecture. Establish bidirectional traceability between verification results and verification measures.

Note 5: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage.

SYS.4.BP5: Summarize and communicate results. Summarize the system integration and integration verification results and communicate them to all affected parties.

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

SYS.4 System Integration and Integration Verification

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Outcome 7

Output Information Items

08-60 Verification Measure

X

06-50 Integration Sequence Instruction

X

08-58 Verification Measure Selection Set

X

15-52 Verification Results

X

13-51 Consistency Evidence

X

X

13-52 Communication Evidence

X

11-06 Integrated System

X

Base Practices

BP1: Specify verification measures for system integration

X

BP2: Select verification measures

X

BP3: Integrate system elements and perform integration verification.

X

X

BP4: Ensure consistency and establish bidirectional traceability

X

X

BP5: Summarize and communicate results

X

Process ID

SYS.5

Process name

System Verification

Process purpose

The purpose is to ensure that the system is verified to be consistent with the system requirements.

Process outcomes

1) Verification measures are specified for system verification of the system based on the system requirements.

2) Verification measures are selected according to the release scope considering criteria for regression verification.

3) The integrated system is verified using the selected verification measures and the results of system verification are recorded.

4) Consistency and bidirectional traceability are established between verification measures and system requirements.

5) Bidirectional traceability is established between verification results and verification measures.

6) Verification results are summarized and communicated to all affected parties.

Base practices

SYS.5.BP1: Specify verification measures for system verification. Specify the verification measures for system verification suitable to provide evidence for compliance with the functional and non-functional information in the system requirements, including

 techniques for the verification measures;

 pass/fail criteria for verification measures;

 a definition of entry and exit criteria for the verification measures;

 necessary sequence of verification measures;

 the required verification infrastructure and environment setup.

Note 1: The system verification measures may cover aspects such as thermal, environmental, robustness/lifetime, and EMC.

SYS.5.BP2: Select verification measures. Document the selection of verification measures considering selection criteria including criteria for regression verification. The selection of verification measures shall have sufficient coverage according to the release scope.

Note 2: Examples for criteria for selection can be prioritization of requirements, the need for regression verification (due to e.g. changes to the system requirements), the intended use of the delivered product release (test bench, test track, public road etc.)

SYS.5.BP3: Perform verification of the integrated system. Perform the verification of the integrated system using the selected verification measures. Record the verification results including pass/fail status and corresponding verification measure data.

Note 3: See SUP.9 for handling verification results that deviate from expected results

SYS.5.BP4: Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between verification measures and system requirements. Establish bidirectional traceability between verification results and verification measures.

Note 4: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage

SYS.5.BP5: Summarize and communicate results. Summarize the system verification results and communicate them to all affected parties.

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

SYS.5 System Verification

Outcome 1

Outcome 2

Outcome 3

Outcome 4

Outcome 5

Outcome 6

Output Information item

08-60 Verification Measure

X

08-58 Verification Measure Selection Set

X

15-52 Verification Results

X

13-51 Consistency Evidence

X

X

13-52 Communication Evidence

X

Base Practices

BP1: Specify verification measures for system verification

X

BP2: Select verification measures

X

BP3: Perform verification of the integrated system

X

BP4: Ensure consistency and establish bidirectional traceability.

X

X

BP5: Summarize and communicate results

X