Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
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
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
Answer This question was answered by Kim Faint, on Wednesday, July 20, 2005 11:17 PM

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
 11-Jul-2005 19:40
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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:

  • More flexibility in filters, traceability and impact analyses. The conditions selected for a filter and/or analysis can look for in-links or out-links that go through specific link module(s). Isolating each relationship in its own module would allow for constructing filters as finely- or coarsely-grained as needed.
  • More flexibility in administration. When restoring a project from an archive, it is possible to selectively restore both formal and link modules. If all or a subset of linksets are grouped in one module, then that would be the resolution for which restoration capability would be available. Thus, if only a few links are corrupted between a specific pair of modules, we believed that everything in the link module would be restored (and wiped out). Instead, isolating a linkset to its own module would provide the restoration flexibility we desired.
  • DOORS® performance would be improved, in that it would only have to load the relevant linksets when opening a formal module.
Whether the perceived advantages of the last two items are really true have not been substantiated, but those were the thoughts that guided the decision.

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:
  • What is your link module philosophy and why? What benefits have you realized from your approach?
  • Are the advantages we outlined in deciding upon our current model even accurate?
  • Do you have a recommendation for us?
Your comments are most appreciated.

Thanks,

Greg
Report this to a Moderator Report this to a Moderator
 12-Jul-2005 02:12
User is offline View Users Profile Print this message


Kim Faint

Posts: 15
Joined: 16-Aug-2004

Answer 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

-------------------------
Kim Faint (kim.faint@boeing.com)
Systems Engineer
Boeing Australia
http://www.boeing.com.au
Report this to a Moderator Report this to a Moderator
 19-Jul-2005 00:02
User is offline View Users Profile Print this message


Keith Collyer

Posts: 6
Joined: 20-May-2002

In my experience there are four general approaches to use of link modules

    One link module per link set

    Advantage: fine grained traceability

    Disadvantage: lots to manage


    Link module per link class, within each originating folder

    Advantage: reasonable granularity of traceability

    Disadvantage: still quite a bit to manage


    Link module per link class, held at project root

    Advantage: easy to manage and easy to trace same class of links through several levels

    Disadvantage: coarse traceability


    One link module

    Advantage: None

    Disadvantage: lots!



-------------------------
--

Cheers

Keith
Report this to a Moderator Report this to a Moderator
 19-Jul-2005 00:02
User is offline View Users Profile Print this message


Keith Collyer

Posts: 6
Joined: 20-May-2002

Hmm, that was supposed to be numbered and bulleted. Hope it still makes sense!

-------------------------
--

Cheers

Keith
Report this to a Moderator Report this to a Moderator
 19-Jul-2005 09:09
User is offline View Users Profile Print this message


Ken Mcguffie

Posts: 63
Joined: 3-Feb-2004

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
Report this to a Moderator Report this to a Moderator
 20-Jul-2005 23:24
User is offline View Users Profile Print this message


Greg Lacefield

Posts: 13
Joined: 23-Oct-2003

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
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 0 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 0 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.