Cameo Requirement numbering vs. ID vs. Organization

I haven't seen this question asked on the legacy Cameo Community forum, or here; I believe it to be a big deal. I appreciate any suggestions. I think the tool needs new options/features/structure to how it handles ID vs. Organization --> they should be separate things.

 

Dassault defines requirement numbering here (for example):

 

Note that the requirement number, is also its ID.

 

Next, note that the Number dictates its location in the structure tree:

 

  1. So what happens when you MOVE a requirement? Answer: The Number changes, Answer: The ID changes.
  2. So what happens when you add a requirement above an existing requirement? Answer: That depends on if you allow it. Generally speaking, you cant (Generally speaking, the new requirement gets the next available number, and in turn, is at the bottom of the structure tree for the parent containment you added it - thus, there is no semblance of structure or order, or organization unless you renumber everything, which is quite a complicated and fussy operation; it's also something you should never be doing???).

 

In DOORS, the object number is not the object absolute number. The ID (Object Identifier) is the module prefix + the absolute number. The object number is an auto-numbered bulleted list like Cameo demonstrates above, and it changes freely, based on its location.

 

Cameo does not allow us to separate these ideas. In fact, cameo forces the "ID" to be the deciding factor in the structure tree organization. Oddly enough, when you import requirements in a spreadsheet, there appears to be no consistent behavior on what ID number gets auto assigned to what requirement.

 

There is a logical order for human readability both in the structure tree, as well as in requirement tables to have the requirements "flow" in a readable (i.e., top down?) order. But - because Cameo treats this number as the ID, it significantly hinders any movement or restructuring of the requirements in these areas; thus creating  a set of requirements that are not organized, or organizable, to the level we use in word docs or other requirement management tools.

 

You get some structure control when you create requirements, one by one, and ordering them in groups (as you typically do anyways) helps as well, but; if you ever want to move one to precede another, you will be struggling forever.

 

As an aside... If you use Datahub to import requirements, and you use the object number as the Cameo ID, and move a requirement in DOORS, you create ID changes in Cameo. If you use the DOORS Object Identifier as the ID, you get consistent numbering that never changes, but a structure that is completely unintelligible.

 

Any suggestions to address both issues in a way that remains separate and expedient to re-order a requirements location within Cameo when needed/desired?