Page History
...
So, you can reflect the ISO 26262 and ASPICE model for documenting the system (both hardware and software) requirements in a way that clearly reflects the scope, dependencies, status, etc. For this example, let’s assume we are working with an Automated Driving System, here is how a few requirements for it could be arranged:
The hierarchical view is achieved with the Structure add-on for Jira
...
| Info |
|---|
ASIL = Impact x (Probability x Controllability). Although the definition of risk in ISO 31000 is slightly different, these 3 key concepts are still largely applicable for that standard as well. |
We could then classify the requirement entities by ASIL directly, or just impact, or any other user-defined field.
...
We have already set up the ASIL and related values to match ISO 26262 at the requirement/story level. We can choose to maintain the same level of detail at the test level or do a more customized risk assessment - e.g., combining ASIL with complexity for an aggregate Risk Score metric:
You can not only add tests to the execution based on risk values in filters, but also prioritize the execution order accordingly.
...
Epic and Story issues, common in Agile environments, can be covered by creating tests and tracking coverage directly from Jira. From the user story issue screen you can immediately create a Test. It is also easy to go back to the user story, using the issue link that was created automatically between the Test and the user story.
Within the Test Coverage Report, you can have a birds-eye view of quality status of your requirements, based on the tests that cover them and their results. To ease your analysis, you can group stories by specific metrics; for example, by risk level. That way you can have a better understanding of whether a higher priority issue is ready to be released or not.
...