Skip to main content
RegisterLog In to Jazz.net dW

Blogs about Jazz

Blogs > Jazz Team Blog >

CLM 2012 Part 4 – Rational Requirements Composer: Definition to Delivery

This is the fourth in a series of blog posts discussing the enhancements in our Collaborative Lifecycle Management 2012 solution.  Continuing with our race to the CLM 2012 finish line, let’s take a look at some of the great new features in Rational Requirements Composer.

Just as a racing pit crew is essential to keep things moving to stay ahead of the pack, the business analyst keeps the requirements and product use cases in check to ensure that the product meets the customer’s needs when it’s delivered. I enjoy being an analyst just as I enjoy being pit crew (to my 78’ MG Midget – it requires a lot of pit time).

The Rational Requirements Composer (RRC) team has really made great headway over the past year, succeeding in making RRC the “next generation requirements tool”. With a release (RRC 3.0.1.1 with RequisitePro migration) in October 2011 and now the 2012 CLM release , we deliver even more high priority customer capability. Along the way we’ve witnessed even wider customer adoption for Requirements Composer as customers choose to put RRC in the project driver’s seat.

RRC is part of the CLM 2012 release, so naturally it adopts other CLM architecture improvements in order to support high availability via clustering and server rename. But beyond CLM there are some pretty powerful additions for the business analyst … especially in the area of traceability and trace analysis.

Ratchet up the Power of Traceability

If you paid any attention to Requirements Composer’s headlines last year (here on jazz.net) you’ll know that we were working on some very special capability to improve the way people interact with and analyze their requirements traceability. We introduced an “incubator” add-on for Requirements Composer called the graphical traceability explorer which gave the RRC community a very real idea of the possibilities for exploring project artifact relationships. As we move the calendar forward twelve months, we’re now ready to introduce the trace explorer directly in RRC – but significantly improved, with the help of your feedback.

Take single or multiple selected requirements from the grid or the artifact display and open the explorer to see the dependent relationships in a variety of displays. For those of us who are using traceability to help expose development gaps, track changes across links on dependent requirements, or understand downstream dependencies, the explorer will be a new place where much of your work will be done. From the explorer you will be able to create new requirements, use cases, tests, work items, etc. that automatically link to fill out the next level of detail required for your upcoming release.

I can’t say enough good about the potential of the new graphical traceability explorer; you just have to try it out for yourself.

But if that isn’t enough traceability power for you, then we’re going to take it up even another notch. RRC introduces the power of suspect links through user profiles that improves on older methods for detecting changes on the other side of linked artifacts. Never before have you been able to set up specific profiles that can be configured to watch specific link relationships across project requirements. When changes are made to linked requirements, tests, or development items, you will see suspect link indicators based upon your user role. If you’re an analyst, then you will know that the displayed indicators are alerting you to changes that you actually care about analyzing. Once you’ve validated the change or updated your requirement, then you can clear the suspicion to get back to a valid relationship.

With the additions of suspect links and the graphical traceability explorer to RRC’s existing trace tree, traceability columns, and trace reports, you have so many ways to ensure that you have the appropriate coverage  – from business needs to development delivery – for your next release.

More Control with Write Permissions

Previous versions of RRC 2.x and 3.x let us use various access permissions at a project level, but now we can do much, much more. Write permissions can now be set on both the folder and the artifact levels. This opens up a whole new way of working with your project information and collaborating with team members during the requirements definition phase. Imagine setting write permissions to specific folder areas during the initial start up phase of your project and then removing these permissions once the project has achieved a specific milestone at which a review process is more appropriate.  You will have much more control.

Working across Project Boundaries

Are you working with multiple projects, multiple project configurations, or requirements in separate repositories?  Many people are, including the RRC team in our self host on jazz.net. We now have a great way to upload and download project templates from one project to another, making it easier for all of us to maintain our project configurations from one environment to another.

Additionally we now also have the ability to export and import requirements from one project repository to another (including from DOORS 9.4) using the OMG XML standard Requirements Interchange Format (ReqIF).  This open format standard lets us reliably take requirement artifacts from one project to another. It’s a great way for taking an existing set of requirements to kick-start a new project and for sharing with a partner or collaborator. It’s also much more reliable than working with spreadsheet transfers.

Automatic Requirements Identification using Requirements Parsing

Go from manual to automatic when importing Word documents (supported since RRC 3.0.1) with automatic requirements parsing. Once we’ve imported the requirements document or spreadsheet, you can automatically pick out the requirements and apply them to your artifact template.

Now you can take any set of requirements in Microsoft Word, spreadsheets, or existing artifacts and automatically detect the requirements using keywords, paragraphs, or document structure. Each requirement will be parsed into a new artifact of your selection to allow you to then use attributes and links, and designate them for release.

There is a great deal more for the analyst to be excited about including performance, better usability, etc. in the upcoming CLM release and Rational Requirements Composer. But don’t take my word for it. I expect you to see if for yourself. Join me here on jazz.net and become a part of the next generation.

Jared Pulham
Senior Product Manager, Requirements Management for CLM
jared.pulham@uk.ibm.com