I have new users who desire to continue to see the sub section number as part of the requirement ID. I was thinking of combining a portion of the Object Number along with the Absolute Number to create a unique ID for the module using Attribute DXL.
It would go something like:
use the sub section numbering, trim the .0-xx at the end, and replace it with nnn to get 3.2.1.2123.
As they get more comfortable with DOORS, and its ability to search and locate requirements based on the ID, I think we could eventually drop the section numbering with no harm done. Of course they would have to understand that if they move the requirement to another section, that effectively changes "their" version of the ID, but in DOORS, the Absolute Number would remain.
Has anyone else done this, and what pitfalls might I be setting myself up for?
SystemAdmin - Wed Mar 03 08:55:21 EST 2010 |
|
Re: creating a RID based on section numbers for document centric users
llandale - Wed Mar 03 16:47:54 EST 2010
Display the section number along with the ID may make sense.
SYS_123 (3.2.1.4)
But the section number cannot form a unique part of the ID.
|
|
Re: creating a RID based on section numbers for document centric users
SystemAdmin - Wed Mar 03 17:16:10 EST 2010
Cliff Sadler wrote: I have new users who desire to continue to see the sub section number as part of the requirement ID
This sounds like your users have perhaps innocently succumbed to a past bad practice becoming a legitimised practice by virtue of "that's how we have always done it". It would very interesting to know why they feel this UID syntax gives them some sort of advantage.
If users need some sort of paragraph numbering system to help navigate the document then it would be safer to create a DXL Layout column that displays the cleaned up Object Number value and locate this column next to the column displaying the DOORS unique Object Identifier value.
You have correctly identified why this custom format is bad - the UID is no longer a Unique ID every time you add a new section or move requirements around. I would be impressing on your users that the whole point of having UID's for requirements is that they can be used widely as a unique reference pointer, so that if they appear in a document or in another tool somewhere outside of DOORS, then the reader can be safe in the knowledge that this is a cross reference that will never change - this is fundamental to the requirements management principle of Traceability.
Paul Miller
|
|
Re: creating a RID based on section numbers for document centric users
SystemAdmin - Thu Mar 04 09:22:39 EST 2010 SystemAdmin - Wed Mar 03 17:16:10 EST 2010
Cliff Sadler wrote: I have new users who desire to continue to see the sub section number as part of the requirement ID
This sounds like your users have perhaps innocently succumbed to a past bad practice becoming a legitimised practice by virtue of "that's how we have always done it". It would very interesting to know why they feel this UID syntax gives them some sort of advantage.
If users need some sort of paragraph numbering system to help navigate the document then it would be safer to create a DXL Layout column that displays the cleaned up Object Number value and locate this column next to the column displaying the DOORS unique Object Identifier value.
You have correctly identified why this custom format is bad - the UID is no longer a Unique ID every time you add a new section or move requirements around. I would be impressing on your users that the whole point of having UID's for requirements is that they can be used widely as a unique reference pointer, so that if they appear in a document or in another tool somewhere outside of DOORS, then the reader can be safe in the knowledge that this is a cross reference that will never change - this is fundamental to the requirements management principle of Traceability.
Paul Miller
There may be some advantages to showing the heading number if there is a specific template used for many modules - for example Use Cases where (example) all flows are under heading 9.x, sub/alternate flows 9.1++ special requirements under another chapter. However, as Paul pointed out - move, add or DELETE a heading and it all changes...
If needed, use a DXL column to show Object Number to a specific level, that will remove allot of churn. After that, refer to the individual requirements only with their absolute numbers!
|
|
Re: creating a RID based on section numbers for document centric users
SystemAdmin - Fri Mar 05 08:40:30 EST 2010
I wasn't trying to debate the validity of doing this. I was looking for a snip of DXL or another method to make it happen. Probably should have posted in the DXL section. The Object ID will remain the actual RID. I will display the sub section number next to it, and the "experienced" guys will feel better until they get the DOORS paradigm.
So, something like this in a DXL attribute, which can be updated on demand with the tools menu:
// DXL script for an attribute "REQ_ID" to display the subsection where this requirement is located
// Use the Object number, and strip the trailing .0- for each leaf node
// Use Object Type to qualify the object is indeed a requirement, otherwise don't bother
// Wrap the Object Identifier in -[ ]
// 2010 - Cliff Sadler
string str0 = obj."Object Type"
if(str0 == "Requirement") {
string s = number(obj)
string sub = ".0-"
int offset = null
int length = null
bool matchCase = true
bool reverse = true
if (findPlainText (s, sub, offset, length, matchCase, reverse)){
obj.attrDXLName = s 0:-- offset "-"
}
}
Which gets me what's in the attachment. More interesting when it's 3 levels down amongst a thousand requirements.
|
|
Re: creating a RID based on section numbers for document centric users
llandale - Sun Mar 07 15:23:44 EST 2010 SystemAdmin - Fri Mar 05 08:40:30 EST 2010
I wasn't trying to debate the validity of doing this. I was looking for a snip of DXL or another method to make it happen. Probably should have posted in the DXL section. The Object ID will remain the actual RID. I will display the sub section number next to it, and the "experienced" guys will feel better until they get the DOORS paradigm.
So, something like this in a DXL attribute, which can be updated on demand with the tools menu:
// DXL script for an attribute "REQ_ID" to display the subsection where this requirement is located
// Use the Object number, and strip the trailing .0- for each leaf node
// Use Object Type to qualify the object is indeed a requirement, otherwise don't bother
// Wrap the Object Identifier in -[ ]
// 2010 - Cliff Sadler
string str0 = obj."Object Type"
if(str0 == "Requirement") {
string s = number(obj)
string sub = ".0-"
int offset = null
int length = null
bool matchCase = true
bool reverse = true
if (findPlainText (s, sub, offset, length, matchCase, reverse)){
obj.attrDXLName = s 0:-- offset "-"
}
}
Which gets me what's in the attachment. More interesting when it's 3 levels down amongst a thousand requirements.
I believe I can come up with examples where your clever find-the-".0-" won't work. Its probably better to find the Heading section that houses the object, then display that 'number' whatever it is.
Object FindSection(Object obj)
{
// Find the section object housing this object
if (
null obj)
return(
null Object) string Head = obj.
"Object Heading"
if (!
null Head)
return(obj)
// This object IS a section Heading
else
return(parent(obj))
// ** RECURSION **
}
// end FindSection() string Para Object oSection = FindSection(obj)
if (
null oSection)
//- then Para =
"Top Section"
else Para = number(oSection) obj.attrDXLName = identifier(obj)
" (" Para
")"
Actually, the 'is Heading' check is more complicated; perhaps I posted 'fIsHead' on this forum some time ago.
|
|