What added value does ReqPro have to RRC 2.x?
We have been using ReqPro for a while now and there are a couple of things we really miss, like decent "out-of-the-box" version control of requirements. It looks like RRC 2.x delivers more goods in that area (amongst others) and I would therefore consider moving to RRC 2.x.
But then I see all this attention on integrating with ReqPro and I'm kind of puzzled: I would rather replace ReqPro with RRC. So my question is: what am I giving up if we'd move to RRC from ReqPro. And what added benefit does integration with ReqPro give me (other than automatically assigning sequence numbers to requirement elements and the ability to manually maintain traceability matrices, I guess)? Thanks! Pascal. |
4 answers
I would rather replace ReqPro with RRC. So my question is: what am I giving up if we'd move to RRC from ReqPro. And what added benefit does integration with ReqPro give me (other than automatically assigning sequence numbers to requirement elements and the ability to manually maintain traceability matrices, I guess)? Yes, a single tool is easier for users and system admin to deal with, and RRC, a next-generation requirements solution, offers some great new value/capabilities. Below are some considerations for you ... RRC 2.0 lacks some signature ReqPro capabilities, including the following: * Live links in MS Word documents (using Word as the UI to your RM repository) * Import of requirements from Word and CSV files * Some traceability views (tree, grid views) * Suspect links (though there are other ways of discovering and dealing with change in RRC) * Some richness in the security model * Some product integrations (e.g., RSA, WBM, CQ) If these are essential to you, then you might want to consider a deployment that includes both RRC and ReqPro. If they are not that important, or the are negotiable in the short term (until we are able to address them in RRC), then you might want to deploy RRC only. Daniel |
|
|
I would rather replace ReqPro with RRC. So my question is: what am I giving up if we'd move to RRC from ReqPro. And what added benefit does integration with ReqPro give me (other than automatically assigning sequence numbers to requirement elements and the ability to manually maintain traceability matrices, I guess)? Yes, a single tool is easier for users and system admin to deal with, and RRC, a next-generation requirements solution, offers some great new value/capabilities. Below are some considerations for you ... RRC 2.0 lacks some signature ReqPro capabilities, including the following: * Live links in MS Word documents (using Word as the UI to your RM repository) * Import of requirements from Word and CSV files * Some traceability views (tree, grid views) * Suspect links (though there are other ways of discovering and dealing with change in RRC) * Some richness in the security model * Some product integrations (e.g., RSA, WBM, CQ) If these are essential to you, then you might want to consider a deployment that includes both RRC and ReqPro. If they are not that important, or the are negotiable in the short term (until we are able to address them in RRC), then you might want to deploy RRC only. Daniel <b> Is RequsitePro still going to be supported? SLA's?</b> |
I would rather replace ReqPro with RRC. So my question is: what am I giving up if we'd move to RRC from ReqPro. And what added benefit does integration with ReqPro give me (other than automatically assigning sequence numbers to requirement elements and the ability to manually maintain traceability matrices, I guess)? Yes, a single tool is easier for users and system admin to deal with, and RRC, a next-generation requirements solution, offers some great new value/capabilities. Below are some considerations for you ... RRC 2.0 lacks some signature ReqPro capabilities, including the following: * Live links in MS Word documents (using Word as the UI to your RM repository) * Import of requirements from Word and CSV files * Some traceability views (tree, grid views) * Suspect links (though there are other ways of discovering and dealing with change in RRC) * Some richness in the security model * Some product integrations (e.g., RSA, WBM, CQ) If these are essential to you, then you might want to consider a deployment that includes both RRC and ReqPro. If they are not that important, or the are negotiable in the short term (until we are able to address them in RRC), then you might want to deploy RRC only. Daniel Yes for RequisitePro there is no end in sight. We are continuing to keep RequisitePro vital(*). But as we enhance Rational Requirements Composer to include features inherent in RequisitePro (and many new requirements definition, requirements management, and collaborative lifecycle management capabilities), we expect customers eventually will want to migrate from RequisitePro to Rational Requirements Composer -- starting with the 2011 release of RRC. (*) We continue to do quarterly maintenance releases of RequisitePro, and in 2010 we have made a number of performance improvements to RequisitePro Web client and added support for Windows 7 and Word 2010. This year we plan to improve the integration scenarios between RequisitePro and RQM (see the RQM 2011 plan at http://jazz.net/projects/rational-quality-manager/release-plan/) (*) Also work has been made by the RequisitePro dev team on complying with the rigorous performance requirements demanded by customers. The detailed performance information is published in a white paper which explains the performance improvements of RequisitePro 7.1.1.1 ( and later versions ). It contains comprehensive information about the use cases that were improved and a clear description of the environment where it was tested. The white paper can be located here: http://www-01.ibm.com/support/docview.wss?uid=swg27019877&cm_sp=MTE15269 Also, the product main Web page for RequsitePro contains links to this technical document. http://www-01.ibm.com/software/awdtools/reqpro |
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.