![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Link module philosophy Topic Summary: What is the best philosophy for setting up link modules? Created On: 11-Jul-2005 19:40 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: Hi Greg, We use a model that is a combination of the two that you have described here. While we establish link modules based on the class of links we also break them up according to the folder structure of the database and the users that will require access to those links. For example in the root directory of a project, our system level specification has an InheritedFrom link module that we use to link from the system specification (SysSpec) requirements to the contract requirements (ConSpec) that they inherit from. However in this same folder we also have a number of segment specifications (SegSpec). Each SegSpec uses the same InheritedFrom link module to link from the segment requirements to the SysSpec requirements that they inherit from. In this top level folder we also have modules which represent our system level design (SysDesgn) which use a DesignCoverage link module to link from elements of the design to the requirements that piece of design satisfies. Then each SegSpec uses a separate DerrivedFrom link module to link from derived segment requirements to the elements of the design from which they have been derived. All of these modules are contained within the one top-level folder (or root directory of a project) because the team that uses all of these modules and links is the same team (the system level systems engineers). So it makes it easy to manage the permissions in that edit access is only allocated to this folder for this group of people only and each module inherits it access from this folder. Likewise at the next level down we have a number of independent subsystem teams which each have their own subsystem folder and within it a subsystem specification (SubSysSpec), subsystem IRS and subsystem design documents as well as a InheritedFrom link module to link from the SubSysSpec requirements to the parent SegSpec requirements and a DerrivedFrom link module to link from the SubSysSpec and the IRS to the segment level design in the top-level folder. This scheme then continues to scale as the system is further broken down to lower component levels etc. I think the benefit of this scheme is that is does scale in that each workgroup can manage their link modules themselves. However the disadvantage may be that it is not as flexible to change in either the system breakdown or the organisational structure of the workgroups and teams as perhaps your scheme is. This is definitely one of those fuzzy areas where there doesn’t appear to a right or wrong answer and no matter which scheme you choose at the beginning of a project you will come back to question it and probably change it multiple times as you progress. Regards, Kim | |
![]() |
|
Hello,
Like most of you, we have created modules that each trace to a number of higher-level modules. Two years ago, we initially chose to establish a policy whereby each linking relationship between two modules would be in a single direction (always many-to-many), and all links which define that relationship would be contained in a single linkset. One link module would exist for each linkset, and would contain only that linkset, i.e.. there would be a 1:1 relationship between number link modules and number of linksets. While this policy has since lead to a proliferation of link modules, at the time we based this philosophy on what we perceived were the following advantages:
However, our links had always been intended to only satisfy traceability. In the two years since that decision, we have recognized a need for other types of links, e.g., links to useful references that do not necessarily satisfy higher-level requirements. We would not want these to clutter our existing linksets because there would be no automated way to sort them out post-creation. But the thought of creating and administering another set of link modules for each type of link has made us realize that our original philosophy does not scale well. We have noticed that other DOORS users establish link modules based on the class of the links it contains, e.g., Satisfies requirement; References information; etc. Each link module then contains any number of linksets. This obviously scales much better in terms of administration, and we are considering migrating the thousands of links we currently have over to this model. However, our perceived benefits disappear with this arrangement, so we'd like to hear views for and against this before we make a decision. My questions to the DOORS community are these:
Thanks, Greg |
|
![]() |
|
![]() |
|
Hi Greg,
We use a model that is a combination of the two that you have described here. While we establish link modules based on the class of links we also break them up according to the folder structure of the database and the users that will require access to those links. For example in the root directory of a project, our system level specification has an InheritedFrom link module that we use to link from the system specification (SysSpec) requirements to the contract requirements (ConSpec) that they inherit from. However in this same folder we also have a number of segment specifications (SegSpec). Each SegSpec uses the same InheritedFrom link module to link from the segment requirements to the SysSpec requirements that they inherit from. In this top level folder we also have modules which represent our system level design (SysDesgn) which use a DesignCoverage link module to link from elements of the design to the requirements that piece of design satisfies. Then each SegSpec uses a separate DerrivedFrom link module to link from derived segment requirements to the elements of the design from which they have been derived. All of these modules are contained within the one top-level folder (or root directory of a project) because the team that uses all of these modules and links is the same team (the system level systems engineers). So it makes it easy to manage the permissions in that edit access is only allocated to this folder for this group of people only and each module inherits it access from this folder. Likewise at the next level down we have a number of independent subsystem teams which each have their own subsystem folder and within it a subsystem specification (SubSysSpec), subsystem IRS and subsystem design documents as well as a InheritedFrom link module to link from the SubSysSpec requirements to the parent SegSpec requirements and a DerrivedFrom link module to link from the SubSysSpec and the IRS to the segment level design in the top-level folder. This scheme then continues to scale as the system is further broken down to lower component levels etc. I think the benefit of this scheme is that is does scale in that each workgroup can manage their link modules themselves. However the disadvantage may be that it is not as flexible to change in either the system breakdown or the organisational structure of the workgroups and teams as perhaps your scheme is. This is definitely one of those fuzzy areas where there doesn’t appear to a right or wrong answer and no matter which scheme you choose at the beginning of a project you will come back to question it and probably change it multiple times as you progress. Regards, Kim ------------------------- Kim Faint (kim.faint@boeing.com) Systems Engineer Boeing Australia http://www.boeing.com.au |
|
![]() |
|
![]() |
|
In my experience there are four general approaches to use of link modules
------------------------- -- Cheers Keith |
|
![]() |
|
![]() |
|
Hmm, that was supposed to be numbered and bulleted. Hope it still makes sense!
------------------------- -- Cheers Keith |
|
![]() |
|
![]() |
|
Another consideration may be partitions.
I've not tried this out myself but it would seem likely if two requirement modules and a link module were to be partitioned out so links could be worked on between the two modules in an away database - if there was a single link module (Link module per link class, held at project root ) for requirement links, then links could not be worked on between other requirement modules in the home database as the link module would be locked. Ken McGuffie Harrier Avionics BAE S Edited: 19-Jul-2005 at 09:11 by Ken Mcguffie |
|
![]() |
|
![]() |
|
Thanks to everyone for your responses. Based on your inputs, we're leaning toward the class-based approach now, although we're still deciding on whether to put the classes only at the project root, or at the individual workgroup level. One advantage that we've identified to placing them at the project root is that the Analysis Wizard can be used to analyze, e.g., full top-down traceability (and only traceability). This is not possible with multiple Satisfies modules spread throughout the workgroups, because only one link module can be specified in the AW.
Regards, Greg |
|
![]() |
Telelogic DOORS
» General Discussion
»
Link module philosophy
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.