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: 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
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.
 18-Jan-2006 12:41
User is offline View Users Profile Print this message


Kevin James

Posts: 32
Joined: 12-Dec-2005

Hello,

We just purchased DOORS 8.0 so we can better manager our SRD and our test
cases.  We currently have our SRD in a Microsoft Word document (~3500
requirements) and have migrated those to a DOORS module.  One of the things we
wanted to do when getting DOORS was to setup effectivities so we could
effectively manage the overlap between releases without having to keep
multiple copies of the document (or module, now).  We currently have our new
SRD module setup with a multiselect, enumerated effectivity column for our
releases.  We have views that filter the module for each release.

Today I think we may have found a flaw in our approach, so I'm writing to
solicit input from the community about how we could fix it.  Our SRD seems to
be structured a little bit differently from the functional requirements in the
training database.  Our SRD does not have a clear distinction between headings
and requirements -- i.e., we have a tree structure, but each object is a
requirement and can have children.  For example, we might have the following
structure in our SRD:

2.1 User Registration
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
2.1.1.3.1 The system shall require the user to enter the email address twice when requesting an account.
2.1.1.3.2 The system shall validate that the email addresses are the same.
2.1.1.4 Telelphone
2.1.1.5 Username
...

I actually had to make *every* object a heading in DOORS to achieve the same
appearance that we have in our SRD.  That aside though, where this causes a
big problem is with effectivities.  The way we've setup our process, if a
requirement changes from one release to the next, a new requirement is
inserted after it.  The original requirement's effectivity attribute should
only be checked for the releases where the old value still applies.  The new
requirement should only be checked for the new release in which the change was
made (and for any subsequent releases, of course).  For example, a requirement
changes between release 1.4 and 1.5, so the old one is checked for 1.1-1.4 and
the new one only for 1.5.

But this system is thrown off if the object being changed has children.  What
happens to the subtree under that object?  A copy of the object has been made
to indicate that there are actually two different versions of it, with each
copy applying to different releases.  But that subtree cannot have both
objects as parents, and we certainly don't want to copy the entire subtree.

Anyway, I think this issue may be driven partly by the structure of our SRD. 
Looking in the training database for DOORS, there is a clear distinction
between headings and requirements.  That is, headings are headings and
requirements are leaf objects.  If we had real headings and requirements as
leaves, then the requirements could use effectivities to manage versions
across releases without running into this subtree problem.

In the end, I have two basic questions for you guys:

(1) Does anybody else use a similar SRD structure?  i.e., where requirements
can have children, so headings are not clearly defined?
(2) Is this how most people manage effectivities, or there is a simpler
approach that we are missing?

Any help is greatly appreciated.

Regards,
Kevin

Report this to a Moderator Report this to a Moderator
 18-Jan-2006 14:34
User is offline View Users Profile Print this message


Tony Goodman

Posts: 1098
Joined: 12-Sep-2002

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
Report this to a Moderator Report this to a Moderator
 19-Jan-2006 09:00
User is offline View Users Profile Print this message


Robert Swan

Posts: 86
Joined: 14-Apr-2005

Our system is set up as Tony describes, but for the comment on leaf objects.

We have requirements as root objects only, with its leaves used for explanatory text and comments.
The requirement attribute tag propagates to those leaves so the full detail can be viewed by filter ifd required.
A second attribute holds a requirement identification number, which allows filtering to only see the requirement statement.

Report this to a Moderator Report this to a Moderator
 19-Jan-2006 11:15
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 78
Joined: 6-May-2005

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
Report this to a Moderator Report this to a Moderator
 24-Feb-2006 01:57
User is offline View Users Profile Print this message


Kevin James

Posts: 32
Joined: 12-Dec-2005

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,
Kevin

Report this to a Moderator Report this to a Moderator
 27-Feb-2006 15:59
User is offline View Users Profile Print this message


Hazel Woodcock

Posts: 78
Joined: 6-May-2005

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
Report this to a Moderator Report this to a Moderator
 1-Mar-2006 01:32
User is offline View Users Profile Print this message


Kevin James

Posts: 32
Joined: 12-Dec-2005

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.

On the filtering issue, I did try to use triggers as a means of dealing with tables in their entirety.  That is, if something in the cell matched the filter, the whole table would show.  Otherwise the whole table would be absent.  This requires a hidden attribute that is set by the trigger for all cells in the table whenever a particular attribute is set within one cell.  This got complicated quickly, plus it's limited to filtering on that attribute.  I bagged that idea, so we just have cells in isolation right now when people filter.

We'll keep investigating, but at least we know we're not missing something obvious here.

Thanks,
Kevin

Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 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 1 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.