![]() |
Telelogic DOORS (steve huntington) | ![]() |
new topic :
profile :
search :
help :
dashboard :
calendar :
home
|
||
Latest News:
|
|
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 |
![]() |
![]()
|
![]() 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 | |
![]() |
|
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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
quote: 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 |
|
![]() |
|
![]() |
|
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 |
|
![]() |
|
![]() |
|
quote: 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 |
|
![]() |
|
![]() |
|
"...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 |
|
![]() |
|
![]() |
|
quote: Is it? Posted what? ... quote: 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 |
|
![]() |
Telelogic DOORS
» General Discussion
»
Creating an RVVM view
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.