an introduction to rational's new requirements composer

CONCEPTS OneSpring LLC

w w w . o n e s p r i n g . n e t

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.

Concepts | Rational’s new Requirements Composer

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

• 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.



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.



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



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



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:



• 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



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

Figure 11 - Search strings



• 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



RRC.

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



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.



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



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

an introduction to rational's new requirements composer

Business

rational requirements

requirements management

new entrant

new entry

rrc analysts

pagein rrc

rolebased dashboards

business process bpm