Hello Everyone,
I am working on a project where we have a list of requirements which can be belong to variant1 or/and variant2 or/and variant3, ... The difficulty is that for each variant, there are a set of specific attributes, this means variant1 can have attr1 and attr2 which variant2 doesn't have. The second difficulty is that different teams work on every variant and allowing all teams to work parallely is required, this brought to my brain the idea of having every variant in a separate module but then got blocked at the point where variant share exactly the same list of requirement and if a Req N° XXX is changed in the Customer Requirement Module is should be applied to all the Variant Modules.
Can you guys help me to structure this variant management project based on your experience ?
Solution 1: Customer Requirement Module Req ID | Req Text | Variant | Attr1 - Variant1 | Attr2 - Variant2 | Attr3 - Variant2 | Attr4 - Variant2 1 | Abc | 1 - 2 -3 | ...... | ....... | ....... | ....... 2 | Bcd | 2 - 3 | ...... | ....... | ....... | ....... 3 | Cde | 1 -2 | ...... | ....... | ....... | ....... .. | .......... ..... | 1-3 | ...... | ....... | ....... | .......
Is there a way to split such module based on the variant name, probably a DXL script or something ? inorder to allow the different teams to work simultaneously.
Thank you for your feed back. YassinBen - Mon Jun 12 08:32:44 EDT 2017 |
Re: Managing Doors Requirement variants 2 thoughts, 1 - have you considered using DOORS next generation? if this is an option I'd look into it as it was built with variant management in mind. If you are in DOORS I'd recommend using spreadsheets, and export data out.. for teams to work and import back in. You can certainly use shareable edit to ensure people can work in the same module at the same time. This won't help with ability to edit multiple attributes on the same object, but you can get around this with the spreadsheets. |
Re: Managing Doors Requirement variants DOORSWizard - Thu Jun 15 11:26:55 EDT 2017 2 thoughts, 1 - have you considered using DOORS next generation? if this is an option I'd look into it as it was built with variant management in mind. If you are in DOORS I'd recommend using spreadsheets, and export data out.. for teams to work and import back in. You can certainly use shareable edit to ensure people can work in the same module at the same time. This won't help with ability to edit multiple attributes on the same object, but you can get around this with the spreadsheets. Thank you for your answer, Unfortunately, Doors next generation is not an option but good to know that it is built with variant management in mind. I thought shareable edit works only when the section is locked ? this means the object in one section can not be edited simultaneously by different user. Can you correct me if I am wrong ? |
Re: Managing Doors Requirement variants Yes you are correct only 1 person can be editing an object at once, thus my suggestion to use spreadsheet export/import to allow for multiple people to work on the same object at once. Another option is to use the built in change proposal system, a bit more formal but this would allow multiple people to propose changes against the same requirement. And you as the DOORS manager couple apply the 'approved' changes all at once making changes to all the attributes. I'd say it might be too much for the development of a spec but none the less something you can try. |
Re: Managing Doors Requirement variants Hi. I am encountering a similar issue. At the System level there may be variants for each component of the system. It is not practical to either have a column for each type of variant, or have a single column with any possible variant. I was thinking as a solution to split the System module in a way that each component has a separate module, but they would all be conceptually under the same level (System). Then, in each component-module I can create a single "Variant" column with only the relevant values. As a positive side-effect, this would make reusability of System-elements more straightforward conceptually and probably also in a practical way.
However I am not sure that such a structure would be acceptable at the System Requirements level. Most often, the System Requirements are all included in a single DOORS module. Has anyone experienced a project where such a split structure was implemented? |