An Introduction To Rational's New Requirements Composer

CONCEPTS
OneSpring LLC

March 3, 2009
Rational’s new Requirements Composer
An Introductory Overview
By Mark J. Sandefur

Executive Summary
In late 2008 a new entrant emerged in the expanding Requirements Definition tools arena – IBM Rational’s
Requirements Composer. As Rational is correctly recognized as a thought leader in the Application Lifecycle
Management (ALM) space, it is important to see the role this new entry can play, for enterprises.

Rational Requirements Composer, hereafter referred to as RRC, is not a Requirements Management tool. It rather
attempts to exist earlier in the lifecycle, where requirements are first defined. This matches the current trend, whereby
business-side resources can contribute more fully on projects, using various ‘vocabularies’ to collaborate on ideas.
RRC seeks to serve two audiences: Analysts (who author), and Stakeholders (who review). Ultimately, it can thus
serve as a collaborative repository for organizing, creating, refining, and reviewing requirements and their related
materials. This can shorten duration and increase your competitiveness in a demanding market; and also lower costs
through better communication and less rework.

Flexible sources, of Requirement material
A great starting point in trying to grasp RRC’s role is understanding the variety of artifacts that can be leveraged, in it.
These can include:
Rich Text – either create Rich Text (including media such as images) in the editor, or leverage other rich
•
formats such as Microsoft Office documents.

Figure 1 - Rich Text document example

Multiple Glossaries – Remove ambiguity on business and technology terminology.
•

www.onespring.net

Concepts | Rational’s new Requirements Composer

Models – both Business Process (BPM) and Use Case (UC) diagramming is possible in the product’s editor,
•
using industry standard notations.
User Interface (UI) – In RRC analysts can sketch out reusable screen ‘parts’, as well as full screens. From
•
these, storyboards can be constructed, providing a low-fidelity display of how an application can flow.

Note this is not the same as Visualizations, which are by nature high-fidelity.

[Visualization: a powerful way to define applications right – the first time, by enabling organizations to “test
drive” and fully experience systems early in the process, insuring the design looks, acts and feels like the real
thing and that everyone is literally on the same page]

In RRC the analyst focuses on visually designing the user interaction desired in an application, versus producing a
partially “live” version of the application (i.e. a prototype), as they would with a Visualization product.

Figure 2 – UI Parts, Sketches, Flows, & Storyboards

As to the product’s usage, it has an Eclipse-based interface, and leverages Rational’s Jazz platform to enable linking,
collaboration, and various other uses of the meta-data in the repository. It has role-based dashboards to help focus
team members’ work, and security controls ensure that teams and partners only have access to the appropriate
content. Licensing price points exist for both Authoring and Reviewing, and a browser-based client is in future plans.

3/5/09 Page 2 of 13
COPYRIGHT © 2009 ONESPRING LLC ALL RIGHTS RESERVED


Ok, so about linking, and the Requirements themselves…
It is from this wide variety of possible sources, where one can come to understand the power of a repository. Because
for an organization that made use of these various mechanisms, an entire team can come to see the same vision.
Consider:
From the ‘Meeting Minutes’ document above, Analysts decide that a new term has arisen that should be
•
added to Glossary, in order to ensure consistency should it arise again.

Figure 3 - Adding to glossary

The team also realizes that they now have a new formal requirement, and denote it as such via right-clicking
•
text and selecting ‘Mark as Requirement’, so that it can be managed moving forward, in the lifecycle.

Figure 4 - New requirement

Additionally, a process change has been ‘brainstormed’. In addition to inserting a picture of this design
•
change from the whiteboard into the repository, the analysts should tie that change to the appropriate design
models.

3/5/09 Page 3 of 13


Figure 5 - BPM entity linked from ‘Minutes’ doc, and out to ‘Purchase CD’ UC

Figure 6 - Existing UC Diagram, showing ‘Purchase CD’ UC in context

3/5/09 Page 4 of 13


Figure 7 – ‘Purchase CD’ UC tied to example User story

Finally the appropriate Use Case (above) can have a visual elaboration tied to it, to help define. This
•
elaboration can show a User Story, with resulting screen design seen that was built from screen ‘parts’

Figure 8 - appropriate Story

3/5/09 Page 5 of 13


Note in the above story that screen sketches appear below, with green dots showing navigation/flow.

Figure 9 – Sketch of screen impacted

By clicking on impacted sketch in bottom part of story, it is pulled up in the editor, for review or modification.

Note that an enterprise doesn’t have to make use of all these different formats when they elicit requirements, but only
that if they do RRC can accommodate it.

Additional Features
The following features of RRC are also important to note:

3/5/09 Page 6 of 13


Collaboration is a core component of all the entities within RRC. Messages concerning artifacts can be
•
recorded and directed to the appropriate team member, which they will then see in their dashboard.

Figure 10 - Collaborate around specific artifacts

3/5/09 Page 7 of 13


Powerful string search capabilities exist, across the repository. In example below, all artifacts with the word
•
‘check’ are returned.

Figure 11 - Search strings

3/5/09 Page 8 of 13


Versioning exists for each artifact. Each change to the artifact is shown in a timeline across top (in the
•
History view), allowing easy rollback to previous versions.

Figure 12 - History of artifact

Word Exports help facilitate getting the data ‘out’.
•

Figure 13 - Glossary exported to Word

Detailed process guidance, available. It can reference entities such as Actors, Inputs, Outputs, and Tasks.
•
Enterprises can in fact author their own process in Rational Method Composer, if desired, and publish to

3/5/09 Page 9 of 13


RRC.

Figure 14 – In-depth process guidance, a click away

3/5/09 Page 10 of 13


Extending RRC
Functionalities not present in RRC can also be ‘part of’ the project; and downstream usages exist:

Partnerships already exist with iRise’s more advanced Visualization technology, as well as RavenFlow’s
•
generation of visual models from textual use cases to aid understanding.

Figure 15 - example of iRise artifact in repository

Requirements can be pushed out to RequisitePro allowing for continued Traceability, as well as other
•
artifacts into other downstream Rational products.

Conclusion
Where an enterprise falls at any given time, on the Requirements Definition and Management spectrum (below) can
vary; and as such a mechanism like RRC where they can store, link, and govern the outputs from these variety of
approaches is of value.

3/5/09 Page 11 of 13


Early adopters of RRC are likely to be organizations that already adopt Rational’s ALM suite of offerings, particularly
Jazz and RequisitePro. Over time however, it could also provide value to other organizations that currently define
requirements through a variety of measures and seek to add a layer of unified vision and governance to the process.

OneSpring was created to harness the power of new technology in requirements definition and software design. Our
background with traditional requirements definition provided us with countless years of experience developing textual
requirements (i.e., use cases). Hours spent cleaning up the results of documentation and design errors had provided
us with a burning ambition to stay on top of solutions that could save our team and our clients many hours of
development time. As a result, our consultants at OneSpring have moved away from traditional requirements
definition and have adopted a process of leveraging Visualization methods, and new tools such as this.

External Resources

ALM - http://en.wikipedia.org/wiki/Application_Lifecycle_Management
•
Eclipse - http://www.eclipse.org/org/#about
•
Jazz - http://www-01.ibm.com/software/rational/jazz/
•
OneSpring - http://www.onespring.net/index.html
•
RRC - http://www-01.ibm.com/software/awdtools/rrc/
•

About Author
As Director of Business Development at OneSpring, Mark J. Sandefur plays a key role in the company's sales efforts.
He has a solid background in selling, leading, and implementing technological service engagements and projects, with
a strong emphasis on application development and software architecture solutions. Prior to joining OneSpring, he was
with IBM Rational Software after a long background in management consulting. In addition to having an MBA, he

3/5/09 Page 12 of 13


also is certified as a Master IT Specialist with The Open Group and a PMP from the Project Management Institute.
He makes his home in Roswell, GA, with his wife Amy and two children Kirby and Rhianna.

For more information regarding OneSpring and how we can assist your company with delivering products faster,
more intelligently and more focused contact us at www.onespring.net

3/5/09 Page 13 of 13

An Introduction To Rational's New Requirements Composer

Recommandé

Recommandé

Contenu connexe

Similaire à An Introduction To Rational's New Requirements Composer

Similaire à An Introduction To Rational's New Requirements Composer (20)

Plus de OneSpring LLC

Plus de OneSpring LLC (6)

Dernier

Dernier (20)

An Introduction To Rational's New Requirements Composer