![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Defect: Serious linking limitation Topic Summary: Created On: 8-Nov-2004 09:58 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: I am going a bit off topic here, but it is generally good practice to create and then soft delete a "DOORS Links" link module in every folder of your project. This prevents creation of links in the DOORS Links module. | |
![]() |
|
Ref: DOORS 7/7.1
I am trying to setup relationships between documents that the DOORS documentation says are possible, but DOORS will not let me do it. In the DOORS help section: Using Links/Understanding Link modules and Linksets/Why Use Other Link modules, there is a diagram showing two formal modules using more than one link module to establish types of relationship between the modules. However when I try to establish more than one relationship between the two same modules, DOORS throws an error: "Unable to add linkset pairing: Source/target pairing already present" Our company was sold DOORS citing this capability as one of DOORS' virtues, which is backed up by the documentation and the DOORS consultancy expertise. Telelogic support has responded to this issue suggesting that it is a documentation issue and not a fault with DOORS. I find this completely unacceptable and incorrect. The problem seems to lie in the fact that DOORS is checking for Source/Target module pairing, when it should actually be checking for Link/Target module pairing before throwing an error. Regards Ian Kirwan MG Rover Group ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group Edited: 8-Nov-2004 at 10:34 by Ian Kirwan |
|
![]() |
|
![]() |
|
The diagram in the doors help is wrong. You can only have one relationships between any two modules in each direction.
This makes sense, otherwise the user would have to select which link module to use every time he wanted to create a link. The default linkset pairings would become redundant, and doors would not automatically know which type of link to create. Try to think of your doors data model in terms of an entity relationship model. Each module is an entity (or part of an entity), but never two entities combined, which is what might be suggested by having more than one relationship. There are ways to mark links as being different, while still using the same link module. You can add an attribute to the link itself to contain qualitative information such as a justification or explanation for the existence of the link. You can add an intermediate object between the source and target objects which contains this additional information. Either way, there is an overhead for the user when creating links unless you modify doors to handle this extra complexity in the background. The scenario for creating a link is: 1. select source object. 2. go to target and select "make link" 3. enter your justification and hit OK This is not possible with standard doors features, so customisations or different work-flows are required. ------------------------- Tony Goodman http://www.smartdxl.com Edited: 9-Nov-2004 at 08:27 by Tony Goodman |
|
![]() |
|
![]() |
|
Thanks Tony,
I understand the entity relationship concept, however I beleive this a very restrictive way of using links. If you now forget the idea of entity relationships and ask the question "what do I want my link to mean?" then you have a valid reason to allow multiple relationships. For instance If I have a feature list for a product, I could make links between features which are tied i.e. one cant exist without the other. Also I could make links that show exclusivity i.e. features that can exist in mutual exlusion only. Both links are equally valid to make in this type requirements specification. I would then be able to analyse against the link type. The issue of how DOORS knows what type of link to make could be solved very easily by a popup dialog during the process of making the link. Regards Ian PS Is High Integrity Solutions part of the Altran Group? ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group Edited: 9-Nov-2004 at 09:56 by Ian Kirwan |
|
![]() |
|
![]() |
|
Ian,
The diagram isn't wrong...notice that there is no mention of linkset pairings in the section containing the diagram. There's nothing stopping you creating links using two link modules. The only thing that is prevented is the definition of 2 linkset pairings between the same 2 modules. I think that a popup in the case of multiple linkset pairing is a good enhancement idea, but you probably need a workaround for the time being. You could create a linkset pairing for what is considered to be the main relationship between the modules. This would then be supported by drag and drop linking. Don't specify this linkset pairing as "mandatory". If a different relationship is to be used, then the "Create Links" dialog may be used to specify a different link module. The drawback is that you cannot then specify "Only allow outgoing links as specified in the above list" for the source module, so you can't "lock" the linking schema down. It is then possible for users to create outgoing links to modules they aren't meant to. Antonio. |
|
![]() |
|
![]() |
|
Okay, the diagram is not wrong. But it is a little misleading.
Ian, you might want to look at Jeremy Dick's Rich Traceability. See Requirements Engineering by Hull, Jackson and Dick. This addresses a lot of the issues you have mentioned. High Integrity Solutions is not part of any group. Our website is http:\\www.hisltd.com ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Hi Antonio,
Yes you are right that the schema would not be locked if there were more than one type of link, because it allows the user some options in choosing the link type. However this does not mean that a DOORS schema could not be enforced as it is today. What it does mean is that the schema designer can provide the user with options if that suits the scheme. The designer decides the degree of enforcement. Perhaps this is considered bad in requirements management. I cant say I know. Regards Ian Kirwan ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group Edited: 9-Nov-2004 at 13:39 by Ian Kirwan |
|
![]() |
|
![]() |
|
Hi Tony,
Yes you might be right. A text on traceability might provide some answers. I will see what the budget is doing ![]() Many thanks Ian ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group |
|
![]() |
|
![]() |
|
Ian, I don't think that giving the user the choice is necessarily a bad thing. In fact some RE processes can be too constraining. What we must aim to do is make using the tool as easy as possible so the requirements engineer can concentrate on his requirements rather than how to manage and link them.
Best of luck. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
What really bugs me is that the "Mandatory" and "Overridable" flags are quite useless in practice.
If you tick "Overridable" and then do a drag-and-drop link, it will create a link in the "DOORS Links" module. The manual states "When a user has not defined their own default link module, information about their links will be stored in the module specified in the linkset pairing". However, I have not been able set the default link module (Tools->Options->Setting in DOORS Explorer) to undefined...it always defaults to "DOORS Links". If you untick "Mandatory" and then tick "Only allow outgoing links..." you cannot create a link between the two modules using a different link module using "Create Links". But I though I said that the pairing was not mandatory? I still haven't found a use for these flags... |
|
![]() |
|
![]() |
|
The mandatory/Overridable thing is a bit of a paradox to me also.
If you didnt want to save the link info in the specified link module, then wy do have to specify the link module? ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group |
|
![]() |
|
![]() |
|
I am going a bit off topic here, but it is generally good practice to create and then soft delete a "DOORS Links" link module in every folder of your project. This prevents creation of links in the DOORS Links module.
------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Hi Tony,
Yes I am aware of this. It is however only if you want to enforce a linking schema that you do this. Also you have to be sure that the module you create and delete is the same as the DOORS default links module name, which is set by the administrator. It comes out of the box set as DOORS Links, but can be changed. For what reason I dont know....it is a rather pointless excercise. PS I'm pretty sure I have met Jeremy Dick. Regards Ian ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group Edited: 10-Nov-2004 at 09:09 by Ian Kirwan |
|
![]() |
|
![]() |
|
Hi All,
Somebody from Oxford (Telelogic no doubt) has sent me a copy of 'Requirements Engineering', which arrived today. Thanks very much whoever you are. I guess you are hoping this might shut me up ![]() Many thanks Ian ------------------------- Principle Software Engineer Electrical Engineering Product Development MG Rover Group Edited: 10-Nov-2004 at 14:17 by Ian Kirwan |
|
![]() |
Telelogic DOORS
» Defect/Issue Tracking
»
Defect: Serious linking limitation
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.