personAuthor: Process Fellows
Test Management ensures that testing activities are strategically planned, monitored, and evaluated across all development phases. From unit tests to system-level integration, this cross-cutting discipline defines methods, tools, documents, and roles to ensure traceable and efficient verification and validation.
school
PF_Testmanagement_Extract.pdf Short Overview of Test Management (related to all Automotive SPICE® verification processes)
arrow_forward "Verification level vs. Verification timepoint"
personAuthor: Process Fellows
The execution of a verification measure is not necessarily linked to the verification time point.
It is possible that a verification measure from SWE.6 is carried out as part of the verification of the SW component and integration verrifcation if the setup or the environment is better suited to this.
However, it remains a verification of the SW requirements.
The decisive factor is what a verification measure is derived from.
However, it is important to ensure that this verification measure is included in and part of the report and in the summary of the SW verification.
Pay attention to the sequences and dependencies to be followed.
# PROCESS PURPOSE
The purpose is to verify that the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) are consistent with the software architectural design, and to integrate the (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) and verify that the integrated (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) are consistent with the software architecture and the software detailed design.
# PROCESS OUTCOMES
O1 (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) are specified for the software integration verification of the integrated (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) based on the software architecture and the detailed design, including the interfaces of, and interactions between, the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.).
O2 (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) are specified to provide evidence for compliance of the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) with the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.)’ behavior and interfaces.
O3
The (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) are integrated up to a complete integrated software.
O4 (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) are selected according to the (Release = A product delivered to a customer, including a defined set of functionalities and properties.) scope considering criteria, including criteria for (Regression verification = Selective re-verification of elements to verify that modifications have not caused unintended effects.).
O5
The (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) are verified using the selected (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and the results of the integration verification are recorded.
O6
The integrated (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) are verified using the selected (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and the results of the integration verification are recorded.
O7
Consistency and bidirectional traceability are established between the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) and the software architecture as well as the detailed design.
O8
Bidirectional traceability is established between the verification results and the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.).
O9
The results of the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) verification and (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) integration verification are summarized and communicated to all affected parties.
Specify (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), based on a defined sequence and preconditions for the integration of (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT), against the defined static and dynamic aspects of the software architecture, including
techniques for the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.),
pass/fail criteria for (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.),
entry and exit criteria for (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.),
necessary sequence of the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and
the required verification infrastructure and environment setup.
Note 1: Examples on which the software integration (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) may focus on are the correct dataflow and dynamic interaction between (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) together with their timing dependencies, the correct interpretation of data by all (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) using an interface, and the compliance to resource consumption objectives. Note 2: The software integration (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) may be supported by using (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) debug interfaces or simulation environments (e.g., Software-in-the-Loop-Simulation).
BP2
Specify verification measures for verifying the software component behavior. (
O2 )
Specify (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) verification against the defined (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.)’ behavior and their interfaces in the software architecture, including
techniques for the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.),
entry and exit criteria for (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.),
pass/fail criteria for (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.), and
the required verification infrastructure and environment setup.
Note 3: (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) are related to (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) but not to the (Software unit = Software unit in design and implementation-oriented processes: As a result of the decomposition of a software component in a conceptual model, the software is decomposed into software units. A software unit is decided not to be further subdivided. Software unit in verification-oriented processes: An implemented SW unit under verification is represented, e.g., as source code files, or an object file.) since the (Software unit = Software unit in design and implementation-oriented processes: As a result of the decomposition of a software component in a conceptual model, the software is decomposed into software units. A software unit is decided not to be further subdivided. Software unit in verification-oriented processes: An implemented SW unit under verification is represented, e.g., as source code files, or an object file.) verification is addressed in the process SWE.4 (Software unit = Software unit in design and implementation-oriented processes: As a result of the decomposition of a software component in a conceptual model, the software is decomposed into software units. A software unit is decided not to be further subdivided. Software unit in verification-oriented processes: An implemented SW unit under verification is represented, e.g., as source code files, or an object file.) Verification.
BP3
Select verification measures. (
O4 )
Document the selection of integration (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for each integration step considering selection criteria including criteria for the (Regression verification = Selective re-verification of elements to verify that modifications have not caused unintended effects.). The documented selection of (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) shall have sufficient coverage according to the (Release = A product delivered to a customer, including a defined set of functionalities and properties.) scope. Note 4: Examples for selection criteria can be the need for continuous integration / continuous development (Regression verification = Selective re-verification of elements to verify that modifications have not caused unintended effects.) (due to, e.g., changes to the software architectural or detailed design), or the intended use of the delivered product (Release = A product delivered to a customer, including a defined set of functionalities and properties.) (e.g., test bench, test track, public road etc.).
BP4
Integrate the software elements and perform the integration verification. (
O3, O6 )
Integrate the (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) until the software is fully integrated according to the specified interfaces and interactions between the (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT), and according to the defined sequence and the defined preconditions. Perform the selected integration (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.). Record the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) data including pass/fail status and the corresponding (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) data. Note 5: Examples for preconditions for starting the software integration are qualification of pre- existing (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.), off-the-shelf (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.), open-source-software, or auto- code generated software. Note 6: Defined preconditions may allow, e.g., big-bang-integration of all (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.), continuous integration, as well as stepwise integration (e.g., across (Software unit = Software unit in design and implementation-oriented processes: As a result of the decomposition of a software component in a conceptual model, the software is decomposed into software units. A software unit is decided not to be further subdivided. Software unit in verification-oriented processes: An implemented SW unit under verification is represented, e.g., as source code files, or an object file.) and/or (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) up to the fully integrated software) with accompanying (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.). Note 7: See SUP.9 for handling the verification results which deviate from expected results.
Linked Knowledge Nuggets: arrow_forward "Archiving test results"
personAuthor: Process Fellows
Don’t lose your evidence. With perspective to testing, SUP.8.BP1 in combination with SUP.8.BP8 expects structured storage of test logs, verdicts, anomalies, and configuration info. This is not only a formality: It enables you to later on reproduce details about a certain system version.
BP5
Perform the software component verification. (
O5 )
Perform the selected (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) for verifying the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) behavior. Record the verification results including pass/fail status and the corresponding (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) data. Note 8: See SUP.9 for handling the verification results which deviate from expected results.
Linked Knowledge Nuggets: arrow_forward "Archiving test results"
personAuthor: Process Fellows
Don’t lose your evidence. With perspective to testing, SUP.8.BP1 in combination with SUP.8.BP8 expects structured storage of test logs, verdicts, anomalies, and configuration info. This is not only a formality: It enables you to later on reproduce details about a certain system version.
Ensure consistency and establish bidirectional traceability between the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) and the static and dynamic aspects of the software architecture as well as the detailed design. Establish bidirectional traceability between the verification results and the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.). Note 9: Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent.
Linked Knowledge Nuggets: arrow_forward "Consistency vs. Traceability – What’s the Difference?"
personAuthor: Process Fellows
Consistency ensures that related content doesn’t contradict itself – e.g., requirements align with architecture and test. Traceability, in contrast, is about links: can you follow a requirement through to implementation and verification? Both are needed – consistency builds trust, traceability enables control. Typically, traceability strongly supports consistency review.
arrow_forward "The role of traceability in risk control"
personAuthor: Process Fellows
Traceability isn’t just about completeness — it’s about managing impact. When a requirement changes, trace links tell you what’s affected. That’s your early-warning system.
arrow_forward "The true benefit of traceability
"
personAuthor: Process Fellows
Sometimes the creation of traceability is seen as an additional expense, the benefits are not recognized.
Traceability should be set up at the same time as the derived elements are created. Both work products are open in front of us and the creation of the trace often only takes a few moments.
In the aftermath, the effort increases noticeably and the risk of gaps is high.
If the traceability is complete and consistent, the discovery of dependencies is unbeatably fast and reliable compared to searching for dependencies at a later stage, when there may also be time pressure.
It also enables proof of complete coverage of the derived elements and allows the complete consistency check.
BP7
Summarize and communicate the results. (
O9 )
Summarize the (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) verification and the software integration verification results and communicate them to all affected parties. Note 10: Providing all necessary information from the execution of the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) in a summary enables other parties to judge the consequences.
# OUTPUT INFORMATION ITEMS
13-52
Communication evidence (
O9 )
Evidence of interpersonal communication.Identifies:
Scope of information
Need for feedback, for example an expected confirmation within one week
Meta data, for example time when communication was done or how information was distributed.
Includes:
Personal information
Work-flows, for example within tools
Examples and References:
E-mails and other forms of memos
Verbal statements
Meeting minutes, for example in standups
Electronic media, for example webcasts, blog posts intranet forum
Chat protocols
Wiki pages
Photo protocol
Used by these processes:
ACQ.4 Supplier Monitoring
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
PIM.3 Process Improvement
REU.2 Reuse of Products
SUP.1 Quality Assurance
SUP.11 Machine Learning Data Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.1 Requirements Elicitation
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
Used by these process attributes:
PA2.1 Process performance management process attribute
13-51
Consistency evidence (
O7, O8 )
Evidence of information to be semantically coherent alongrelevant artifacts, ensuring completeness, purpose maturity of processes, (Task = A definition, but not the execution, of a coherent set of atomic actions.) and products throughout their lifecycle.Identifies:
Traceability information, for example hyperlinks, repository location or editorial references.
Naming conventions
Relevant artifacts
Revision and revision history information
Change documentation and analysis information
Includes:
Meta-information, for example database identifiers notes in Git commits comments
Examples and References:
Evidence of Definition of Done (DoD) adherence.
Used by these processes:
HWE.1 Hardware Requirements Analysis
HWE.2 Hardware Design
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
MAN.3 Project Management
MLE.1 Machine Learning Requirements Analysis
MLE.2 Machine Learning Architecture
MLE.3 Machine Learning Training
MLE.4 Machine Learning Model Testing
SUP.8 Configuration Management
SUP.10 Change Request Management
SWE.1 Software Requirements Analysis
SWE.2 Software Architectural Design
SWE.3 Software Detailed Design and Unit Construction
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.2 System Requirements Analysis
SYS.3 System Architectural Design
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
VAL.1 Validation
01-50
Integrated Software (
O3 )
A functional executable software which has been integrated from multiple (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.).Identifies:
All configured (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT)
Includes:
(Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.)
Examples and references:
Simulator with stubbing
Object code
Used by these processes:
SWE.5 Software Component Verification and Integration Verification
06-50
Integration Sequence Instruction (
O3 )
Workflow definition to combine, assemble or connect different (System = A collection of interacting components organized to accomplish a specific function or set of functions within a specific environment.) or components into an integrated configuration.Identifies:
Physical elements, for example (Hardware = Assembled and interconnected electrical or electronic hardware components or parts which perform analog or digital functions or operations.) mechanical and wiring elements.
Software
(Application parameter = An application parameter is a software variable containing data that can be changed at the system or software levels; they influence the system’s or software behavior and properties. The notion of application parameter is expressed in two ways:
The specification (including variable names, the domain value range, technical data types, default values, physical unit (if applicable), the corresponding memory maps, respectively).
The actual quantitative data value it receives by means of data application.
Application parameters are not requirements. They are a technical implementation solution for configurability-oriented requirements.)
Sequences and order of integration
Preconditions
Includes:
Safety instructions
Recovery or fallback procedures
Verification activities
Used by these processes:
SWE.5 Software Component Verification and Integration Verification
SYS.4 System Integration and Integration Verification
01-03
Software Component (
O3 )
See definition of (Software component = Software component in design and implementation-oriented processes: The software architecture decomposes the software into software components across appropriate hierarchical levels down to the lowest-level software components in a conceptual model. Software component in verification-oriented processes: The implementation of a SW component under verification is represented, e.g., as source code, object files, library file, executable, or executable model.) in glossary.Identifies:
The (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT) in the software architecture above the (Software unit = Software unit in design and implementation-oriented processes: As a result of the decomposition of a software component in a conceptual model, the software is decomposed into software units. A software unit is decided not to be further subdivided. Software unit in verification-oriented processes: An implemented SW unit under verification is represented, e.g., as source code files, or an object file.) level, or an implementation of such a (Software element = A software element is subject to integration within the software. Can represent a →SOFTWARE COMPONENT or →SOFTWARE UNIT).
Includes:
Design model element, or executable source code such as libraries, modules, services or scripts.
Used by these processes:
SWE.5 Software Component Verification and Integration Verification
08-60
Verification Measure (
O1, O2 )
Tool or method used to ensure the accuracy and reliability of a (Measurement = The activity to find the size, quantity or degree of something.) or test under specified conditions to verify specified functionality.Identifies:
Description of test scope, for example fault injection safety case
Classifications, for example black-box or grey-box test
(Measurement = The activity to find the size, quantity or degree of something.) to be performed during the test, for example an optical inspection
Test steps description
Pass/fail criteria, for example from end user survey
Includes:
Simulation scenarios
Emulation
Entry criteria
Equivalence classes and boundary values
Calculations and mathematical functions
Techniques and resources, for example review verification
Verification environment setup and configuration
Sequences
Used by these processes:
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
03-50
Verification Measure Data (
O5 )
Data recorded during the execution of a (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.).Identifies:
Logging data, for example raw data or tool generated output
Values of (Measurement = The activity to find the size, quantity or degree of something.) and calculations
Protocols of simulations
Review data
Includes:
Finding records
Used by these processes:
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
08-58
Verification Measure Selection Set (
O4 )
A set of (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.) selected for a specific purpose.Identifies:
(Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.)
Scope of their application, for example a product variant, regression or a subcomponent
Includes:
Identification of the (Verification measure = Verification measure can be:
Test cases
Measurements
Calculations
Simulations
Reviews
Analyses
Note, that in particular domains certain verification measures may not be applicable, e.g., software units generally cannot be verified by means of calculations or analyses.)
Criteria for re-verification, for example in the case of changes
Dependencies
Used by these processes:
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.4 System Integration and Integration Verification
SYS.5 System Verification
15-52
Verification Results (
O5, O6 )
Results of verification activities.Identifies:
Identification information
Log data
Passed and failed results
Not executed/blocked verification activities
Test execution details, for example tester name, role.
Timing information
Includes:
Summary of verification results
References, for example to problem resolution actions.
Used by these processes:
HWE.3 Verification against Hardware Design
HWE.4 Verification against Hardware Requirements
SWE.4 Software Unit Verification
SWE.5 Software Component Verification and Integration Verification
SWE.6 Software Verification
SYS.4 System Integration and Integration Verification
SWE.5
Software Component Verification and Integration Verification
