Copy Requirement diagram incrementing autocounters

[jepessen]

I've the situation that you can see in the bottom image.

I've a package named CIGI 3.1 with some Requirements Diagram and many requirements in it. These requirements have an auto-counter set.
I have to create a new CIGI 3.2 requirement package that's almost equal to this one (only a few of them change). In order to avoid to re-create all these requirements, I want to clone this package and then modify the cloned one.
In order to clone it, I'd like a programmatic way to do following things:

• Copy every requirement in the new package incrementing the autocounter. I.e. "RQ-0126: CIGI 3.1 etc etc." will be copied in a new requirement "RQ-0255: CIGI 3.1 etc etc" (the number of the requirement must be the next available, like adding a new requirement normally).
• After cloning, in the new package replace "3.1" with "3.2" in every requirement (both requirement title and note).

I don't want that you make all the work, but I don't know almost anything about scripting, so any help will be really appreciated.

[qwerty]

I stumbled over "clone requirements". What's that? Since when should one clone requirements? Each requirements needs to be unique. What's the point in telling "The system must be able to do A" twice?

q.

[jepessen]

We have to implement this library that allows to send and receive message using CIGI protocol. There are different version of this protocol (3.1, 3.2 and so on) and for every version we must test the sending and the receiving for every packet, even if they are equal in two versions. One requirement if for version 3.1 of the protocol, the other one for version 3.2, so even if the message is the same the requirement is different.

[Eve]

Version 13 has a function to copy a package as a new version. It won't update the version string embedded into the name but it could still be of some use.

In another thread I posted how to use a shape script to emulate a standard requirement notation. If you wanted to use that, you could remove the versions from the name and directly print the version and an auto-number alias.

Code: [Select]

shape main
{
layouttype="border";

rectangle(0,0,100,100);
addsubshape("statusbar", "W");
addsubshape("namecompartment", "CENTER");

shape statusbar
{
preferredwidth=12;
SetFillColor(GetStatusColor());
rectangle(0,0,100,100);
SetFillColor(GetUserFillColor());
rectangle(80,0,100,100);
}

shape namecompartment
{
if(HasProperty("alias", ""))
println("#VERSION# - #NAME#");
else
println("#ALIAS# - #VERSION# - #NAME#");
}
}
You could then use the clone package feature to copy the structure. I would then replace the top level requirement and any child-requirements that have changed for the new version. It would then be easy to see what will need to be changed to support the new version.

[qwerty]

Still, that does not sound logically. A requirement "Must stick to A for Vx" and also have "Must stick to A for Vy" makes no sense. This should rather be "Must stick to A" and a constraint "Vx applies for release m" and "Vy applies to n". The requirements need to be reduced to the basic which is the common "A". Just my 2 cent.

q.

[jepessen]

I agree but unfortunately I'm not the one that decides what to do for these ones. They are old requirements that I'm recreating inside the EA project.

[qwerty]

Oh, I smell that. When it comes to requirements, companies outsource the work to where it's done cheapest. And that's the outcome then. I feel with you. But also: I can't help you :-/

q.

[Guillaume]

Hi,
I'm leaving the EA13 "time aware modeling" Cloning feature aside.
The fact that you use references in the requirements name make it a bit more difficult to run a bulk update. I'd recommend using a separate field like Alias to store requirements references.

Have you tried to export the requirements to Excel, rename all titles, and import in EA?

Guillaume

[jepessen]

No, I'll try to export them... Thanks for the suggestion.