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.

  3 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.

  2. Hi Hazel,
    We are using DOORS 9.5.1.2 and sending our Contractors a ReqIF file to import into DOORS NG. As you explain above, we have lost the unique object IDs with our prefixes through this process. The requirements are being imported into DOORS NG with new IDs starting at 1. Going forward, we plan to the use ReqIF import/export feature to send our requirements back and forth between our group and the Contractor’s team. If we are not able to keep the same Unique IDs in the original database, then we are going to have difficulty maintaining our full lifecycle traceability. My questions:

    1. Any suggestions for maintaining the Unique IDs while we go back and forth between DOORS 9.5.2.1 and DOORS NG. Changes will be made to the requirements and attributes in DOORS NG and then we will need to see those changes and perform requirements traceability using the original Unique IDs in DOORS 9.5.2.1.

    2. I read in one of the IBM Forums on the Jazz Community Site, that the Unique IDs may be maintained when exporting from DOORS 9.6 to DOORS NG. Do you have any experience with this? I’m wondering if upgrading to DOORS 9.6 will help this situation.

    Thanks so much for the above post too! It is very helpful!

Leave a Reply

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

%d bloggers like this: