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: Creating an RVVM view
Topic Summary: Need to create RVVM view on User Requirements with one test per line
Created On: 9-Jan-2007 14:25
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 Louie Landale, on Wednesday, February 14, 2007 5:24 PM

Answer:
So you want your Layout DXL to only report a found object only once. Here's an outline for that:

Skip skpObjs = create() // Desired Objects to Report; KEY and DATA are both 'Object'
// [0] Open source modules
Open all modules that have this object as a target of a link

// [1] find objects to report:
for lnk in obj <- "*" do
{ Ignore this link if it isn't the right type
Retreive the oSource from the link
put(skpObjs, oSource, oSource) // Ignore put error; which can only mean a duplicated oSource
Is there recusion here?
}
// [2] report found objects:
Buffer bufResults = create()
EOL = ""
for oSource in skpObjs do
{ Accumulate summary of oSource in bufResults
bufResults += EOL
EOL = "\n" // get ready for the next reported object, if any
}
displayRich bufResults

delete(bufResults)
delete(skpObjs)

- Louie
 9-Jan-2007 14:25
User is offline View Users Profile Print this message


Stuart Bruff

Posts: 4
Joined: 9-Jan-2007

I'm just starting to use DOORS with TREK for managing our IVV data.  We have a User Requirement specification that maps down through a SSS (design document) to a number of PIDS (product specs) and the associated IVV modules (SSS, PIDS)..

Our customer expects us to produce the validation evidence in the form of a Requirement Verification and Validation Matrix (RVVM), which gives the validation tests associated with each requirement.  A complication is that each row can represent at most one (possibly composite) test.  For example, if we validate a requirement by analysis (for the whole problem) and demonstration (for specific examples), then the RVVM must contain 2 rows.

I couldn't find anything obvious within either the existing views or dxl scripts that would allow me to do this.  I've created a dxl script that will allow me to pull up all of the tests to a single 'cell', but I now need to split the cell to separate out the individual tests and remove duplicates.  I think that I need to run a regexp on the cell and create new objects.  As for duplicates, I'm not sure whether it is better to remove them once the cell is split, during the process or even in my existing script (by making use of a skiplist).

However, before I spend time doing this (and having just discovered this forum, I was wondering if a capability already exists within DOORS that I simply haven't found yet, or whether anybody could point me in the direction of some useful scripts that might help.

Thank you.

Stuart Bruff
Report this to a Moderator Report this to a Moderator
 10-Jan-2007 00:24
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

DOORS isn't a relational database where you can associate a new many-to-one relation to an existing relation. DOORS is bunch of big spread sheets that allow you to link between any to spread sheet rows.

I don't quite understand what you are getting at, but am pretty sure you will need some sort of 'Verification Item' module that has a row for each individual test. One attribute in that module would of course be the Requirement ID (or Obj Identifier) or the requirment and another showing the Text of the requirement. Using the example in your 2nd paragraph, there would be two rows in this module for that requirement, one for Analysis and another for Demonstration. You would link these two rows to the requirement.

- Louie
Report this to a Moderator Report this to a Moderator
 10-Jan-2007 16:58
User is offline View Users Profile Print this message


Stuart Bruff

Posts: 4
Joined: 9-Jan-2007

quote:

Originally posted by: Louie Landale
DOORS isn't a relational database where you can associate a new many-to-one relation to an existing relation. DOORS is bunch of big spread sheets that allow you to link between any to spread sheet rows. I don't quite understand what you are getting at, but am pretty sure you will need some sort of 'Verification Item' module that has a row for each individual test. One attribute in that module would of course be the Requirement ID (or Obj Identifier) or the requirment and another showing the Text of the requirement. Using the example in your 2nd paragraph, there would be two rows in this module for that requirement, one for Analysis and another for Demonstration. You would link these two rows to the requirement. - Louie


Thank you for your reply.

To clarify, each object of an IVV Module contains a test object.  The test may cover one or more product requirements.  The IVV object will not normally contain a reference to a product requirement, but instead we use a linkset to manually connect product requirements to tests.  

We also have a design module, with its own IVV Module, that links to the multiple product requirement modules. In turn, the design module links to the system requirements module, which also has an IVV module.  (as an added complication, one equipment links straight to the system module)

I've created a view that looks down from the system requirement module, to find all IVV tests associated with that system requirement. 

My problem is that I end up with a a dxl layout cell that could show multiple tests from each of the product modules, the design module and the system module, including (at the moment) some duplicates where more than one path exists through the design module to a product requirement.

What I would like to do it automate the process of removing duplicates and creating a separate line for each system requirement - test mapping.

Thanks,

Stuart Bruff
Report this to a Moderator Report this to a Moderator
 10-Jan-2007 23:48
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Answer Answer
So you want your Layout DXL to only report a found object only once. Here's an outline for that:

Skip skpObjs = create() // Desired Objects to Report; KEY and DATA are both 'Object'
// [0] Open source modules
Open all modules that have this object as a target of a link

// [1] find objects to report:
for lnk in obj <- "*" do
{ Ignore this link if it isn't the right type
Retreive the oSource from the link
put(skpObjs, oSource, oSource) // Ignore put error; which can only mean a duplicated oSource
Is there recusion here?
}
// [2] report found objects:
Buffer bufResults = create()
EOL = ""
for oSource in skpObjs do
{ Accumulate summary of oSource in bufResults
bufResults += EOL
EOL = "\n" // get ready for the next reported object, if any
}
displayRich bufResults

delete(bufResults)
delete(skpObjs)

- Louie
Report this to a Moderator Report this to a Moderator
 14-Feb-2007 17:32
User is offline View Users Profile Print this message


Stuart Bruff

Posts: 4
Joined: 9-Jan-2007

quote:

Originally posted by: Louie Landale
So you want your Layout DXL to only report a found object only once. Here's an outline for that: Skip skpObjs = create() // Desired Objects to Report; KEY and DATA are both 'Object' // [0] Open source modules Open all modules that have this object as a target of a link // [1] find objects to report: for lnk in obj <- "*" do { Ignore this link if it isn't the right type Retreive the oSource from the link put(skpObjs, oSource, oSource) // Ignore put error; which can only mean a duplicated oSource Is there recusion here? } // [2] report found objects: Buffer bufResults = create() EOL = "" for oSource in skpObjs do { Accumulate summary of oSource in bufResults bufResults += EOL EOL = "\n" // get ready for the next reported object, if any } displayRich bufResults delete(bufResults) delete(skpObjs) - Louie


Sorry about the delay in replying - I'd forgotten I'd asked the question (I've got a memory a goldfish would be ashamed of)

I couldn't see a way of getting a view to do what I wanted so ended up writing a standalone script that creates a module.  The structure is along the lines of your template, including recursion and seems to work.  The complications included ignoring certain 'historical' linked modules and having to retain information from the 'parent' object of the test object, where the parents may occur at different levels within the requirement hierarchy (where I use 'parent' to mean the requirement(s) that the test object verifies)

Thanks for your input.

Stuart
Report this to a Moderator Report this to a Moderator
 15-Feb-2007 06:22
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

"...I've got a memory a goldfish would be ashamed of..." That's the 2nd time this week you've posted that.

I've never had luck doing recursive analysis traveling along multiple links searching for the info I need ..err.. other folks think they need. I argue that a sub-system requirement needs only 'satisfy' its direct parent 'system' requirements, and and doesn't need to 'satisfy' the original ORD requirements. I do have a clumsy script that does recursive link reporting, but it outputs each object to Excel in its own separate line, along with a feeble effort on my part to try to indicate how many levels 'deep' each object is.

The first version of the script allowed 'cousin' reports, and not just direct ancestor and descendant reports; that is, it reported all linked objects of every found linked object. Turns out 98% of all the requirements in the project were so indirectly linked and the script found and reported them all. Even my boss at the time realized the uselessnes of such a report.

On another program I made one report of a paltry 100 ORD requirements looking down 3 levels of linked requirements, and the resulting report took about 10 hours on the client and was too big for Excel. (Part of that excercise was to diswade such reports, another was to highlight the fact that folks were linking child to any parent remotely resembling the child, isntead of just the parents that drive the child's existence).

No, just give one level of linking reports.

- Louie
Report this to a Moderator Report this to a Moderator
 15-Feb-2007 18:40
User is offline View Users Profile Print this message


Stuart Bruff

Posts: 4
Joined: 9-Jan-2007

quote:

Originally posted by: Louie Landale
"...I've got a memory a goldfish would be ashamed of..." That's the 2nd time this week you've posted that.


Is it?  Posted what? ...

quote:

Originally posted by: Louie Landale
"I've never had luck doing recursive analysis traveling along multiple links searching for the info I need ..err.. other folks think they need. I argue that a sub-system requirement needs only 'satisfy' its direct parent 'system' requirements, and and doesn't need to 'satisfy' the original ORD requirements. I do have a clumsy script that does recursive link reporting, but it outputs each object to Excel in its own separate line, along with a feeble effort on my part to try to indicate how many levels 'deep' each object is. The first version of the script allowed 'cousin' reports, and not just direct ancestor and descendant reports; that is, it reported all linked objects of every found linked object. Turns out 98% of all the requirements in the project were so indirectly linked and the script found and reported them all. Even my boss at the time realized the uselessnes of such a report. On another program I made one report of a paltry 100 ORD requirements looking down 3 levels of linked requirements, and the resulting report took about 10 hours on the client and was too big for Excel. (Part of that excercise was to diswade such reports, another was to highlight the fact that folks were linking child to any parent remotely resembling the child, isntead of just the parents that drive the child's existence). No, just give one level of linking reports. - Louie


Oh, it worked OK, beginners' luck I suppose, coupled to a fascination with proof by induction and some exposure to LISP.

Unfortunately, the report is a contractual requirement, as our customer has to provide evidence to sell off the requirements to his customer, und so wieso ... 

So it was either find a way to do it in dxl or do it the hard way. 

The script had to avoid certain 'historical' links and modules and output the actual equipment/system requirement being tested (otherwise the tests wouldn't necessarily make much sense when read against the top-level requirement).  I suppose my script equates to your 'cousin' reports.

Fortunately, although there are a fair number of multiple-paths through the links, I only end up (so far) with about 1200 test objects from 380 requirements looking down 2 levels of linked requirements (I expect to get another 400~500 test objects as we progress).  It took about 5 minutes (once I realized that I had to avoid updating the screen!).

However, I more than take the point - validating it is going to be interesting, as it will mean checking that we haven't missed anything ...

Stuart
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.