In DOORS Next, should we be linking base artifacts or module artifacts? It is a question worthy of consideration for many reasons.
The key principle that this approach addresses is to make it simple for the majority of the end users.
Should links be:
- Base to base
- Base to module
- Module to base
- Module to module
It is easy to link module artifact to module artifact: open both modules and drag an artifact from one into the traceability column for the other.
It is relatively simple to link from module artifact to base artifact: from the module artifact add links and in the dialog select an artifact from a folder rather than from a module.
Going from a base artifact is a little more complicated from a user perspective: from the explorer, find the artifact (without opening a module that it is in) and create the link from there. This can be drag and drop to either a module or to another folder, giving us base to module and base to base options.
There are of course other ways to create links, such as with the link by attribute functionality.
One thing that should be a firm starting point is to set a method and stick to it. Once we start mixing the different link destinations (module or base), we potentially run into problems with inconsistency and reportability.
As with all rules, this one was just needing a reason to be broken.
In this instance we have a standardised set of Risks and Requirements which are applicable to one or more systems. All of the Risks and Requirements are captured here, but not all are applicable to every system. The links are base-to-base.
The core team make a copy of the Risk and Requirements modules which the system teams then prune, removing any unnecessary Risks and Requirements. As all the links here are base-to-base, they show up in every module.
Any additions or deletions in the top level modules will not automatically propagate to the System level. If an additional requirement is added, linked to a risk, it will need to be added to all System level modules as well by the core team.
The system team folders now each contain four modules: Risks, Requirements, Controls, and Evidence. Any comments made on any Risks or Requirements here will only be visible in the team area, not on other team areas, or at the top level.
The Controls and Evidence modules are populated by the system teams, and use module-to-module linking. Links from Controls to Requirements and from Evidence to Controls are module artifact to module artifact, this is simple to create with a drag and drop operation.
Some advantages to this are:
- Analysis from the team Requirements module will show only the relevant team links to the Requirements.
- All of the relevant data for each system team is in one place, making it simple to use, and helping with managing team access.
- End users have a simple experience.
There are negatives as well:
- The Graphical Links Explorer will not show all links in an end-to-end picture.
- The core team have the added complexity of making base to base links, copying modules, and ensuring additions and deletions are propagated to all teams.
- The core team will need to carry out regular checks to ensure that links are made in the correct way – again this will be needed whatever the linking strategy.
- Viewing the FULL safety case (combination of all systems) will only be possible from a Report – but this is the case anyway as there are multiple links to transition.
The key principle that this approach addresses is to make it simple for the majority of the end users. The complexity and the friction cannot be removed entirely, but they can be placed with the advanced users in the core team who are enabled to manage them.
The generalised pattern here is one where there is a set of centrally managed data which is relevant in filtered sets to multiple teams. Those teams only need to see their data – their portion of the centrally managed data plus the data they add. The use of base-to-base links ensures that there is consistency. The use of module-to-module links ensures there is no cluttering of information with other teams.
This works in a situation where there are a manageable number of teams (up to thirty), and a low level of change in the centrally managed data.