Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Absolute Number Usage
Topic Summary: How do you reuse an absolute number for an unsaved object?
Created On: 19-Sep-2007 19:34
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 19-Sep-2007 19:34
User is offline View Users Profile Print this message


Joe Sarkic

Posts: 31
Joined: 13-Jun-2005

When a user creates a new object, a unique absolute number is assigned to that object. If the user does not save the module where this new object has been created, the absolute number that was used is not preserved for the next object that is created.

My question is:

Is there any way to reuse the absolute number of a new object if that object was never saved with a module?
Report this to a Moderator Report this to a Moderator
 19-Sep-2007 20:00
User is offline View Users Profile Print this message


Pete Kowalski

Posts: 301
Joined: 7-Feb-2003

No, you would not use the same absolute number within the same module.

-------------------------
pete.kowalski(at)motorola.com
Report this to a Moderator Report this to a Moderator
 19-Sep-2007 20:01
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Joe,

Not that I'm aware of.

Is this really a problem for you? If so, why? The absolute number is just a primary key. It really doesn't signify any type of order. I've had users complain about the break in numbering when you insert a requirement into an existing section, but most users understand that this is just how DOORS works and the number doesn't have any real significance.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 19-Sep-2007 20:41
User is offline View Users Profile Print this message


Joe Sarkic

Posts: 31
Joined: 13-Jun-2005

Personally this is not a problem. A number is a number.

Where this becomes a problem is when a customer gets a copy of a module's content (whether through MS Word, an archive, a partition, etc.) and they start to question the missing values. From their perspective it looks like requirements have been deleted. Some recipients tend to turn trivial events into major issues.

This problem is particularly evident in one module where a user ran a DXL script, did not like the results and closed the module. The user ran this DXL script multiple times which ended up creating approximately 20,000 objects, causing a huge gap in absolute numbers. We've tightened security access on our modules to prevent this from happening again. This is an extreme example, although gaps exists in just about every module, but at a much smaller scale.

I'm just trying to avoid training everyone about the nuances of DOORS, if we can avoid it.
Report this to a Moderator Report this to a Moderator
 19-Sep-2007 20:58
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Joe,

I didn't think it was a problem just for you--but you bring up a great point: tiny things can be huge problems when they are interpreted by people who are ignorant.

(I don't mean "ignorant" as an insult...not everyone should know how DOORS absolute numbers work!)

I don't know why DOORS treats an unsaved absolute number as a used absolute number. There is likely an architectural reason for Telelogic to do so.

My advice for the problem you had is to educate the user. It's not so much about access rights as it is about that he should have done this in a sandbox area. Creating 20,000 objects, even if they are just blank objects, takes a bit of time. This user was obviously experimenting and thought that by not saving the module that he was ok. (I'd think the same!)

For expirements such as this, users need a sandbox and be educated on what it's for (hint: it's a sandbox--real production work is done in production).

Sorry to hear about mountains out of molehills. I wish that was truly confined just to DOORS.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts

Edited: 19-Sep-2007 at 21:00 by Kevin Murphy
Report this to a Moderator Report this to a Moderator
 19-Sep-2007 22:31
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Rationale: try this. Open modules A and B exclusive. Create new object A_2 and create a link from B_1 to A_2. Save module B. Close but don't save A. Open B. There should be a corrupted link. Now edit A and create a new object. If that object is #2, then does it automatically become the target of that link that previously was corrupted?

There is a particular database file that contains the 'next' absolute number to be used for a particular module. I've never tried it and never will, but I'm confident that you could restore a previous value of just that file and viola! you are reusing old absolute numbers for that module. Don't do that, don't give so much power to Absolute Numbers and let DOORS handle it.

- Louie
Report this to a Moderator Report this to a Moderator
 20-Sep-2007 08:50
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

Rather than using the absolute number to identify requirements have a specific attribute with unique numbering. That way you can avoid showing the absolute number anywhere except in the DOORS display.

Report this to a Moderator Report this to a Moderator
 20-Sep-2007 17:44
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Robert,

I think that is very bad advice.

I worked on a database set up like this, and you have to worry about typos and duplicates.

Do what Lou says. Just let DOORS handle the numbering. It's less work and Object Identifiers are built-in to many DOORS functions.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 21-Sep-2007 14:34
User is offline View Users Profile Print this message


Joe Sarkic

Posts: 31
Joined: 13-Jun-2005

I agree with Kevin that DOORS should be responsible for managing these unique identifiers. When you introduce data that is under human management, we make ourselves susceptible to errors.

In summary, gaps will happen in Absolute Numbers. There are numerous events that can cause these gaps:

    1. DXL scripts creating objects and tables that are not saved,

    2. A user changing their mind when they create a new object,

    3. Network crashes before a user has a chance to save a module with new objects,

    4. Importing CSV file that creates new empty objects,

    5. etc.


Our only defenses against this includes education, and a sandbox area for testing.
Report this to a Moderator Report this to a Moderator
 21-Sep-2007 15:14
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I did not suggest that using ObjID to also mean 'Requirement ID' was a great idea. Methodologically its not particularly sound. For one thing, the only way to get requirements from one database or project to another is via archive-restore, rather than export-import. If you do use ObjID then you must also have a policy where all the module's Prefixes in the project are unique which will cause all the ObjIDs to also be unique.

From a practical standpoint, however, it works fairly well to use ObjID as Requirement ID, and as far as I can tell most folks do it. Its main advantage is that if enforces the notion that DOORS contains the 'source' of all requirements, and all exports are just copies made obsolete the second they are exported.

One advantage of having a separate 'Requirement ID' (aka 'Capability ID') is that it allows one to use clever suffixes in the ID to mean derivatives: If 'Sys_001' is "System shall be Green' then linked sub-system IDs could be 'Sys_001.1' 'SubSystem A shall be Green'.

If requirements are sources elsewhere, such as perhaps the list of drawings, then you must have an external 'ID' recognized by that external program, e.g. unique 'Drawing IDs'.

- Louie
Report this to a Moderator Report this to a Moderator
 21-Sep-2007 15:47
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

quote:

Originally posted by: Louie Landale
I did not suggest that using ObjID to also mean 'Requirement ID' was a great idea. Methodologically its not particularly sound. For one thing, the only way to get requirements from one database or project to another is via archive-restore, rather than export-import.


Lou, I can't believe I'm going to disagree with you or even slightly argue with you--but really, what does an ObjID have to do at all with moving requirements between databases? I am completely missing your point here.

To someone not versed well in DOORS and moving modules to other database, they may read your statement as "the ObjID changes from database to database." This isn't what you mean (as it isn't true), but I fail to see how module transfers even entered this discussion in the first place.

quote:

If you do use ObjID then you must also have a policy where all the module's Prefixes in the project are unique which will cause all the ObjIDs to also be unique.


Agreed, but isn't that what most people do?

quote:

From a practical standpoint, however, it works fairly well to use ObjID as Requirement ID, and as far as I can tell most folks do it. Its main advantage is that if enforces the notion that DOORS contains the 'source' of all requirements, and all exports are just copies made obsolete the second they are exported.


From a practical and theoretical standpoint it make sense to use ObjIDs as Requirement IDs in almost all cases.

The main advantage is the ID creation is not a manual effort. DOORS does this automatically. I've seen plenty of people have documents with DOORS IDs and then give me a Word document they updated and told me to "blow away the current module and import this one." What they didn't say was, "DOORS IDs be damned," but they meant that. So just having IDs implies that DOORS is the source, but if the users are apathetic, and can get away with it, they will, especially if links haven't been made, because to them, a number is just a number, and DOORS can create more!

quote:

One advantage of having a separate 'Requirement ID' (aka 'Capability ID') is that it allows one to use clever suffixes in the ID to mean derivatives: If 'Sys_001' is "System shall be Green' then linked sub-system IDs could be 'Sys_001.1' 'SubSystem A shall be Green'.


What if one subsystem requirement links to two System Requirements? What if the link gets changed? What if the link gets broken? Your IDs are in a state a flux. This is bad database practice.

quote:

If requirements are sources elsewhere, such as perhaps the list of drawings, then you must have an external 'ID' recognized by that external program, e.g. unique 'Drawing IDs'.


Nothing wrong with this, in my opinion, but if the Drawing ID can be put into DOORS as an OLE, it ought to be referred to by its DOORS ID.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts

Edited: 21-Sep-2007 at 15:53 by Kevin Murphy
Report this to a Moderator Report this to a Moderator
 21-Sep-2007 17:01
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

I understand that my opinion is a minority one. However, I'm sure that methodolgically speaking, using ObjIDs as 'Requirement IDs' is methodolgocically unsound, even though it has significant practical advantages.

I didn't say ObjIDs change when you archive-restore, I said that the only way to preserve them between databases is archive-restore, you cannot use export-import. If you had a separate ReqID attribute, then you could export-import.

Using ObjID implies that [1] a requirement only exists if its in DOORS [2] a requirement comes into existence when you create a DOORS object. [1] is mostly but not perfectly true: for example, typical 'ORD' or pre-contract specs are done in Word and these certainly need Requirement IDs to be referenced adequately. [2] suggests that an object is a requirement which is certainly not true. Instead you routinely have a boolean attribute IsReq to indicate which of these objects is a requirement.

You also have the problem where you presume that a single requirement must exist in a single DOORS object. I think it somewhat reasonable that a 'requirement' can occasionally be composed of more than one object, such as for tables and diagrams.

There is also the problem of fat-fingered mistakes where an object is purged. Now what? You: Recreate a new object and adjust all the Requirement IDs EVERYWHERE in the database and in all Reports. Me: recreate an object and assign its ReqID correctly.

No, ObjID is for reference to the object, not its content.

- Louie
Report this to a Moderator Report this to a Moderator
 21-Sep-2007 17:24
User is offline View Users Profile Print this message


Kevin Murphy

Posts: 206
Joined: 15-Jul-2005

Lou,

I am replying to you not for the purpose of arguing, per se--you're going to believe what you're going to believe and I'm not going to change your mind. Likewise you will not change my mind--but this discussion on such a basic principle will allow those who read it to make more informed decisions about their DOORS setups.

quote:

I didn't say ObjIDs change when you archive-restore, I said that the only way to preserve them between databases is archive-restore, you cannot use export-import. If you had a separate ReqID attribute, then you could export-import.


I misread this, but I still don't understand why it was brought up. If someone exports a spreadsheet and I am to import it into a new database, chances are that spreadsheet has the object identifier in it. Since I am a DOORS admin, chances are I know how to create a module prefix so that I can use the spreadsheet with the identifier as an object ID.

quote:

You also have the problem where you presume that a single requirement must exist in a single DOORS object. I think it somewhat reasonable that a 'requirement' can occasionally be composed of more than one object, such as for tables and diagrams.


By definition, a requirement is a testable statement that stands alone. While tables and figures help illustrate things, it is words and numbers that will be tested. They are supporting information, and if one doesn't want to use a DOORS ID to refer to them, one doesn't have to. However, we can both agree that a naming convention needs to be used (I prefer Object IDs or captions, myself).

quote:

There is also the problem of fat-fingered mistakes where an object is purged. Now what? You: Recreate a new object and adjust all the Requirement IDs EVERYWHERE in the database and in all Reports. Me: recreate an object and assign its ReqID correctly.


Fat fingering a purge? This is very, very unlikely through the DOORS interface. If you're scripting, you have to be careful about purging...but even still, purging is dangerous and I can't imagine this would happen often in most situations.

The Object ID as requirement ID works for DOORS. It is built-in. You can use links to do traceability easily to Object IDs, and export Word documents with the IDs appended to shall statements with a little customization. As a DXL developer and a DOORS user, you know that every object will have an ID. This makes your life easier and is precisely what allows one to do something like, say, an export/import, and have it work every time. Fat finger or create a duplicate of a "requirement ID" attribute, and you just lost your primary key and thus cannot do an import.

-------------------------
Kevin Murphy
http://www.baselinesinc.com
The Requirements Management Experts
Report this to a Moderator Report this to a Moderator
 25-Sep-2007 09:18
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

When I advocated using a specific attribute for numbering requirements I didn't explain that that is generated using a dxl script that ensures the id's increment, are not reused nor duplicated, sets up some other requirement related attributes, and generally avoids most problems.
It can be defeated, but only if you really try.

The major advantage is that a user has to have made a positive decision that the object under discussion is a requirement.

However as always DOORS is a tool, whether you use it to insert nails or screws is your choice.

Certainly the discussion generated has been interesting.

Report this to a Moderator Report this to a Moderator
 29-Jan-2008 14:53
User is offline View Users Profile Print this message


Robbie Longworth

Posts: 31
Joined: 23-Jun-2004

I've just come across the same issue..

We have a requirements module that links into a Test Index module and finally a "Verification" module from which we produce Verification Claims to the customer. These use a pre-defined numbering format like VER-ABC-0001, VER-ABC-0002, VER-ABC-0003 etc. I was demonstrating to a user how to populate this module and created a new object, but exited without saving! D'Oh!

Now our claims go 0001, 0002, 0004.. I'm gonna have to clone the module and tweak any views that use it to use my new one.

I'd agree that the "next out" counter should be the one straight after the previous successfully saved one, since the nature of most companies config systems mean people question missing numbers. I'd say most people (well, Engineers) now understand a Requirement ID doesn't have to be incremental etc. However the documents that are produced further away from the requirements generally are.

Rob
Report this to a Moderator Report this to a Moderator
 30-Jan-2008 01:45
User is offline View Users Profile Print this message


Catherine Darrow

Posts: 5
Joined: 13-Nov-2007

I would think Telelogic would have to increment object numbers, even when you add an object and then close the module without saving, for contention reasons.

Consider the following scenario:

Module m has current absolute number = 100

User A opens a module in shareable edit, and locks a section.
User B opens the same module in shareable edit, and locks another section.

User A adds an object (#101) to section 1.
User B adds an object (#102) to section 2.

User A closes the module without saving.
User B does some work, and then saves the module.

#101 has to go missing. I think it always does, unless DOORS gets smart enough to realize *nobody* saved--and that could get very complicated.


Incidentally, in my experience you're much better using the DOORS identifier as your unique ID if you can get away with it. Managing ID collisions with multiple modules open in shareable edit and so on is not anyone's idea of fun. It's easier just to let DOORS manage it and solve more interesting problems.

That said . . . sometimes you have picky customers or someone who cares about absolute numbers being neat. In those cases, it's not too hard to re-code the functionality in DXL. I've seen modules with a "Next REQID" module attribute and a DXL scripts to "assign & increment REQID". If the user community is disciplined, or if assigning REQIDs is the work of configuration management, this can work okay. But WATCH OUT if that isn't the case--you WILL get collisions!

Edited: 30-Jan-2008 at 01:46 by Catherine Darrow
Report this to a Moderator Report this to a Moderator
 30-Jan-2008 23:35
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

This is a minority opinion. While using the Object Identifier to mean 'Requirement ID' is convenient, its methodologically unsound. For one thing, if the object is accidentally purged then your schema is completely messed up. For another thing, if the text of the requirement is fundamentally changed (perhaps a 'weight' requirement becomes a 'color' requirement) then you are also messed up.

Its harder, but fundamentally better if you manage your requirement IDs explicitely, and you write a linking script that keys off these IDs rather than based on Identifier. That is, your Verification objects will reference some "SysReq_123" ID, and the linking script finds that object in the sys spec and creates the link to it.

As for the AbsNo always incrementing even if you close the module without saving: its also possible that some other object linked to the new object while it was open. If you allow that AbsNo to be reused the next time its open, the link will correctly point to the wrong object, and that's probably worse than letting the link be corrupted in the source module.

- Louie
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 0 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.