to remove autogenerated id for headings

hi

Is there any scripting for removing the autogenerated ID for headings alone?
if so pls send me the code also.thanks in advance.

regards,
bhuvana
bhuvanaperiyasamy - Fri Feb 18 01:19:59 EST 2011

Re: to remove autogenerated id for headings
SystemAdmin - Fri Feb 18 03:05:08 EST 2011

DOORS assigns a unique ID to every object - they cannot be deleted.

Are you familiar with the DOORS DXL scripting language?

What you can do is use DXL to create a Layout DXL column that only displays the unique ID of specific objects. In your case, you want to exclude headings. The DXL layout code for that would be:




if (obj.
"Object Heading" 
"" == 
"") then display identifier(obj)


The basic assumption is that if the "Object Heading" attribute is empty, then it's not a heading and therefore we want to see the unique ID.

I'm not sure what your skill level is with DOORS - so here is the instructions on how to insert a DXL Layout column.

Select the column title box of the column that you want to insert a new column next to.

Select Insert > Column

Select the Layout DXL radio button option

Select the Browse button

Select the New button

Copy and paste the DXL code above into the DXL edit area

Select OK (Should be no DXL errors reported)

Give the column a Title in the Column Title text field.

Select the Insert button

The column should now appear - you can drag and move the column to another location if you wish.

Save the View, otherwise you lose the new column that you have added.

Paul Miller
Melbourne, Australia

Re: to remove autogenerated id for headings
bhuvanaperiyasamy - Fri Feb 18 04:23:21 EST 2011

Thanks for your reply.

Re: to remove autogenerated id for headings
llandale - Fri Feb 18 09:59:24 EST 2011

SystemAdmin - Fri Feb 18 03:05:08 EST 2011
DOORS assigns a unique ID to every object - they cannot be deleted.

Are you familiar with the DOORS DXL scripting language?

What you can do is use DXL to create a Layout DXL column that only displays the unique ID of specific objects. In your case, you want to exclude headings. The DXL layout code for that would be:




if (obj.
"Object Heading" 
"" == 
"") then display identifier(obj)


The basic assumption is that if the "Object Heading" attribute is empty, then it's not a heading and therefore we want to see the unique ID.

I'm not sure what your skill level is with DOORS - so here is the instructions on how to insert a DXL Layout column.

Select the column title box of the column that you want to insert a new column next to.

Select Insert > Column

Select the Layout DXL radio button option

Select the Browse button

Select the New button

Copy and paste the DXL code above into the DXL edit area

Select OK (Should be no DXL errors reported)

Give the column a Title in the Column Title text field.

Select the Insert button

The column should now appear - you can drag and move the column to another location if you wish.

Save the View, otherwise you lose the new column that you have added.

Paul Miller
Melbourne, Australia

Two tiny tweaks: <1> I'd be tempted to display the ID only when the Text is also non-blank. <2> DOORS assigns a unique "Absolute Number"; the ID is somewhat at the mercy of the "Prefix" module attribute value.

Re: to remove autogenerated id for headings
SystemAdmin - Fri Feb 18 11:43:27 EST 2011

SystemAdmin - Fri Feb 18 03:05:08 EST 2011
DOORS assigns a unique ID to every object - they cannot be deleted.

Are you familiar with the DOORS DXL scripting language?

What you can do is use DXL to create a Layout DXL column that only displays the unique ID of specific objects. In your case, you want to exclude headings. The DXL layout code for that would be:




if (obj.
"Object Heading" 
"" == 
"") then display identifier(obj)


The basic assumption is that if the "Object Heading" attribute is empty, then it's not a heading and therefore we want to see the unique ID.

I'm not sure what your skill level is with DOORS - so here is the instructions on how to insert a DXL Layout column.

Select the column title box of the column that you want to insert a new column next to.

Select Insert > Column

Select the Layout DXL radio button option

Select the Browse button

Select the New button

Copy and paste the DXL code above into the DXL edit area

Select OK (Should be no DXL errors reported)

Give the column a Title in the Column Title text field.

Select the Insert button

The column should now appear - you can drag and move the column to another location if you wish.

Save the View, otherwise you lose the new column that you have added.

Paul Miller
Melbourne, Australia

I have often discussions with new DOORS users on the DOORS identifier / Absolute Number. They think that headings should not have IDs, just the requirements. Often this includes explaining the DOORS object model and typically saying at the end that they should not care about the identifiers for heading objects, just the identifiers for "real" requirements and use those. Quite often somebody wants either a similar solution as you presented with a Layout column or even want to maintain manually theit own identifier just for the requirements...

Re: to remove autogenerated id for headings
SystemAdmin - Fri Feb 18 19:21:41 EST 2011

SystemAdmin - Fri Feb 18 11:43:27 EST 2011
I have often discussions with new DOORS users on the DOORS identifier / Absolute Number. They think that headings should not have IDs, just the requirements. Often this includes explaining the DOORS object model and typically saying at the end that they should not care about the identifiers for heading objects, just the identifiers for "real" requirements and use those. Quite often somebody wants either a similar solution as you presented with a Layout column or even want to maintain manually theit own identifier just for the requirements...

Pekka wrote: ....and typically saying at the end that they should not care about the identifiers for heading objects...

Firstly, I support your statement above 100%.

Secondly, I've given up trying to convince some users that it's OK for every object to have a UID, if you don't use the UID, who cares? They have it in their heads that this is confusing and violates the written law of Requirements Management 101 - I think it stems from some text books iterating that "only requirements have UID's" - I prefer to use a separate attribute to indicate the disposition of each object (paragraph) in terms of whether it's a requirement, not a requirement, a special type of requirement etc

Paul Miller
Melbourne, Australia

Re: to remove autogenerated id for headings
llandale - Mon Feb 21 12:20:00 EST 2011

SystemAdmin - Fri Feb 18 19:21:41 EST 2011
Pekka wrote: ....and typically saying at the end that they should not care about the identifiers for heading objects...

Firstly, I support your statement above 100%.

Secondly, I've given up trying to convince some users that it's OK for every object to have a UID, if you don't use the UID, who cares? They have it in their heads that this is confusing and violates the written law of Requirements Management 101 - I think it stems from some text books iterating that "only requirements have UID's" - I prefer to use a separate attribute to indicate the disposition of each object (paragraph) in terms of whether it's a requirement, not a requirement, a special type of requirement etc

Paul Miller
Melbourne, Australia

The issue here is that the "Object Identifier" is supposed to uniquely identify the object, its not intended to uniquely identify the "Requirement" therein. Now most folks use the ObjID as the Requirements ID and this is often a reasonable and convenient choice, but it is methodologically very UNSOUND.

++ When the object is deleted and purged you are all hosed up.
++ When the requirement originates elsewhere, such as some old MS-Word document, its IDs won't correspond when you import into DOORS.
++ There is always issues when that requirement exists in some other database or some other DOORS document.
++ If you completely change the text in an object (change a "weight" requirement to a "color" one, which you should not), the new Req will inherit the old ID.
++ There are other reason's that don't come to mind.

Folks who indeed want to use the ObjID as the ReqID, are well advised to actually create a "ReqID" attribute composed of Attr-DXL that displayed ObjID when the object is indeed a requirement, either the text has "shall" or the IsReq attribute is true. Common folks will start refering to "ReqID", which lets you easily transfer over to another method seemlessly, with ObjID issues start arrising.

  • Louie

Re: to remove autogenerated id for headings
SystemAdmin - Mon Feb 21 16:40:28 EST 2011

llandale - Mon Feb 21 12:20:00 EST 2011
The issue here is that the "Object Identifier" is supposed to uniquely identify the object, its not intended to uniquely identify the "Requirement" therein. Now most folks use the ObjID as the Requirements ID and this is often a reasonable and convenient choice, but it is methodologically very UNSOUND.

++ When the object is deleted and purged you are all hosed up.
++ When the requirement originates elsewhere, such as some old MS-Word document, its IDs won't correspond when you import into DOORS.
++ There is always issues when that requirement exists in some other database or some other DOORS document.
++ If you completely change the text in an object (change a "weight" requirement to a "color" one, which you should not), the new Req will inherit the old ID.
++ There are other reason's that don't come to mind.

Folks who indeed want to use the ObjID as the ReqID, are well advised to actually create a "ReqID" attribute composed of Attr-DXL that displayed ObjID when the object is indeed a requirement, either the text has "shall" or the IsReq attribute is true. Common folks will start refering to "ReqID", which lets you easily transfer over to another method seemlessly, with ObjID issues start arrising.

  • Louie

Louie, I'd like to understand more about what you've experienced here, always interested in the lessons learned of others when it comes to RM practices, see my interleaved questions

When the object is deleted and purged you are all hosed up.
How would not using the ObjID avoid this? Any other ID would be gone as well, no?

When the requirement originates elsewhere, such as some old MS-Word document, its IDs won't correspond when you import into DOORS.
Agree - DOORS ObjID needs to be hidden in favour of only displaying the imported UID from the original doc.

There is always issues when that requirement exists in some other database or some other DOORS document.
How would not using the ObjID avoid this, or act to reduce the potential for this to happen anyway?

If you completely change the text in an object (change a "weight" requirement to a "color" one, which you should not), the new Req will inherit the old ID.
Don't understand why inheriting an old DOORS ObjID is a bad thing if the disposition changes from "was originally not a requirement" to "its now a requirement" - as long as it's unique & traceable, isn't that OK?

The one weakness of DOORS that does irk me with respect to ObjID's is that it does not have a native built in function that warns you if the same ObjID prefix has been used more than once in a project, or even across the entire DB, effectively resulting in duplicate ID's being used.
Paul Miller
Melbourne, Australia

Re: to remove autogenerated id for headings
llandale - Tue Feb 22 12:50:20 EST 2011

SystemAdmin - Mon Feb 21 16:40:28 EST 2011
Louie, I'd like to understand more about what you've experienced here, always interested in the lessons learned of others when it comes to RM practices, see my interleaved questions

When the object is deleted and purged you are all hosed up.
How would not using the ObjID avoid this? Any other ID would be gone as well, no?

When the requirement originates elsewhere, such as some old MS-Word document, its IDs won't correspond when you import into DOORS.
Agree - DOORS ObjID needs to be hidden in favour of only displaying the imported UID from the original doc.

There is always issues when that requirement exists in some other database or some other DOORS document.
How would not using the ObjID avoid this, or act to reduce the potential for this to happen anyway?

If you completely change the text in an object (change a "weight" requirement to a "color" one, which you should not), the new Req will inherit the old ID.
Don't understand why inheriting an old DOORS ObjID is a bad thing if the disposition changes from "was originally not a requirement" to "its now a requirement" - as long as it's unique & traceable, isn't that OK?

The one weakness of DOORS that does irk me with respect to ObjID's is that it does not have a native built in function that warns you if the same ObjID prefix has been used more than once in a project, or even across the entire DB, effectively resulting in duplicate ID's being used.

Paul Miller
Melbourne, Australia

I'm a lot better at DXL than this sort of project architecture.

When the object is deleted and purged you are all hosed up.
How would not using the ObjID avoid this? Any other ID would be gone as well, no?
No. If you purge object with ReqID 22, you can create a new object and give it ReqID 22, and recreate it completely.

*When the requirement originates elsewhere, such as some old MS-Word document, its IDs won't correspond when you import into DOORS.
*Agree - DOORS ObjID needs to be hidden in favour of only displaying the imported UID from the original doc.
Didn't say you must hide the ObjID, just understand that its an OBJECT identifier, not the REQUIREMENT identifier.

*There is always issues when that requirement exists in some other database or some other DOORS document.
*How would not using the ObjID avoid this, or act to reduce the potential for this to happen anyway?
If you use a string ReqID, you can assign that other thing to this Object's ReqID.

*If you completely change the text in an object (change a "weight" requirement to a "color" one, which you should not), the new Req will inherit the old ID.
*Don't understand why inheriting an old DOORS ObjID is a bad thing if the disposition changes from "was originally not a requirement" to "its now a requirement" - as long as it's unique & traceable, isn't that OK?
Yes, going from not-a-requirement to is-a-requirement would work OK, but not Is-A-Requirement to Is-A-Completely-Different-Requirement; in which case you would WANT it to have a new ID.

The one weakness of DOORS that does irk me with respect to ObjID's is that it does not have a native built in function that warns you if the same ObjID prefix has been used more than once in a project, or even across the entire DB, effectively resulting in duplicate ID's being used
Yes another reason; Using ObjID requires you to manage unique Prefixes. On the other hand you would want to do that anyway.

Having a separate ReqID indeed forces folks to understand its relationship to the requirement and its ID; sort of like the relationship between a "Document" and its "Document Number"; something few folks would use ObjID for.

  • Louie

Re: to remove autogenerated id for headings
Bob_Swan - Thu Mar 03 06:07:17 EST 2011

SystemAdmin - Fri Feb 18 19:21:41 EST 2011
Pekka wrote: ....and typically saying at the end that they should not care about the identifiers for heading objects...

Firstly, I support your statement above 100%.

Secondly, I've given up trying to convince some users that it's OK for every object to have a UID, if you don't use the UID, who cares? They have it in their heads that this is confusing and violates the written law of Requirements Management 101 - I think it stems from some text books iterating that "only requirements have UID's" - I prefer to use a separate attribute to indicate the disposition of each object (paragraph) in terms of whether it's a requirement, not a requirement, a special type of requirement etc

Paul Miller
Melbourne, Australia

I also agree with all previous comments.

The long discussions seem to occur when there is no defined Requirements Management process in the company (or its being ignored).
How hard is it really to accept Object ID is not Requirement ID?
The prime advantage of a user attribute for ID's is that you can have have differant types, (Requirement, Capability, Function, maybe Political, Legal, Penalty, etc) You define the options, the designer/architect/manager assigns them as they want.

Re: to remove autogenerated id for headings
SystemAdmin - Thu Mar 03 17:03:43 EST 2011

Bob_Swan - Thu Mar 03 06:07:17 EST 2011
I also agree with all previous comments.

The long discussions seem to occur when there is no defined Requirements Management process in the company (or its being ignored).
How hard is it really to accept Object ID is not Requirement ID?
The prime advantage of a user attribute for ID's is that you can have have differant types, (Requirement, Capability, Function, maybe Political, Legal, Penalty, etc) You define the options, the designer/architect/manager assigns them as they want.

Hi Bob,

I have a genuine interest in the various perspectives and approaches taken by others when it comes to requirements engineering practices - always looking out for valuable sage advice. I'm interested in your comments about UID's which also parallels some of Louie Landale's comments in this thread.

When it comes to UID's, I've not yet encountered a situation where I could not use the ObjID created by DOORS as my Requirements ID. Others, such as yourself, see a value in creating your own Req ID attribute and entering the ReqID manually (I assume manually) as well as overloading this to be both a unique reference pointer for traceability purposes as well as a Req Type attribute. This requires strict adherence to a syntax of some sort and also some sort of check to make sure that the same ReqID has not been used more than once within the module and across the entire DOORS project. Two questions.

1. How does an author know if they are duplicating an already used ReqID (DXL of some sort?)

2. Is there not also a value in letting DOORS look after setting the ReqID (ObjID), thus avoiding duplication & human error issues, and using a separate attribute for Requirement Type (avoids syntax mishaps)?

Paul Miller
Melbourne, Australia

Re: to remove autogenerated id for headings
SystemAdmin - Thu Mar 03 17:09:40 EST 2011

SystemAdmin - Thu Mar 03 17:03:43 EST 2011
Hi Bob,

I have a genuine interest in the various perspectives and approaches taken by others when it comes to requirements engineering practices - always looking out for valuable sage advice. I'm interested in your comments about UID's which also parallels some of Louie Landale's comments in this thread.

When it comes to UID's, I've not yet encountered a situation where I could not use the ObjID created by DOORS as my Requirements ID. Others, such as yourself, see a value in creating your own Req ID attribute and entering the ReqID manually (I assume manually) as well as overloading this to be both a unique reference pointer for traceability purposes as well as a Req Type attribute. This requires strict adherence to a syntax of some sort and also some sort of check to make sure that the same ReqID has not been used more than once within the module and across the entire DOORS project. Two questions.

1. How does an author know if they are duplicating an already used ReqID (DXL of some sort?)

2. Is there not also a value in letting DOORS look after setting the ReqID (ObjID), thus avoiding duplication & human error issues, and using a separate attribute for Requirement Type (avoids syntax mishaps)?

Paul Miller
Melbourne, Australia

Gee I wish this forum supported editing of posts!!

A qualification on something I said in my previous post "I've not yet encountered a situation where I could not use the ObjID created by DOORS as my Requirements ID" the exception here is when a customer has used their own ReqID and can't live without it and must continue to be used once exported to DOORS.

Paul Miller
Melbourne, Australia

Re: to remove autogenerated id for headings
SystemAdmin - Tue Oct 11 11:52:39 EDT 2011

SystemAdmin - Thu Mar 03 17:09:40 EST 2011
Gee I wish this forum supported editing of posts!!

A qualification on something I said in my previous post "I've not yet encountered a situation where I could not use the ObjID created by DOORS as my Requirements ID" the exception here is when a customer has used their own ReqID and can't live without it and must continue to be used once exported to DOORS.

Paul Miller
Melbourne, Australia

I know this post is older, but I share some of Paul's questions and didn't feel it was necessary to start a new thread.

I have just started using DOORS, and I was under the understanding that using the DOORS generated Object ID as the requirement ID was the preferred method. This would ensure that the IDs were always unique within a module and provided the best method of linkage between modules.

Now I understand that with imported requirements specs it's not always possible to have the Object ID match a pre-generated Requirements ID, but in cases where the requirements are generated in DOORS, is it best to use the Object ID, or should a separate ReqID be generated? And how is that guaranteed to be unique?

Re: to remove autogenerated id for headings
SystemAdmin - Tue Oct 11 12:13:18 EDT 2011

SystemAdmin - Tue Oct 11 11:52:39 EDT 2011
I know this post is older, but I share some of Paul's questions and didn't feel it was necessary to start a new thread.

I have just started using DOORS, and I was under the understanding that using the DOORS generated Object ID as the requirement ID was the preferred method. This would ensure that the IDs were always unique within a module and provided the best method of linkage between modules.

Now I understand that with imported requirements specs it's not always possible to have the Object ID match a pre-generated Requirements ID, but in cases where the requirements are generated in DOORS, is it best to use the Object ID, or should a separate ReqID be generated? And how is that guaranteed to be unique?

I always recommend to use the DOORS Object Identifier. If you have some legacy ID it is easiest to use that only for reference and not to give your own ID values for new requirements / objects. If however there is a need to continue to use the legacy IDs then typically some kind of DXL script is used to check for uniqueness.

Re: to remove autogenerated id for headings
DOORSWizard - Tue Oct 11 12:54:02 EDT 2011

SystemAdmin - Tue Oct 11 12:13:18 EDT 2011
I always recommend to use the DOORS Object Identifier. If you have some legacy ID it is easiest to use that only for reference and not to give your own ID values for new requirements / objects. If however there is a need to continue to use the legacy IDs then typically some kind of DXL script is used to check for uniqueness.

I am a big believer in using the DOORS Object ID whenever possible, even keeping the legacy ID in a separate attribute is fine but you're just asking for much more of a headache in trying to ensure it's unique. Another thought would be to:

1) Get the legacy document into .csv format and make the legacy ID the Absolute Number column.
2) Determine the largest number in your document outside of DOORS. (i.e. 2345)
3) Create a new DOORS module and pre-create the number from #2 objects (i.e. 2345 objects)
4) Import your spreadsheet selecting update existing objects based on Absolute Number
5) With the help of DXL delete the extraneous objects that didn't get updated and re-arrange the module

Assuming you don't need to go through another update, you have just created a DOORS module preserving the ability to use the DOORS ID based on legacy ID.

Alex

Re: to remove autogenerated id for headings
llandale - Tue Oct 11 18:57:05 EDT 2011

SystemAdmin - Tue Oct 11 11:52:39 EDT 2011
I know this post is older, but I share some of Paul's questions and didn't feel it was necessary to start a new thread.

I have just started using DOORS, and I was under the understanding that using the DOORS generated Object ID as the requirement ID was the preferred method. This would ensure that the IDs were always unique within a module and provided the best method of linkage between modules.

Now I understand that with imported requirements specs it's not always possible to have the Object ID match a pre-generated Requirements ID, but in cases where the requirements are generated in DOORS, is it best to use the Object ID, or should a separate ReqID be generated? And how is that guaranteed to be unique?

My opinion on this subject is clearly in the minority.

It seems to me that if you specs existed with Requirement IDs outside of DOORS then they have a non-DOORS meaning, and you would go ahead and have your own Requiement ID attribute and maintain its uniqueness.

Using the ObjID for the ReqID is certainly the easiest method, but there are lots of situations where you clobber yourself. For one thing, you would not be able to export your requirements figuring to import them into some other database (such as a Secret one) since that other module would have different Object IDs <yes, you CAN very awkwardly line them up>.

But perhaps you can have your cake and eat it too. You have a "ReqID-Raw" string attribute that is blank for most objects, but contains some ID generated outside DOORS for many requirements. Then write a attrDXL "ReqID" attribute that uses "ReqID-Raw" when its non blank, otherwise displays the Object Identifier.

The pro-ObjID folks argue rightfully that 1 its hard to manage 1000s of unqiue IDs, 2 that the vast majority of of the time ObjID works just fine, and 3 requriements are most often now-a-days generated in DOORS and rarely have some outside ID. Well, 1 its easy to write a "Get next Req ID" that maintains info in Config Files; 2 "vast majority of the time" means that "once in a while" you have a big problem, and 3, they are right about that.

I liken all this to other non-Requirement things you may put into DOORS, such as Procurement Specs and Detailed Drawings. All those have unique IDs that are generated outside of DOORS and have real meaning to real people who don't even know what "DOORS" is. Modules housing those references clearly have a "ProcurementID" or "DrawingNumber" attribute, uniquely identifying it.

We are currently battling here over whether to use "Equipment-ID" as the unique identifier, where several folks want to use Object Identifier. I argue unsucessfully that the Planning the Scheduling folks care about Equipment IDs and definately do NOT want a report telling them which to install when, based on "Object Identifier", which has no meaning what-so-ever to them.

  • Louie