Question? What is the correct way for doors trace ability. As I have read the traceability should realize the higher level document, i.e. test should realize requirement. However Grammatically when I assign a link in, it seem to come from an out document and I feel the direction arrow seems to flow incorrectly. I am just reading it wrong or is there a better answer? Ebarnes - Tue Apr 11 05:15:18 EDT 2017 |
Re: Doors Linking Direction and Gramatically Do not care about which direction the links arrows point. The linkage direction in DOORS in usually determined by access rights (because you need modify rights to create a link) or by which object is created after the referred object. In addition if some of your linkage relationships is determined to be in a specific direction, then all the other should be in the same direction, that will help to use the analysis tools. So if your test links go out of Test cases to System requirements, then the links from System requirements to User requirements (and forwards) should follow the same direction: Test cases -> System requirements -> User requirements -> Use cases |
Re: Doors Linking Direction and Gramatically PekkaMakinen - Tue Apr 11 05:27:02 EDT 2017 Do not care about which direction the links arrows point. The linkage direction in DOORS in usually determined by access rights (because you need modify rights to create a link) or by which object is created after the referred object. In addition if some of your linkage relationships is determined to be in a specific direction, then all the other should be in the same direction, that will help to use the analysis tools. So if your test links go out of Test cases to System requirements, then the links from System requirements to User requirements (and forwards) should follow the same direction: Test cases -> System requirements -> User requirements -> Use cases Great Thanks, just needed clarification on it.
|
Re: Doors Linking Direction and Gramatically There's not a correct way but you should care very much about the direction because this will have a fundamental & important impact on your ability to analyze the links (and why else would you need traceability if you are not going to analyze it?) The key is to have a CONSISTENT linking schema in your database for all projects.
|
Re: Doors Linking Direction and Gramatically I usually see responses to this topic along the lines that "It doesn't matter" or "We do it this way because it seems to work better", etc. However, I believe that there is always a "correct" way, but it depends totally on the applications that the database is intended to support. Since the most common type of application is a hierarchical, top down dependency (e.g., a requirements document is assumed to be "above" a design document), the relationships that PekkaMakinen gave are the norm. DB applications proving both completeness and compliance will use this structure.
However, not all modules are hierarchical. Some may be peers. For example, a new alternate product may be documented by duplicating the original product's requirement spec module and, in addition to the out-going links to the higher level source module, you have both in and out links between the two peer modules for tracking things such as history and delta occurrences between them.
The "direction" of a link (i.e., the source to target direction) should be based on the type of dependency of the relationship between the two objects. For example, the "implements" relationship between a design choice object and a requirement object is dependent on the requirement object. Therefore the requirement object would be the target and all design choice objects in a design spec would be the sources. The direction arrow would go from source to target. Note that DOORS has been set up with defaults so that the person creating an object that is dependent on a second object also has access control over the link that he creates to show his object's dependency on the second object. This has the nice effect that it allows the person who actually decided upon the dependency to document that decision (i.e., as a link).
The dependancies between objects is determined by the application of the DB. I.e., what kind of inspection and analyses the DB is to provide for. For some applications, Module A may be dependent on Module B, but in other cases Module B might be dependent on Module A. In these cases it might be necessary to have two separate link sets running between the same two modules. DOORS allows for this (although it has not been implemented in a very stable fashion in past iterations of the tool).
A link set is equivalent to an associative object (i.e., a relationship) in an Entity/Relationship model and it should have the same direction as that needed in the model to support the needed application.
Again, the hierarchical dependencies of the requirement flow down type model are far more common. These other situations can occur though, and when they are misinterpreted (i.e. the relationships are represented by links that are not well defined) difficulties can arise further down the line.
|