Is there a Schema for DOORS Nex t + Quality Manager?
Trying to understand the expected relationships and entities across DOORS Next and Quality Manager which defines the relationships and properties and can therefore be used as a guide for constructing views, queries and reports in Report Builder?
Whilst I've seen some of the OSLC metamodel there is no integrated model (it's split into domains and mostly these are text-based) and therefore don't cover relationships between domains but I need to understand how IBM have implemented it (and what other relationships exist that come with the tool).
|
One answer
In most cases, links across domains in ELM are those defined by OSLC. The relationship between requirements and test artifacts is essentially "validates/validated-by"; a test case validates a requirement, a test plan validates a requirement collection/module.
When you click "add a relationship" in Report Builder, it should list all possible relationships grouped by relationship, so for a requirement, you should see a QM Test Case heading with a validated-by entry beneath it. You can also add columns to views in DNG and ETM (renamed RQM) to show those relationships, and in DNG, you can filter by "lifecycle status".
These Knowledge Centre topics describe the test-requirements linking:
There is a broader table of ELM cross-domain links in this wiki article, although it needs updating to clarify RMM vs DM (mostly the same relationship) - and the article itself is focused on a different topic.
Hope that helps.
Comments
It's the 'in most cases' that is important.
The 'validates' relationship in the OSLC is technically incorrect (proving of a design against requirements is 'verifies', correctness of requirements is 'validates' but because the OSLC have messed up and IBM promulgated the error we cannot not assert that something validates a requirement nor create the proper 'verifies link - and it fragments the verification of functional and non-functional requirements where the evidence is an analysis report).
Using the tool isn't a good basis for producing a schema / metamodel. This needs to be separate in order to plan the architecture. The tool only shows me what's in a component - no way to assess the schema in a holistic way to even understand whether it's possible to undertake the traceability required.
One of the things that isn't explained is the relationship where an artifact is embedded within an artifact.
The second link provides some information but why someone would present a metamodel (E-R diagram) as text in a table rather than as a diagram is baffling. It seems the OSLC suffers similarly.
In summary this provides some pointers but it sounds as though there is no holistic metamodel presented anywhere to consult - at best we've got fragments of text - strange for a tool set built on RDF / tuples. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.