RRC - how should I set up requirements to reduce effort to create custom report templates using RPE
I have a customer who has used DOORS and who
understands RPE. They are in the process of moving from DOORS to CLM/RRC.
One of their needs is to be able to generate documents like system specifications to deliver to their customers when they finish the product. In the box in RRC is a report called “Requirements Specification”. It is just not customer friendly enough for their purposes. None of the other reporting options seems better for this so a new RPE template seems in order. In a DOORS world it is reasonably straight forward to create an RPE template the can pull in all the relevant sections from a DOORS module. As long as the module was constructed using the heading/object paradigm appropriately the amount of customisation to a template is pretty modest... usually you can use just a few attributes to identify some sections that need to be on rotated pages in tables whilst other sections just come out in “book” form. A standard template like this would be very reusable for many projects. The customer presently has CLM 3.0.1.3 installed. I note 4.0 is now available so keep in mind this question is written from the 3.0.1.3 perspective but from what I can see things haven’t changed too much in this area? The question: How should I structure requirements to make it easy to create a report template? The goal: the requirements should be easy to add and navigate from a user perspective, and the amount of effort to create and maintain RPE templates should be minimised. What are good practices for that? For example, I could make each Chapter a folder in RRC and then grab everything in that folder. The pain is I’d have to do that once per folder. It makes the whole template very brittle. It would be great if you could recursively go down through a
set of folders and grab the folders and use them as chapter headings and the
then the contents as rows. From what I can see of the api that doesn’t appear
to be supported. In my experiments to date I had discovered in
the section in the help here: http://pic.dhe.ibm.com/infocenter/clmhelp/v3r0m1/index.jsp?topic=/com.ibm.jazz.reports.doc/topics/qm_c_reporting_options.html I did give some feedback that the info on that page relating to RPE was all out of date. Someone then changed one of the links on that page to then refer to: https://jazz.net/wiki/bin/view/Main/RRC3ReportableRestAPI So that is actually broken as that wiki page has since been renamed to this: https://jazz.net/wiki/bin/view/Main/RRCReportableRestAPI (the “3” was removed. This is still broken in the help and yes I did report that too) Any suggestions greatly appreciated! |
3 answers
This RPE tutorial might help
https://www.ibm.com/developerworks/wikis/display/rpe/RPE+-+RRC+%28Updated%29 Also this is this in the V4 help http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.jazz.reports.doc%2Ftopics%2Frm_c_reports.html In regards to the folders see the V4 blog: http://rhnaranjo.wordpress.com/2012/06/25/folder-support-added-to-rrc-4-0-oslc-rm-api-implementation/ And finally for both V3.0.1 and V4 the wiki which you already found https://jazz.net/wiki/bin/view/Main/RRCReportingWiki |
I don't think that there really is a "nice" answer for this. DOORS is a very, very different paradigm than RRC. DOORS is very rigid and structured per requirements document while RRC is not. The closest that you might be able to come in RRC today with a group of requirements for a specific specification is either with a folder or a requirements collection. A "module" artifact (which is really what you need) was originally proposed to be implemented in RRC 4.0, but that was deferred. You might check when that artifact might be added into RRC.
You might need to get "creative" here. You're going to have to implemented structure into an unstructured world with good process. Folders or requirements collections might work. Using tags or custom attributes as a key for sort order might also work. You can create a URI to filter to a specific requirements collection or view (which would probably be better performance). You can use a custom attribute or tag, then perhaps sort with a Word stylesheet macro to put the requirements in the order that you're looking for. Also note that the embedded RRDG wizard in RRC today is not a full functioned as the stand alone RPE Launcher. You may run into report use cases that would be more easily generated from the Launcher as opposed to the embedded wizard. This of course depends on your report use case and how you implement your template(s). |
One way I have found to be easier to organize the elements to create reports with less maintenance required is to design a report that loads sections of it based on views. By using views as a base for your reports you can organize and change most of the things directly in the view without having to modify the template.
If your report contains sections of requirements you can create a view for each of this sections, for example, if you have first non-functional requirements and then another section with the functional requirements, you can implement a view for each of this requirements type and then just call for those views from the report. |
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.
Comments
Its been quite a while since I posted this and no replies. Can anyone help? (Some of the errors I mentioned above have been corrected)