I have some questions regarding traceability according to ISO26262/ASPICE: In Harmony aMBSE, during use case analysis, there are two steps where we add trace links.
At first we stucture requirements, when we add trace links from requirements to use cases. Next it comes to modelling and we finally create state machines. There we add trace links to states, transitions, etc.
Please can you summarize the important issues in both steps? I cannot remember seeing an example (Deskbook, book) for a traced state machine.
Thank you very much!
Thanks Bruce! I agree with the direction of trace relation.
I think there are two different actions to distinguish. First the trace relations within Requirements Analysis in order to bring consistency from requirements to models. Second, the allocation step within Architectural Design in order to allocate requirements to architectural design elements. This is the main goal from ISO/ASPICE.
A few comments.
First, to be a bit pedantic, the trace relations go from the use case or state machine element TO the requirement, not the other way around. It's a question of ownership of the relation. There are people who direct them the other way, but those people are *wrong*. :-)
The best fidelity of tracing depends on many factors. In most cases, people find it adequate to trace from the use case to the relevant requirements. In safety-critical or high-reliability situations, it may be preferable to trace to the use case contents (e.g. scenarios and state machine elements). In those cases, each action and transition should trace to one or more requirements. While this can be done on the diagram, it need not be; it can be done directly in the model browser and can be shown on a matrix. Or it can be shown on the diagram, and their display can be suppressed or enabled using the view filter feature of Rhapsody.
There may be elements on the state machine that are there only for convenience or to support simulation; in these cases, such elements should be marked as "non-normative", meaning that they are not there to represent requirements. The Harmony SE toolkit has a <<nonNormatve>> stereotype for this purpose. The point here is that is is ok to have state machine elements there for non-requirements related reasons but there should be marked as such. (This comes from the DO-331 standard "Model-Based Development and Verification Supplement to DO-178C and DO-278A".)
If the desired fidelity of the trace relation is to state machine elements, then every action and transition ) should either trace to at least one requirement or be tagged as "non-normative." . States themselves may or may not trace to requirements as most functional requirements really need to trace to transitions or actions. Sometimes, the requirements explicitly speak of "modes" or states; in these cases, the states will trace to the relevant requirements.
I hope this helps.