AutoNumbering of RequirementId in DOORS

lahines - Fri May 11 08:15:40 EDT 2012
If you want a new number whenever you create a new object, you can use a new object trigger. The following script will insert the next highest index number in the new object. This script can probably be improved, but it works for me.
//NewObjectTriggerCreatesIndexNo

/*Initiates trigger that generates the next higher index number. close and reopen module to stop trigger.
Larry Hines
January 2012
*/

Void Current (Trigger trg)
{
Object o = object (trg)
History hst = null
for hst in o do {}
if (!null hst and hst.type == createObject) {

Module m = current
Skip idxkey = create //create skiplist
int absno = o."Absolute Number" //get absolute number of new object so can return later
string oid = null
int idx count = 0, maxindex = 0, idx = 0, n = 0, t = 0

/**************************************Find highest index number*********************/

for o in m do {
idx = o."Index Number"
oid = identifier (o)
put (idxkey, idx, o)
if (idx > maxindex) {maxindex = idx}
}

/**************************************insert next highest index number*************/
maxindex++
filtering off
gotoObject(absno,m)
o=current
n=o."Index Number"
if (n == 0) {
o."Index Number" = maxindex
}

/***************************Clean up ***********************************************/
delet idxkey
}
}
trigger (module->object->all, sync, 10, current) // Dynamic trigger

PDU - Fri May 11 11:04:54 EDT 2012
First a little remark : use (without space inside {..} )
{code }your code {code }, and use tab 'Preview'

I don't see difference between "Absolute Number" and your "Index Number".
I think this code

for o in m 

do 
{ idx = o.
"Index Number" oid = identifier (o) put (idxkey, idx, o) 

if (idx > maxindex) 
{maxindex = idx
} 
}

lahines - Fri May 11 11:45:40 EDT 2012
The difference is : You can set the Index Number, you cannot set the DOORS absolute number. Of course, you do have to add an "Index Number" attribute in the module. Index number increments (by 1 in this script) from the last index number. Maxnumber++ can be modified to increment by any number. This dxl is driven by initiating a trigger so all "new" objects get an index number and existing numbers are not affected. Using concatenantion, the Index Number can be change to a string value and a prefix added if desired.

llandale - Sat May 12 16:11:02 EDT 2012
Not sure this is a good idea.

I would be inclinded to have a 'string' Attr-DXL, which is displayed in the views you use to create "requirements". That Attr-DXL would:

bool IsReq = whether the obj is a requirement. 

int  iReqNum = obj.
"ReqNumber"   
// int; default is zero 

if     (iReqNum  > zero and !IsReq) then attrDXL value is some error  
// Non-Req has ReqNum elseif(iReqNum  > zero and  IsReq) then attrDXL value is iReqNum 
""  
// Req already has ReqNum elseif(iReqNum <= zero and !IsReq) then attrDXL value is 
"-"         
// Non-Req has no ReqNum elseif(iReqNum <= zero and  IsReq) then        iReqNum = next un-used ReqNum obj.
"ReqNumber" = iReqNum attrDXL value is iReqNum 
"" 

else
{
}   
// all cases covered

• obj.attrDXLName = ((module obj)."Prefix" "")"Req-" iReqNum ""

llandale - Sat May 12 16:19:40 EDT 2012
Oops... "if I have current access to this object then set the ReqNum et tal."

lahines - Fri May 11 11:45:40 EDT 2012
The difference is : You can set the Index Number, you cannot set the DOORS absolute number. Of course, you do have to add an "Index Number" attribute in the module. Index number increments (by 1 in this script) from the last index number. Maxnumber++ can be modified to increment by any number. This dxl is driven by initiating a trigger so all "new" objects get an index number and existing numbers are not affected. Using concatenantion, the Index Number can be change to a string value and a prefix added if desired.

kbmurphy - Sat May 12 22:26:48 EDT 2012
Landale: If multiple people are editing in shareable at the same time, the requirement number is no longer unique. Since DOORS does not update a module in real time in shareable edit, this can't work. Your attrDXL will have to give requirement IDs on open only.

lahines - Mon May 14 06:42:29 EDT 2012
Lots of good points and cautions. I work on an isolated system and need to have a method whereby objects and requirements can be synchronized with a second remote isolated system so we have a common reference for requirement changes. The index number, being a attribute field that can be changed, provides that capability, whereas the absolute number is fixed and is determined by the database. With changes occurring on both databases (additions, deletions, rearrrangement) the absolute numbers are quickly out of sync. Restrictions prevent additions by anyone other than a limited group so have not had the problem with duplicates due to DOORS updates mentioned here.

SystemAdmin - Mon May 14 07:46:56 EDT 2012
lahines wrote - "....I work on an isolated system....objects and requirements can be synchronized with a second remote isolated system...."

In your particular case, is there a concept that one of these two isolated systems is considered to be the Master repository and the central source of version truth? If yes, maybe there is a simpler way to do this.

Or can changes be submitted, approved and executed in either repository and the other must follow? I would find this odd as it seems to be asking for trouble with basic change control practices, but I've been humbled before.

I've worked in classified isolated environments where there is the concept of Master (customer) and Slave (contractor) DOORS databases that need to be kept in synch. The Master of course dictates the UID applied to module objects where the Object Identifiers in the Master is always copied into a modifiable string attribute which I will call "Master UID". The Object Identifier attribute is excluded from Views, only the "Master UID" attribute is visible

The Slave is initiated via restoring an archive of a known baseline of modules (Formal and Link) from the Master. If the slave wants to add new requirements it has to, by virtue of good config management practices, raise the change as a change request on the owners of the Master. If approved, the Master creates the new object, and the assigned UID at the Master is relayed to the owners of the Slave where they also create the new object but manually enter the UID assigned at the Master into the "Master UID" attribute in the Slave.

All change management is controlled at the Master end - deleted objects, modified objects & new objects - and instructions on how to apply approved change are relayed to the Slave end. It worked quite well as there was only one Master, but still required super tight diligence to ensure synchronization.

lahines - Mon May 14 08:01:02 EDT 2012
That is generally how our system works. We use "Index number" in lieu of "Master UID". ASpecs are customer owned and derived specs are contractor owned. Either can initiate changes through a change process, and due diligence keeps them synchronized. Absolute numbers are only used for local reference.

kbmurphy - Sat May 12 22:26:48 EDT 2012
Landale: If multiple people are editing in shareable at the same time, the requirement number is no longer unique. Since DOORS does not update a module in real time in shareable edit, this can't work. Your attrDXL will have to give requirement IDs on open only.

BillTidy - Tue May 15 11:38:30 EDT 2012
The OP has not come back with more exact requirements - I think the replies so far have been overthought. What did the OP ask for or state?

Q1. Can I increment the RequirementIDs automatically in DOORS(?)
A1: Why would you want to? DOORS does this for you automatically - the attribute is 'Absolute Number'.

Constraint1: My Requirements Id is an attribute of type integer.
Answer: This is the type of 'Absolute Number'.

Requirement1: ...this Id should not change in case I insert another Requirement between the two already existing requirements.
Solution1: That is standard DOORS functionality - an 'Absolute Number' is forever.
It appears the OP needs nothing more than standard DOORS functionality.

Bob_Swan - Fri May 18 07:11:48 EDT 2012
Using the Absolute number is great if you are identifying each object, but you need another attribute, with all the safety controls above if you want to identify requirements specifically, and ignore guidance, information and other waffle in the document.

Bob_Swan - Fri May 18 07:11:48 EDT 2012
Using the Absolute number is great if you are identifying each object, but you need another attribute, with all the safety controls above if you want to identify requirements specifically, and ignore guidance, information and other waffle in the document.

llandale - Wed May 16 12:07:44 EDT 2012
I sit corrected.

Odd I forgot that I had this exact situation develop and ended up resolving it by awkwardly keeping the "latest" number in a configFile.

PDU - Tue May 22 01:57:12 EDT 2012
Hi,

a little question: in shareable edit, is it possible use an module attribute to store "latest" number (instead configFile) ?

more generally, how DOORS manage Module Attributes in shareable mode ?

Pierre

SystemAdmin - Tue May 22 05:03:23 EDT 2012
"....how DOORS manage Module Attributes in shareable mode?..."

Even though Shareable Edit mode disconnects the cascading\inheritance of access rights from the module level down into the Object level, Shareable Edit mode overrides the module level access rights with Read only access. This is to avoid potential data contention issues if two users attempt to edit the same module level attribute at the same time.

SystemAdmin - Tue May 22 05:03:23 EDT 2012
"....how DOORS manage Module Attributes in shareable mode?..."

Even though Shareable Edit mode disconnects the cascading\inheritance of access rights from the module level down into the Object level, Shareable Edit mode overrides the module level access rights with Read only access. This is to avoid potential data contention issues if two users attempt to edit the same module level attribute at the same time.