Lately I've received a number of questions about the ReqPro migration capability in RRC (including this recent post), and I thought it might help to update the larger community on the status of this work.

RRC V3 Beta 2a could read a ReqPro baseline file and import requirements, documents, and users into the RRC repository. We got a lot of helpful feedback from beta customers and decided, before we could offer it for production use, we need to address a number of new requirements related to the migration process, including better logging and support for multi-value enumerated attributes (which a lot of ReqPro projects use). We could not finish this work in the remaining portion of the V3 release cycle. So we deferred it, did not include it in later V3 milestones, and intend to deliver it in the first fixpack on V3.

We see this migration capability as "very important", because we know there are a lot of teams using ReqPro that are looking forward to using the great new capabilities in RRC -- as well as having a RM system that's tightly integrated with RTC and RQM ... in other words, the promises of Collaborative Lifecycle Management.

If you are in this group, then I encourage you to go ahead and get started with RRC now or when V3 is released (which is planned for later this quarter). If you need to bring some ReqPro data into RRC, you can do that in one of these ways:

1. Synchronize RRC V2 and ReqPro 7, then upgrade to RRC V3

2. Export ReqPro info in Word or CSV files, then import them to RRC. You'll need to recreate trace links, but at least your data will be there.

Note that RRC does not offer the same kind of Word integration as ReqPro (no editing requirements in the RM system from Word -- only import from Word), and the synchronization between ReqPro and RRC supported in RRC V1 and V2 has not been carried forward into V3; we intend to switch the migration model from "sync" to "migrate" as mentioned above.

There are a number of things to consider as you move to RRC, including the questions listed below. The best way to answer these questions is to run a pilot project and/or find a trusted adviser who knows the tools and development processes they support and can share his/her wisdom. You can use the supplied project templates, but chances are you'll want to tailor them to your organization. And don't worry: you don't have to answer all of these questions just to get started.

1. Which artifact types will we use? RRC offers a lot more flexibility in creating artifact types, addressing the full information lifecycle of requirements. For example, how about "meeting minutes" as one artifact type? The RRC product team uses that type n our self host.

2. How will we make use of the visual editors; where will they fit in our requirements process?

3. What attributes do we need on our artifact types? What can we learn from how we used attributes in RequisitePro? Now that there are other grouping mechanisms (folders, tags, collections), do we need as many attributes?

4. How will we use folders, tags, collections, and saved filters (views)?

5. What reporting and metrics do we need from the system, both generated documents and dashboard-type information?

6. What new "degrees of freedom" will the CLM products working together give us to adapt our development process and team roles so we are more effective? I see many teams wanting to become "more agile", adopting and adapting agile processes so they scale to large enterprises. RRC, RTC, and RQM are designed to help you do this.

In general, I recommend starting small and simple, and adding complexity only when you really need it. Focus on the things that are most valuable -- a "lean" approach.

You can start now to gain familiarity with RRC and being to answer these questions, then when the migration capability is available you'll be further along in getting your RRC environment ready to be used on real projects.