May 062016

2015-07-10 12.18.31In 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.

DNGModulePrefixThis ‘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.

  2 Responses to “So you miss your DOORS Module Prefix…”

  1. Noo… we really loose the prefix? I can foresee great cries already for us. We’re right you know: this is a dearly held thing, and goes everywhere … better go prepare the team now.
    Thanks for the heads-up.

    • It really isn’t so bad Alex. You gain the ability to have multiple ‘object’ (actually artifact) types in a single module, and to reuse individual artifacts across multiple modules. The Prefix as you know it wouldn’t make sense in a DOORS Next Generation world. We also have an identifier that will be unique within the project, with DOORS 9.x you can easily have ‘STK-43’ in two or more modules in a project.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: