It's all about the answers!

Ask a question

[Report Builder] Where are top level Requirement relationships specified?


Fernando Cabrera (1527) | asked Aug 19 '20, 11:00 p.m.
edited Aug 19 '20, 11:01 p.m.

 I'm researching right now LQE and JRS (Jazz Reporting Services). I understand that LQE essentially is a triple store that takes as input TRS feeds. JRS uses LQE as a data source to create reports.


In JRS you select an artifact to report on. For Quality Management artifacts it is straightforward, but for Requirements Management artifacts I see there are several sub-types of both Requirement and Requirement Collection. If I understand correctly there is no Requirement artifact, there are only sub-types. As an OOP analogy Requirement is like an interface and the sub-types (Vision, Header, etc.) are implementations. 

My question is, when you select the top level Requirement artifact type in "Choose an artifact" and then you select a relationship you want to report on in the next section, where do the relationship options come from? If I don't select any project, links to Work Items ("Affected By", "Implemented by" and "Tracked By") will be shown, but if I select any RM project those relationship options are gone. 

I've also seen that the "Specified By" relationship shows all artifact types as targets in the top level Requirement artifact type, but for all the sub-types the target artifact types for this relationship are limited to "Requirement", "Requirement Collection" and "Some Resource". Why is that? Where is this data coming for the top level Requirement artifact type?

One answer



permanent link
Ian Barnard (1.9k613) | answered Aug 21 '20, 4:22 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Disclaimer: I'm sure my description below is approximate - I don't have any detailed knowledge of how RB is implemented.


For each data source Report Builder builds a metamodel of the things in that data source - this is updated daily, or if you have admin role you can 'refresh' a data source to force an update to the metamodel. This metamodel records the 'shape' of each type of resource: i.e. it's attributes and relationships. The daily update cycle means when you add e.g. a new artifact type in your DOORS Next project it may take a day to become visible in RB.

The metamodel is then used to present to you the relationships for that type of resource, and the attributes you can put in report columns.

The use of shapes (which are provided by each app like RM, QM that contributes to the data source) and the fact that RB builds its metamodel from your data in LQE/DCC is A Good Thing: it means the RB developers don't have to hardcode every detail, and it means that users are offered selections based on the data they are reporting from - they aren't bombarded with irrelevant details.

BTW Where RB shows the top-level 'Requirement' that refers to, in DOORS Next terminology, non-module/collection Artifact Type, and the entries below it are the specific Artifact Types defined for the scope you've selected.

when you select the top level Requirement artifact type in "Choose an artifact"
> and then you select a relationship you want to report on in the next section, 
> where do the relationship options come from? 

The displayed relationships come from the metamodel Report Builder holds for the data source you've selected - and if you've set a scope then they are constrained by that scope e.g. only requirements relationships if you've selected an RM project.

the "Specified By" relationship shows all artifact types as targets ...

The metamodel includes shapes for all the data in LQE not just requirements: 'requirements relationships' include not just all relationships that go from requirements but also relationships that can come to a requirement. I think 'specifies' is a relationship from a model element to a requirement.

Also you'll be offered relationships which you don't explicitly create - for example Used By/Uses - this is the relationship between a module and the artifacts in it; you create it when you put an artifact in a module.

Basically you may see possibilities that don't mean much to you - just ignore them.

HTH
Ian


Comments
Fernando Cabrera commented Sep 18 '20, 9:22 p.m.
Sorry for the late reply. Thanks for the explanation, Ian. To be specific what I'm attempting to do is provide a custom relationship in the top-level "Requirement". This is from where my question comes from. Is this feasible? I understand that the entire artifact section comes from the RB meta-model and I have successfully specified custom relationships in Requirement sub-types in the metamodel, but not for the top-level "Requirement" type .

Your answer


Register or to post your answer.