![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Seeking comments on project & module structure Topic Summary: How to split project between modules & folders - best practice Created On: 8-Oct-2007 13:06 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
It has always seemed that the 'right way' of using DOORS is to create a module for every specification, but I wonder if this is necessary. My Technical Director suggested that a single DOORS module could contain sytem, hardware and software requirements using one or more attributes to determine the applicability of each requirement.
If a project has a customer requirement, and a customer facing ICD; and the design process identifies system, hardware and software requirement specifications. It seems the 'right way' is to create a module for each of these 5 'documents'. With a relatively small number of modules there is no obvious reason why these should be put in different folders, although I have heard that recommended. It also seems 'good practice' to create separate link modules to 'connect' related modules. However my TD suggested that a single DOORS module could be used to hold everything below the customer's documents. Clearly this should produce some savings in module maintenance but it sounds like a bad idea to me. One obvious problem is that links would be internal to the module and hence would go through a single link module. I'd be interested to hear reasons why separate specifications are better in separate modules. I don't think a 'that's the way it is always done' would cut it! How do people use folders in DOORS? I've tended to use them for archive material or groups of related documents such as test equipment specifications. A recurrent theme of topics on the forums is that the DOORS documentation can tell you how to do something but rarely why to do it. All advice and comments on the use of modules and folders will be welcomed. TIA ------------------------- Jim Backus<BR>Ultra Electronics, Controls |
|
![]() |
|
![]() |
|
You need a different link module for each KIND of link. Links of the same kind would go in the same link module. If you deal only with requirements then you probably need only one link module, perhaps "Requirement Links". A child source requirement 'satisfies' a linked parent target requirement. If you have System, SubSystem, and Component requirements, they are linked in the same link module. You may be dealing with things other than requirements. CPS uses its own link module 'Change Proposal Links' where a CP 'proposes changing' a requirement. You may also have Test Cases that "tests" the requirements they link to.
A big reason to separate different things into different modules is so you can install leveled change control. The System spec gets 'locked down' and placed in rigorous change control long before the SubSystem spec does. It would be very hard to install such a leveled lock-down if all the requirements were in the same module. Another reason is thats its very difficult to produce the 'Sub System' spec if its requirements are in the same module as the System and Components. Would not the SubSystem spec get its own section 1.0 Scope? Folders are for organizing stuff. If you don't have much stuff then you don't need much organization. I can think of two primary folder hierarchy schemes: [1] the same levels of stuff go in the same folder. That is, all the Sub-System specs go in a Sub-System folder and all the componenent specs go in the Components folder. [2] Folders match the Hierarchy of the specs. There is a "Req Folder" housing the System Spec. It has as many sub-folders as there are Sub-System Specs. Each Sub-System folder has that Sub-System spec and as many sub-folders as that Sub-System has subordinate Components. Notice that each folder tends to have only one module. Notice that in order to find component "C3" you need to know which Sub-Systems its in. With this scheme the "Req Folder" would have some sort of "Test Folder" sibling in which you'd find the "System Tests" test spec; and it would have sub-folders matching the Req sub-folders; one for each Sub-System test spec. - Louie |
|
![]() |
|
![]() |
|
Louie,
You say " You need a different link module for each KIND of link." but don't say why. I was thinking that it would be better to have a link module for every pair of linked modules because it is possible to filter on links going through a particular module but not on a linkset. For example if I have modules m1, m2 and m3 with links from both m2 & m3 going to m1, if there is a link module for links from m2 and another for links from m3 I can use these link modules when filtering in m1. I'm thinking of GUI filtering, not DXL filtering where much more powerful filtering can be done. Your point on levelled change control is good. That's what I was thinking but you've put it elegantly. On organisation, the project I'm working on definitely comes under the "don't have much stuff" category. I'll continue to use folders as before for general organisation. Another question on folders: if a module with links is moved to a different folder, do the links get broken? TIA for any further replies ------------------------- Jim Backus<BR>Ultra Electronics, Controls |
|
![]() |
|
![]() |
|
You suggest each link module contain only one link-set. If you need another link-set then create another link module. That sounds like an excessive propagation of modules. Yes, it does allow you to create filters stored in views to see just the links you care about. With this scheme, the System spec would specifically need to filter for any link from any of the 5 specific SubSystem modules, instead of just filtering for all SubSystem links.
However, I do all my work with DXL and its pretty trivial to filter based on the other module, although you do have generally have to open the other modules to find out its name. (Think that changed in v8.2). Anyway, its a lot more common to want to see all the 'requirements trace' links or all the 'test cases' links then it is to just see some of them. Besides the manual filtering you pointed out, the only real reason to have more than one link module per project is so you can tell which kind of link you are talking about. I've got a vision that objects in one module can have more than one kind of relationship to objects in another module; that is a SubSys requirement may 'Satisfy' a System requirement, but it may also 'Refer' to it for some other reason. If so, you need more than one allowed link-module since a single SubSys object can have two links to a single System req. Anyway, we don't have a solid scheme figured out here yet. - Louie |
|
![]() |
|
![]() |
|
What is going on with this forum?
I know I made 2 posts here, and Lou made a few posts in response and they are now missing. ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
The only response I've seen to my original message was Louie's dated 8th October.
There have been other cases of missing replies. See for example https://support.telelogic.com/en/doors/forums/messageview.cfm?catid=17&threadid=2041 ------------------------- Jim Backus<BR>Ultra Electronics, Controls |
|
![]() |
|
![]() |
|
Kevin says "What is going on with this forum?" ... posts missing...
4pm Wed: Not counting this post, right now I see 6 posts in this thread; 3 by Jim, 2 by me, and this one I'm replying to by Kevin. Perhaps its one's profile user options. I use default 'Topic View:' of 'Threading', which lets me see the thread structure along with the posts themselves. Don't see anything in my profile that will hide my posts nor hide others however. - Louie |
|
![]() |
|
![]() |
|
Maybe I dreamt it Lou...but remember? You didn't like my airport/linkset analogy. That was this thread, no?
If not, maybe I am just working way too much. ![]() ------------------------- Kevin Murphy http://www.baselinesinc.com The Requirements Management Experts |
|
![]() |
|
![]() |
|
No dream. In some thread you directed folks to your blog on your site. I read it and commented on it.
Since I cannot find 'airport' anywhere, it could have been this thread (but I don't recall). I see that Goodman posted such a disappearing-posts on the Feedback forum. - Louie |
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.