DOORS Next Artifact Types

One of the really nice features of DOORS Next is that artifact* types are defined for the project, and artifacts used in a module can be of various types.

Quick translation: Artifact in this context is like an Object in DOORS Classic, although other things can be artifacts as well.

In DOORS Classic I always recommended an attribute for Object Type which would be an enumeration with values like

• Requirement
• Information
• Heading
• Not Set (default)

For more advanced users we would include different types of requirement.  There are many good reasons for doing this, including the ability to filter by Object Type so that, for example, Requirements with no InLinks through the ‘satisfies’ link module can be identified.We also might want to filter on Requirements that have no value set for the ‘Delivery Phase’ attribute.

Headings need very little additional information, the heading number, the unique id and the Heading text is about it.  Information Objects might want an attribute to show the scope, or the source.  Requirements need a multitude of additional information; depending on the requirement type there will be typically around six to 10 actively managed attributes at any point in time for each interested team, and over the life of the requirement there can easily be 20, 30, 50, or more attributes that have at least historical value.  With a pause for thought here, I think that many of those attributes will have values of N/A for some requirement types, but because attributes in DOORS Classic are module-wide there is no option to say they do not exist for some objects.

While we are looking at the shortcomings of DOORS Classic, one question I have been asked many times is how to copy attributes across to different modules.  I don’t have DOORS running, but memory tells me it is Edit->Attributes->Import or similar, then browse to the Module with the desired Attributes and bring them across.  A thoroughly reasonable process I feel, and if modules are created by copying an empty template module then there is very little need to even go through that simple process.

DOORS Next, however, is very nice in this regard.  Artifacts have a different sort of heritage in DOORS Next, they don’t live in the module, they are just referenced from the module.  Artifacts of different types are collected together and organized in a hierarchy that we call a Module.  This module doesn’t have attributes that apply to all of its artifacts.  So we can have a Heading artifact type with just a minimal set of attributes and a Functional Requirement artifact type with many more attributes.  Safety requirements might want an attribute for potential damage, Functional requirements might want an attribute for operational modes.

The N/A value that was set so often in DOORS Classic is much less in demand for DOORS Next.  There is no clutter of totally irrelevant attributes for an artifact.  It is easier to see what should be populated.

Another common question: ‘Can I mandate that a value for a particular attribute should be set?’  The answer is still the same ‘No, but we can sort that out with scripting’.  DXL was the answer for DOORS Classic, and a trigger was the surest way to go if you had someone competent enough to play with them (they are tricky and not for beginners!).  We have some basic scripting now available for DOORS Next (javaScript with html), and while it is prototype only and not terribly sophisticated (nothing in place to ensure that a client is actually running the script), it is a start and will surely improve over time.  There is also the dashboard to consider, you can show the number of artifacts of a particular type with an attribute not set – the widget shows the result of a view, so anything that can be defined in a view can be shown.

DOORS Classic experts will need to reconsider their data models, but this part of the shift should be easy and welcome.  New users will appreciate the project-wide approach to attribute definition.

*Artifact is the American spelling, Artefact is the British spelling.  IBM uses US English so I am following suit for words used in the tool when I remember.  Also my in-browser spell checker is US English.