Tool Verification Report Template#
Note
Tool Verification Report header
[Your Tool Name]
|
status: draft
|
||||
Attention
The above directive must be updated according to your tool.
The information is used for proper tool identification
Status may (draft, evaluated, qualified, released, rejected)
Safety/Security affected may (YES, NO)
TCL may (LOW, HIGH)
Version may v.MAJOR.MINOR.PATCH
Note
An example of a Tool Verification Report can be found here: Example Tool Verification Report
[Your Tool Name] Verification Report#
Introduction#
Scope and purpose#
[Describe the scope and purpose of the tool]
Tip
May add general use cases, scenarios, etc.
Inputs and outputs#
[Describe here the inputs and outputs of the tool]
Tip
May add a figure, if appropriate
Note
Available information#
[Describe here the available information for the tool]
Tip
May also add some general information about the tool
May add links to the public available information, if applicable, e.g. tools documentation, tracking of tool bugs, user manual, guidelines, etc.
May add some comments to get started or usage information or integration manual
May add tool usage constraints/limitations
Installation and integration#
Installation#
[Describe here how to install the tool]
Tip
May add where is the tool located
May add how the tool is configured in order to be used in safe/secure way
May add access/usage protection required, execution authority required
Integration#
[Describe here how to integrate the tool in existing toolchain]
Tip
May add how the tool works together with other tools
Environment#
[Describe environment and its constraints/limitations]
Safety evaluation#
[Describe here detailed information about the tool safety evaluation]
Tip
Determine the use case for the tool in the project and for each use case
Determine the malfunctions
Determine the tool impact based on the malfunctions
Determine the available safety measures
Determine if the impact detection based on safety measures are sufficient and add additional ones, if required
Determine the tool confidence based on tool impact and tool impact detection
Use the table below to document all uses cases and their evaluation, the example table provided below
The final confidence shall be judged on the maximum confidence level of each use case
Malfunction identification |
Use case description |
Malfunctions |
Impact on safety? |
Impact safety measures available? |
Impact safety detection sufficient? |
Further additional safety measure required? |
Confidence (automatic calculation) |
|---|---|---|---|---|---|---|---|
1 |
Use case description example |
Malfunction X (with safety impact and available measures)
Detailed description of malfunction X shall be added here, if applicable.
|
yes |
Reviews |
yes |
no |
high |
2 |
Use case description example |
Malfunction Y (with safety impact and no available measures)
Detailed description of malfunction Y shall be added here, if applicable.
|
yes |
no |
no |
yes (qualification) |
low |
3 |
Use case description example |
Malfunction Z (without safety impact)
Detailed description of malfunction Z shall be added here, if applicable.
|
no |
no |
yes |
no |
high |
Security evaluation#
[Describe here detailed information about the tool security evaluation]
Tip
Determine the use case for the tool in the project and for each use case
Determine the threats
Determine the tool impact based on the threats
Determine the available security measures
Determine if the impact detection based on security measures are sufficient and add additional ones, if required
Use the table below to document all uses cases and their security evaluation, the example table provided below
The final confidence shall be judged on the maximum confidence level of each use case
Threat identification |
Use case description |
Threats |
Impact on security? |
Impact security measures available? |
Impact security detection sufficient? |
Further additional security measure required? |
|---|---|---|---|---|---|---|
1 |
Use case description example |
Threat A (with security impact and available measures)
Detailed description of threat A shall be added here, if applicable.
|
yes |
(Example) Usage of SSH/GPG keys to access to the source code repository |
yes |
no |
2 |
Use case description example |
Threat B (with security impact and no available measures)
Detailed description of threat B shall be added here, if applicable.
|
yes |
no |
no |
yes (qualification) |
3 |
Use case description example |
Threat C (without security impact)
Detailed description of threat C shall be added here, if applicable.
|
no |
no |
yes |
no |
Result#
Tip
Add here final statement, if tool qualification is required or not.
[Your tool name] requires qualification for use in safety-related software development according to ISO 26262.
or
[Your tool name] does not require qualification for use in safety-related software development according to ISO 26262.
Optional Section for Tool Qualification#
Based on method: validation of the software tool
Requirements and testing aspects#
[Describe here requirements and their tests from user point of view]
Tip
Where are tool requirements defined
Where are the test cases for the requirements defined
Where are the requirements coverage documented
Analysis perspective#
[Describe analysis perspective]
Tip
Optional:
Where is the architectural design of the tool defined
Where is the safety analysis for the tool defined
Where is the security analysis for the tool defined