DOORS Tips: Links, Analysis and Views
Hazel Woodcock 270002KYG8 Comments (5) Visits (13753)
First the boundaries between modules need to be defined; a formal module should contain only one ‘type’ of information, requirements at a certain level, tests, risks or whatever else you are capturing. Once these modules are defined, the relationships between them should be identified.
Defining this structure allows for ease of analysis later in the project and use of the same schema across projects, even with tailoring, allows for cross project comparisons and reporting and a lower barrier to entry for people moving to a new project. This structure can also help with following process and providing a repeatable audit trail for certification to national and international standards. This is particularly important in highly regulated industries.
A link schema is typically drawn out with boxes for the formal modules, lines for the linksets, and the name of the link module on the line. A link module name such as ‘satisfies’ or ‘tests’ will appear multiple times on the diagram indicating a number of linksets in a single link module. Describing the relationship in a short sentence is a good idea, for example, ‘Requirement satisfies higher level requirement’. This sentence can be used for the link module description and the verb can be used as the link module name.
Some relationships are not considered good practice. Round trip links, where two modules can be connected in either direction are not normally valid. Multiple routes between two modules are also generally an indication that something has gone wrong. Linking within a module is often an indication that the module contains more than one type of information and should be split. Use of the default DOORS Links module is discouraged because it shows that the relationship was not planned as a part of the schema. To enforce this, the DOORS Links module can be created in every folder, and then soft deleted. This makes it unavailable for use, and a new DOORS Links module cannot be created while the existing one is still present in its deleted form.
Links should go from the later information to the earlier information. A link should be created at the time the dependent information is added. So when adding a lower level requirement, reference to the existing higher level requirement is appropriate. Access rights make it practical to create the links from the lower level to the higher level. Links will be traversable in either direction through analysis later.
The link schema is implemented by creating the named link modules, usually in an Admin folder in the DOORS project, and for each module, setting up the allowable linkages in the module properties. By setting the option to ‘Only allow outgoing links to the target modules in the above list’, you disallow ad-hoc linking that does not fit with the schema.
A template project can easily be created so that this set up time is minimised for each new project.
Once the project is set up, the allowable relationships are enforced. There is no automated checking that individual links are valid – that requires rather more intelligence than can be included in a requirements management tool.
Analysis can then be carried out, looking at either a single link type through multiple levels, such as the ‘satisfies’ links, or for the existence of a particular link type to ensure that each requirement has an associated test for example.
This analysis can be easily viewed in a column using the inbuilt wizard. The view can then be saved so that all team members can see it, ensuring a consistent picture of the information across the project team.