![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() |
|
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? |
|
![]() |
|
![]() |
|
No, you would not use the same absolute number within the same module.
------------------------- pete.kowalski(at)motorola.com |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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:
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
quote: 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: Agreed, but isn't that what most people do? quote: 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: 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: 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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 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: 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: 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 |
|
![]() |
|
![]() |
|
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. |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
Telelogic DOORS
» General Discussion
»
Absolute Number Usage
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.