The latest beta of Rational Requirements Composer (RRC) demonstrates significant progress in our plans to deliver requirements definition and management capabilities in a single application on the Jazz Team Server*. Our intent is to help teams to employ relatively light-weight requirements processes as part of their agile, iterative, or waterfall project methodologies –- whether they are placing user stories in a larger business context, quickly evaluating alternatives using UI storyboards, or using RRC as the next-generation RequisitePro** for creating requirement specifications and working from them.
Requirements definition and management together
We have received many enhancement requests to take RRC beyond requirements definition and make it easier to express a richer set of requirement relationships, analyze them, manage and report on these requirements throughout the development lifecycle. To that end, we have taken RRC’s visual editors, glossaries, and its collaborative requirements definition environment, and combined them with new requirements management capabilities, building on what we delivered in the Collaborative Lifecycle Management (CLM) Beta 2. This will enable teams to address the whole information lifecycle of requirements: from meeting notes and other informal, document-oriented information to managed requirements that are used in development, test, project management, and reporting.
More requirements management capabilities
Beta 2a offers more sophisticated ways to express relationships among requirements, view, and analyze them. It’s now possible to define custom link types, use them when relating requirements, and filter views to display relationships of interest, including multi-level traceability views such as “stakeholder needs are satisfied by features” and “features are satisfied by user stories and supplementary (non-functional) requirements“. Requirements and their relationships can be displayed in tree views (shown above) and in various row and column views. This helps analysts to uncover traceability gaps (coverage analysis) and to analyze the impact of proposed changes.
Improved filtering and CLM links
With the enhanced filtering, it’s now easier to create, save, and share specific dynamic views that report on key project management concerns. For example, using Collaborative Lifecycle Management (CLM) links it’s possible to see related development tasks, test plans, and test cases –- and filter on their status –- directly in the requirements management user interface. Below you see approved features and user stories with associated test cases that have not been attempted.
Looking at this from the RTC perspective: teams that manage their work in backlogs in RTC can see the requirements that guide their implementation tasks.
Entirely Web-based
The RRC authoring environment has moved to the Web; a rich client is no longer needed or provided — just point your browser at the RRC server. This will greatly simplify deployment, reduce total cost of ownership, and make it easier for occasional participants in the requirements process to be meaningfully involved. Here you see a UI sketch in edit mode. Business process diagrams, use case diagrams and actors are also available in this beta milestone.
More productive Web UI for creating and editing requirements
You can now create new requirements faster with only a few clicks, and optionally edit them directly in the grid. You can also update the attributes of multiple requirements at the same time.
The rich text editor continues to improve, and it now includes project-wide glossary term look-up.
Getting information in and out
Beta 2a supports importing documents into native RRC rich text format from Microsoft Word, OpenDocument text (odt) and common rich text (rtf) formats. This makes it easier to incorporate existing information from your stakeholders and documents you create on a plane, your customer’s conference room, or other places where you don’t have access to the network. In addition, you can import from and export to spreadsheets using comma-separated text (csv) files — including associated attribute values.
Data migration from RequisitePro
If you use RequisitePro you can now import a RequisitePro baseline file and evaluate the value of RRC’s new capabilities using your own requirements information — including requirements that originated in Microsoft Word documents. You can find more information on our wiki.
Rational Reporting for Development Intelligence
You can make RRC data available in a data warehouse for improved reporting and trend analysis. A reporting scenario is available on our wiki that includes prerequisites, data warehouse configuration steps, and sample reports. Note that this beta milestone only supports requirements data in these reports (no development or test data).
Generating documents with the Rational Publishing Engine
It’s now possible to use a stand-alone installation of the Rational Publishing Engine on your workstation to generate documents with RRC Beta 2a as a data source. Four report templates are included with Beta 2a. Details on how to use them can be found on our wiki.
Updated sample project
The JKE Business Recovery Matters sample project provides a pre-populated example, making it easier for you to assess RRC alone or with Rational Team Concert and Rational Quality Manager.
- New artifacts, including sketches, process and use case diagrams, actors, and use case specifications
- Enterprise and project glossaries
- Richer linking to demonstrate functional decomposition of high-level requirements
- New link type (“illustrates / illustrated by”) for relating visual artifacts to other artifacts
- New saved filters demonstrate new views
- Release planning collection for use in CLM scenarios
This milestone is called “Beta 2a” because it’s built on CLM Beta 2 (September 2010 code levels of the Jazz Team Server, Rational Team Concert, and Rational Quality Manager). This gives you the opportunity to experiment with the new requirements capabilities in RRC alone or in the context of Collaborative Lifecycle Management. See the RRC Beta 2a release notes and new and noteworthy for more information. There are capabilities in RRC 2.0 that we have yet to enable in the Beta 2a release of RRC, for example: embedded document generation, UI storyboards, UI screen flows, and inheritance of UI sketch parts. For more information on the next CLM beta and release plans see Staging the CLM deliverables.
I invite you to download RRC Beta 2a (M9), create the sample project or import a RequisitePro baseline, and give us your feedback by posting in the RRC forum or the CLM forum or by submitting bugs and requests in our work item system.
Daniel Moul
Rational Offering and Strategy Delivery
* Our lawyers would like me to remind you that these are not finalized plans or commitments … just work in progress, and plans are subject to change without notice. See the Terms of Use.
** By using “next generation RequisitePro” I am implying that RRC is the means by which we will bring innovations in requirements practices and CLM to RequisitePro customers. This will involve migrating your teams and data to RRC sooner or later. Let me be clear: we are not about to sunset RequisitePro or ask RequisitePro customers to rush to adopt RRC. To the contrary, we expect many customers will continue to use RequisitePro for years and will adopt RRC as their project schedules and organizational priorities allow. We are working to keep RequisitePro vital; for example in 2010 we delivered quarterly maintenance releases, made significant performance improvements in ReqWeb, and added support for Microsoft Windows 7 and Microsoft Word 2010.
You must be logged in to post a comment.
Hi, I’m curious about potential performance issues of a web based RRC client.
1) All the user load related to client interactivity will be on the server process and what’ll happen if many users (>100 ?) try to interact with the requirements ? The server is not clusterable and it will also not serve service execution requests but the whole UI interaction as well.
2) When big documents within artifacts are in question, even the eclipse based client hangs, performing all these layout tasks, etc. What’ll happen in such documents are created and they all need to be maintained via the server since the UI is web based. Would this be really a concern ? Are you going to empose smaller sized requirements as the best practice for requirements definition ?
Best regards,
Bulent Erdemir
Good questions. Every product architecture has its advantages and disadvantages. We believe on balance that moving to a Web client will offer the best overall experience and cost of ownership. The RRC V2 client is an Eclipse Rich Client Platform application, and as you note, it can take a while to download a large document. Let’s consider this example. We can improve the user experience in this case by keeping the data in the Web application and paging the information that goes to the client.
Before the next version of RRC is finished we intend to do a lot of performance profiling and optimization, and I expect we will publish the results as we did for RRC V2. See http://www.ibm.com/developerworks/rational/library/10/rrcperformanceandscalablitytestresults/index.html
In terms of best practices, in general we already recommend that large documents be created in pieces, either by (1) using the report generation facility based on the Rational Publishing Engine, or (2) embedding RRC artifacts into a larger RRC composite document. In addition to performance benefits, with each smaller piece of the composite document it is easier to review, understand, and track changes, resulting in better requirements quality overall. In other words, if you are building a large requirements specification document, it’s best if you don’t build a single “flat’ document as you might in MS Word.
This is a good topic for further discussion; if you wish to follow up, I suggest doing so in the RRC forum [ http://jazz.net/forums/viewforum.php?f=8 ] here on jazz.net.
Daniel,
what kind of RequisitePro features RRC 3.0 does not plan to support?
thank you for the topic
@Wagner, I think of the differences from ReqPro in three categories: (1) integrations that don’t make sense to continue (example: with Rational Portfolio Manager); (2) differences due to fundamental product changes (example: RPX scripting is based on Visual Basic and MS COM; we need to move to REST-based APIs); and (3) things we haven’t gotten to yet, because you cannot build Rome in a day — or in one release (example: rich security model). In the coming months we plan to publish a detailed list of “gaps” and (where possible) how to work around them.
We expect RequisitePro customers to do their own benefit/cost analysis, i.e., to look at the great new capabilities in RRC and CLM, consider the gaps versus ReqPro, determine whether any of the gaps are non-negotiable for them, and based on this analysis decide whether they can begin using RRC for new projects or need to wait for a later release. Early indications from our Reqpro customer design partners have been quite positive about being able to start using RRC Next when it is released.
Is there any target date yet for release of RRC 3.0? Is it intended that the licensing will follow RTC 3.0’s use (ie, don’t need to purchase a “server” license — everything is licensed per user)?
RRC V3 is part of the CLM 2011 release, which is planned for the coming (northern) summer. You can learn more in the “staging the CLM deliverables” blog post mentioned above and in the CLM plan available here: http://jazz.net/jazz/web/projects/Jazz%20Collaborative%20ALM#action=com.ibm.team.apt.search&predef=current&tq=1294774927000
Re: licensing of RRC V3 … it’s not for me to make licensing commitments now or in this venue, but you can assume RTC 3.0 provides a general template. In the case of RRC V2 the cost of a server is less than three authorized users (which are included) so moving to “purchase of RRC server license not required” would be a simple transition for V3.