Overwriting requirements in Variant specification

Description
jahennum
Posts: 4
Joined: Tue Dec 01, 2015 8:51 am

Overwriting requirements in Variant specification

Postby jahennum » Mon Dec 07, 2015 8:11 am

When creating a Variant specification, the requirements used in the specification are the original requirements from the master specification. Also, it is of course possible to overwrite separate requirements, but I have experienced the following on two separate occasions: When overwriting a requirement, I change the requirement text (normally the reason I want to overwrite a requirement) and save the document, and upon saving, I get an error message, and the entire work item is gone. Both old text and attributes, as well as new text are completely gone, and the work item is nowhere to be found. In most cases however, this works just fine, and I am able to overwrite, change and save as I expect to be able to. Is this a bug? Have I done something wrong? Since I don't know if I did something wrong, I haven't been able to reproduce it :(

Fortunately, this has only happened during testing so far and not in a production database, but if this is something I can expect, I am a bit reluctant...

NickEntin
Posts: 472
Joined: Tue Oct 24, 2006 10:27 am
Location: Polarion Software GmbH, Stuttgart
Contact:

Re: Overwriting requirements in Variant specification

Postby NickEntin » Wed Dec 16, 2015 1:16 pm

Hi,

I'd recommend you to contact support. In the log files you (or they) should be able to recognize what's happened.
In worst case (whatever defects) - only information from your browser, i.e. not-yet saved data may be lost. Everything, what was sent to the server is versioned and recoverable.

Best regards,
Nick
P.S. If you're using Polarion VARIANTS, probably you didn't get concept of 150% approach. In our methodology, you should not overwrite requirements in the variant specification - you should do it in master (btw, regeneration of variant from Master will fully overwrite all local changes). May be calling our Professional Services or watching some Variant Management webinars might be helpful. Thus you'll understand what's Polarion is capable and how to use features of it to support your particular process.

jahennum
Posts: 4
Joined: Tue Dec 01, 2015 8:51 am

Re: Overwriting requirements in Variant specification

Postby jahennum » Thu Dec 17, 2015 10:03 am

Nick,

Thanks for your reply. This hasn't happened since, so it may have just been a one time glitch due to connection issues or something like that. If it happens again, I'll notify support.

As for the variant requirements, I don't quite follow your recommendation. There are several instances where a rewrite of a requirement is absolutely necessary for a variant. For example, the only difference between two pump variants may be the operational pressure they are qualified for. In this instance, the pressure requirement must be rewritten for the variant only, not the master (as the different variants only differ in the required pressure number). In my view, this is essential in variant control of hardware items. Of course, if it is possible to change the master requirement for all variants, this should be a goal, but in my experience, it is far from always the case.

jahennum
Posts: 4
Joined: Tue Dec 01, 2015 8:51 am

Re: Overwriting requirements in Variant specification

Postby jahennum » Thu Dec 17, 2015 10:20 am

Just a quick example I just thought of, using the Weather Station example project. Here, you can select if your weather station variant is using mains or battery power. These are functional requirements, and are perfectly fine to have as master requirements. Say that most of your products (90% or so) have battery only because you want backup in case of a power outage, meaning that most products have a requirement stating the batteries shall be able to power the weather station for at least 24 hours. This is a performance requirement. A smaller subset (the remaining 10%) of your weather station is however intended for remote locations, and need substantially larger battery capacity, say six months instead of 24 hours. Apart from this, the weather stations are identical. Using six months as the master requirement would make no sense, because almost all your products don't need it, so in my view, using 24 hours would make perfectly sense, changing this to six months for the variant that needs it.

NickEntin
Posts: 472
Joined: Tue Oct 24, 2006 10:27 am
Location: Polarion Software GmbH, Stuttgart
Contact:

Re: Overwriting requirements in Variant specification

Postby NickEntin » Fri Dec 18, 2015 9:23 am

Hi,

Assuming that the mentioned kind of variation happens multiple times for
different reasons in your master requirements, this represents a good
use case for the 150% concept provided in Polarion VARIANTS. A Polarion
Feature Model is used to control selection of requirements from master
documents (requirement supersets / 150% documents / ... ).
A possible repeating variation (10% vs. 90%) may be represented by a
optional feature in the feature model (possibly named ... ). Or two
alternative features if more alternating variations of the same concept
may occur in future.
Connecting the requirements with the feature and configuring the
variants with appropriate feature selections will help you to maintain
all possible requirements in a single set of documents while allowing
variants to differ in their requirements.

Still, I'm not really a VM expert and our colleagues could bring you more arguments on the case...

Best regards,
Nick


Return to “Polarion Application Lifecycle Management (ALM)”

Who is online

Users browsing this forum: Baidu [Spider] and 13 guests