![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
Topic Title: Effectivities and SRD structure Topic Summary: Having trouble managing requirements with multiple releases Created On: 18-Jan-2006 12:41 Status: Post and Reply |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
Hello, We just purchased DOORS 8.0 so we can better manager our SRD and our test Today I think we may have found a flaw in our approach, so I'm writing to 2.1 User Registration I actually had to make *every* object a heading in DOORS to achieve the same But this system is thrown off if the object being changed has children. What Anyway, I think this issue may be driven partly by the structure of our SRD. In the end, I have two basic questions for you guys: (1) Does anybody else use a similar SRD structure? i.e., where requirements Any help is greatly appreciated. Regards, |
|
![]() |
|
![]() |
|
Oh dear!
Don't feel bad Kevin, this is not the first time I have seen this sort of thing and it won't be the last. Restructure your module so that requirements are atomic (one requirement per object) and held in the object text. Make all requirements leaf objects (no children). In fact no text objects should have children because the hierarchy is not apparent to the user. Very dangerous. Use object heading for heading objects only. Use a boolean parameter to denote requirements - this is helpful for distinguishing between requirements and suppoprting information and headings. Using an attribute to filter on releases (effectivities) is a valid approach and will work better once the module has been properly structured. Start using the DOORS unique identifier - paragraph numbers are meaningless, especially if you are using filtered views to produce documents. Best of luck. ------------------------- Tony Goodman http://www.smartdxl.com |
|
![]() |
|
![]() |
|
Our system is set up as Tony describes, but for the comment on leaf objects. |
|
![]() |
|
![]() |
|
I use an enumerated type attribute to define if an object is Heading, Requirement or Context.
Ideally all your text objects should be leaf objects and one of the reasons this looks 'wrong' is because when using Word you write: 2.1.1 The system shall require the following information from all users requesting an account 2.1.1.1 First Name 2.1.1.2 Last Name 2.1.1.3 Valid Email Address The three requrements just need fleshing out into whole sentences. So you end up with a heading of Account Details followed by requirements The system shall require a First Name from all users requesting an account The system shall require a Last Name from all users requesting an account The system shall require a Valid Email Address from all users requesting an account This looks strange because you have repeated a lot of text and it doesn't read well, but you have a database where each requirement has (to a large extent) a life of its own and needs to be complete to make best use of the tools you have available. I also use separate requirements if I have an optional level of service, for example Transactions shall be completed in less than 2 seconds Transactions shall be completed in less than 1.5 seconds I then tag the first one as mandatory and the second as desirable. You could use this for control of increasing functionality between releases, but you might be better to use baselines that way you can still link to the same DOORS Object. (This is what Baseline Sets were intended for, but they don't seem very popular :-)) While we are at it - can I suggest that you NEVER use a DOORS table. Create a hierarchy or use an embedded Excel sheet, or find another way. Hazel |
|
![]() |
|
![]() |
|
Tony, Robert, and Hazel, Thanks for your input, and sorry for taking so long to respond to this thread. We've been discussing this a lot within our group here because it's obviously so central to how we're going to use DOORS. I think we're going to defer the idea of using full effectivities and opt to copy the module over when we need to maintain multiple releases. We did think about using baselines instead of copying the module, but we seem to have too much overlap for that. That is, if we just baseline and move on to the next release, we've lost the ability to make any other changes to that previous release's SRD. Granted, most of them will end up carrying forward to the next release, but that doesn't always seem to be the case. We also decided not to go through with restructuring our SRD right now until we can do more research. The most important thing I gathered was that it seems like, as Hazel said, that we should have fewer levels of headings and be writing requirements so they're more independent of one another. I did want to ask Hazel why he had such a negative reaction to DOORS tables. I've definitely encountered some difficulties trying to use them, but was curious what your thoughts were. Anyway, thanks to you guys for your input. Regards, |
|
![]() |
|
![]() |
|
Having tried every way of dealing with this, I have come up with the following.
The negatives on tables 1. Attributes. Because a table is two dimensional, you lose visibility of the attributes. You can display multiple attributes in a table cell, but then you cannot 'point and click' edit. This is really the biggest useability issue. 2. Filtering. If you exclude non matching table cells, you get cells in isolation, if you include them you get every table included. 3. Linking. You can only link to a single cell, not a row or column. This is very rarely appropriate. Even if this is 'correct', when you include the details in an analysis column from the other module, you get out of context data. If you rearrange things, you get useful information. There are other awkwardnesses to the user interface for tables but those are my top three. There is always a way around it... Tables come in various forms, the common ones are a. performance curve - the whole table is the thing you want to link to, none of it makes sense without the whole - use an Excel OLE b. ________________________ . heading 1. heading 2.data. ................. ________ .data. ................. more h 2 .data. .__________________.data. It makes sense to split this to a hierarchy. The way to spot one of these is by the merged cells in a column. c. each row is a requirement - split them up. Sometimes it is worth presenting them as mini-tables with the heading and one row in an OLE. d. (rarely) each column is a requirement, again split them up e. (never seen one!) each cell is a requirement. f. a *huge* table - put it in a separate module and use attributes. g. a table in a document from the customer that is relatively insignificant to the work you are doing - live with it :-) Hazel |
|
![]() |
|
![]() |
|
Hazel, Thanks for your input. Your negatives about tables line up with what we've been experiencing. We have about 25 appendices, some small and some decently large, at the end of our SRD. Right now they're all DOORS tables, so we're evaluating whether that's the best option. |
|
![]() |
Telelogic DOORS
» General Discussion
»
Effectivities and SRD structure
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.