In DOORS Classic we have a Module prefix; every requirement (Object) has a number that is unique within the module, and every requirement in a module has the same prefix. The prefix is user defined, and so not guaranteed unique in the database, or even the project, but that is what we are used to, and we like it, mostly.
DOORS Next Generation gives every requirement (artifact) a number that is unique within the database, but there is no prefix. Technically, we don’t need it, we have a better way to pinpoint the exact requirement of interest – using that unique-within-the-database number, but migrating people is nothing like as easy as migrating data.
There are a couple of obvious routes around this. First we can do some clever scripting in DNG to mash together a module attribute and the ID, we would have to consider the consequences when re-using a requirement in a project; the same artifact could potentially end up with two different identifiers dependent on from where the script was last run, which would be generally a ‘bad’ thing.
My preferred option, at least for now, is to have an attribute on the requirement with the prefix. Make this a string or enumeration with a default value. Now our stakeholder requirements have an attribute with ‘Stk-‘ and our functional requirements have an attribute with ‘Func-‘. These are separate artifact types, with separate attribute types. Headings probably don’t need anything and information could either have nothing or ‘Info-‘. These are all separate attributes, and are assigned to the requirement type.
This results in a module with multiple requirement types having a selection of ‘prefixes’; something that I have heard requested by numerous DOORS Classic customers through the years.
This ‘prefix’ attribute would be shown in a column to the left of the ID column to give the illusion of a combined identifier, it can also be exported in reports to easily carry that information through to other formats. In the example in the image, I have a ‘prefix’ of ‘STK-‘.
By setting a default value, whenever a new artifact is created, the default value will be assigned and no action need be taken by the user. If we make this an enumeration with only one value, then there will be no option to change this to something that is outside of the process. An alternative is to create a single enumerated type for all prefixes, and still use separate attributes, each with a different default/initial value.