Now that Rational Requirements Composer 2.0 is available for download here on jazz.net, I would like to explain our motivation for 2.0, put Requirements Composer in the context of the Jazz vision (specifically with Team Concert and Quality Manager), and provide some pointers so you can learn more.

With Rational Requirements Composer, we aim to help teams be more effective when they are …

• Running fast-paced projects
• Employing lean, light-weight requirements practices
• Involving a high degree of stakeholder participation and interaction

Let me explain these in reverse order.

Customer/stakeholder involvement

Project success is judged by your customers and other stakeholders. Good project leaders will help teams to identify, engage, and communicate with their stakeholders through the life of a project. Who are your stakeholders? Certainly your sponsor, who is paying the bills, and the end users of whatever you are building are stakeholders. In larger organizations the customers are often in the lines of business, and while they may be business experts, they typically are not experts in technology (this is one factor driving an increasing use of intuitive visual notations as means of bridging the IT/line-of-business communication gap).

Use scenarios in multiple notations to uncover customer needs

Your stakeholders probably include marketing/product management; and don’t forget the operations/production teams who have to live with what you produce. In larger organizations, there are many other corporate stakeholders, for example the keepers of your project governance process and your compliance/legal department. Project team members themselves are also stakeholders: developers, independent testers, documentation team, user experience professionals, etc. The better each person understands the organizational context, business goals, and reasons why one thing is more important than another, the more value he or she can deliver as part of the project.

These stakeholders all have something to bring to requirements definition. Together they understand more of the possibilities and constraints than the project team alone can identify. Your project is more likely to deliver valuable outcomes if you involve them early and often in expressing the business context, clarifying the goals, and validating the work done to date. This is challenging enough even when teams and their stakeholders work in the same building. It’s worse for many teams, who are continually crossing boundaries that impede effective collaboration: organizational, geographical, cultural, and linguistic.

Project teams are most effective when they work with a common understanding of priorities and requirements.  Developers need deep visibility into requirements; independent testers need to prove that the requirements are being met.  The first results of the Jazz Collaborative ALM project now make possible new levels of team alignment and information visibility among the users of Requirements Composer, Team Concert and Quality Manager.  More on this below.

With Requirements Composer you can:

• Use the best notations for expressing your ideas (using UI storyboards, process diagrams, use case diagrams, text, office documents, your favorite mind mapper, snapshots of whiteboards, etc.)
• Tie this information together in meaningful ways for yourself and the rest of the team (using links, collections, attributes, tags)
• Make team activity visible, including conversations, what’s changing, history, and the artifacts themselves (using dashboards, review and approval workflow, threaded group comments)
• Make it easy for stakeholders to get involved (using the web client, review and approval notifications)
• Align and inform development and test activities with customer needs and requirements (using Collaborative ALM integrations)

Lean practices

Many teams use documents and spreadsheets to capture and organize requirements – and then struggle with the limitations of this approach. With Requirements Composer we aspire to help these teams bridge their information islands, better organize, use and reuse this information.  We are doing another kind of bridging as well: in the business domain, requirements information is typically document-oriented (presentations, diagrams, documents); in the solution domain, it is typically record-oriented (work items, defects, test plans, test cases).

Lean means “just enough” process and just enough documentation; the right balance differs by organization and project. For example, in long and complex projects (for example if you are building a jumbo jet, or you have to prove compliance with a large set of policies) you can increase your chances of success if you use a high-end requirements management tool like Rational DOORS.

With Rational Requirements Composer 2.0 we are primarily targeting teams building and evolving IT systems needing more than documents and spreadsheets for their requirements but less than Rational DOORS.  RRC is applicable to teams using waterfall, iterative, and agile-at-scale methodologies.

Alternatively, teams managing requirements in DOORS or Rational RequisitePro can use Rational Requirements Composer to improve their requirements definition practices. You can find more information on integration scenarios in our wiki.

Fast paced

For a long time Rational (and many others) have advocated the use of iterations in project methodologies. Each iteration gives your team opportunity to reflect on what’s been done thus far, get additional validation from customers and other sponsors, learn more about what the project needs to deliver, and prioritize the work for the next iteration. We have had this dynamic in mind as we’ve built Rational Requirements Composer.

Many requirements get fleshed out just-in-time, often as part of solution design.  We see with on our own team: our user experience (UX) professionals use Requirements Composer storyboards to describe important user scenarios and flesh out detailed requirements as they engage in conversations with customers, marketing, and other project team members.  Maybe you have sat with them and provided your own feedback in the Users First lounge at a Rational conference.  Rational Requirements Composer helps us iterate quickly and make changes consistently in our project artifacts while still seeing and using prior versions; our UX team love Requirement Composer’s UI sketches and storyboards in particular, because they provoke good requirements-focused conversations with both non-technical and technical people; and the way we’ve built in reuse and inheritance, changes can be made in one place and consistently applied across many wireframe mockups.

Early design of the RRC 2.0 review and approval workflow; from a storyboard employed in the Users First Lounge at the Rational Software Conference 2009 in Orlando Florida

Collaborative Application Lifecycle Management

Jazz is a vision, an architecture, a community, and a growing set of interrelated tools that bring teams together in productive collaboration across the project and application lifecycle.  Through the Jazz Collaborative ALM project we are defining cross-role and cross-tool scenarios according to these guiding principles:

• Enable users to weave a ‘web’ of ALM resources that they can use to collaborate, navigate, and track status
• Enable transparency with dashboards that support viewlets from other repositories
• Let users work in the tool that best suits their role and minimize the need to use a separate tool
• Allow our customers to choose the tools that best suit their needs by providing flexible and open integrations

This is a new way of doing integrations inspired by the way people collaborate over the the Internet. Requirements Composer 2.0, Team Concert 2.0 and Quality Manger 2.0 are the first to implement scenarios defined in C/ALM, including links between requirements, work items and tests; rich hovers that show information from the other end of a link (which may come from other tools); and dashboard viewlets that consolidate relevant information from across the tools.

Dashboard can include information from Team Concert and Quality Manager

Learn more

I suggest the following resources to learn more about Rational Requirements Composer (RRC) 2.0.

• Download Rational Requirements Composer and see for yourself.
• What’s new webcast [18 minutes] by George Decandio (Senior Development Manager) and Vishy Ramaswamy (Requirements Composer architect).  They made this recording at the end of September 2009 when we released the last beta.  Most of the major features of V2 were in this beta.  See also the New and Noteworthy tab, which summarizes the new features.
• The Collaborative ALM integrations with Requirements Composer, Team Concert and Quality Manager are based on Jazz Integration Architecture principles and the APIs defined as part of the cross-vendor Open Services for Lifecycle Collaboration (OSLC) initiative.
• The RRC product team use RRC in projects to develop RRC.  We talk about our experience developing the review and approval workflow for RRC 2.0 in the blog post Only 5% are Requirements and in this video.
• You may be interested in some of the other RRC product integration scenarios and their status.
• The jazz.net library includes a growing number of short RRC videos and and information about Collaborative ALM.
• There is a developerWorks primer on Storyboarding in Rational Requirements Composer.
• The release notes and product documentation are available in the RRC information center.
• IBM publishes announcement letters for each product and major release; you can find them for your country at the IBM offering information portal (search for “Requirements Composer”).

And to learn more about implementing a stakeholder-centered development approach, I recommend Outside In Software Development: A Practical Approach to Building Successful Stakeholder-based Products by Carl Kessler and John Sweitzer.