IBM Engineering Rhapsody Tip #90 - Switching requirements from Rhapsody to DOORS Next (Intermediate)

I'm a big fan of not just tracing model elements to requirements but using use case analysis to define requirements for a system. I like the analogy of how modeling provides a powerful and visual workshop in which requirements can be forged and the requirements management is the "gallery" where the resulting works will be exhibited moving forwards. This isn't just about creating requirements to manage but rather finding way to get a better and more complete set of requirements to manage, and also the use of diagrams to communicate in ways which textual requirements cannot. This is video I cover some of the provisional work I've done in adapting my methods, like ROCKETS (R=Requirements), to work with Rhapsody and Jazz/rm (aka DOORS Next). In this work I use existing technology in the form of the csv importer to first get the requirements into a DOORS Next module. I then add the requirements to the model and use a profile helper in Rhapsody to perform the switch. The good thing about this technique is that it means that my helpers work for wide variety of different Rhapsody and Jazz versions and is not tied to an API or the need to do authentication to achieve the sync, i.e. it's not ROCKET science but it helps load the payload into the ROCKET using a 10 minute method.

Here's the transcript:

This silent video covers some development work I'm doing on my profiles.

Some who've followed me may have picked up that I see value from dovetailing use case steps with textual requirements.

Creating requirements from textual activity diagrams for use cases is stage 1 in most of my MBSE methods, including my executable MBSE method called ROCKETS.

To help achieve quick success from MBSE quickly and systematically I've written profiles like this ExecutableMBSEProfile to set up the tool to provide a "10 minute" method.

Diagrams like this are highly accessible because most people can understand flow-chart like semantics with limited training.

For use case modeling, we can use decision nodes to show alternate paths (e.g. sunny and rainy day) on the same canvas.

Diagrams are richer than text, e.g., you can also show things happening in parallel.

Interruptible regions like this can also be powerful, e.g., to show things being interrupted by events.

Importantly people can read a flow-chart like syntax without needing much training, including users.

The Requirements Analysis stage of ROCKETS, focused on the production of formal requirements using use case steps as a stepping stone.

Requirements are the formal hand-off but they are fortified by the understanding conveyed in the diagrams.

In this particular method, all use case steps and guards must be traced to reviewed requirement(s) before hand off to the next stage.

The profile provides automation to make this  easy to do, once the use case steps have been reviewed with stakeholders.

As well as being fun this can lead to a surprisingly complete set of functional requirements when followed through to fruition.

Use case steps are not requirements and requirements are not use case steps. However, they are both enhanced by dovetailing them together.

To accelerate usage, my helper profile has automatically moved the Rhapsody requirements into their own package.

The end of the Requirements Analysis stage involves getting Rhapsody requirements into a formal requirements management tool.

Previously, my methods worked well with the Gateway Add-in and DOORS 9. Moving forward there is a need to be able to switch requirements to DOORS NG (Jazz/rm) without the Gateway.

I want to show you some early work, I've done to achieve this.

Firstly, I'll create a module in DOORS Next where I want the requirements to go.

To get them into DOORS NG I've written a helper to first export them into a CSV file.

This isn't rocket science. However, using the csv import works for all the versions of Jazz, i.e. makes things less coupled to specific versions.

I'll now choose the CSV file import in DOORS Next and select the module I want to import them into.

I'm treating the model as the 'workshop' where requirements are forged, and the requirements management tool as the 'gallery' where they are exhibited.

Next we need to create a view with just the requirements we want to sync back to the model.

Creating shared views are how we aggregate the requirement artifacts we want to trace to the model (include the name of the module here).

We can now tell Rhapsody to load the view we just created into its remote artifacts package for the RM Project.

Remote artifacts are visible in the Rhapsody browser but stored on the server.

To get my automation to switch the Rhapsody requirements to their Jazz/rm counterparts, I first add them as OSLC links to the requirements package.

Finally, I run a "switch requirements to DOORS NG" command that I added to my profile's right-click menu.

This does the switch on all the diagrams and removes the old requirements

All the requirements are now actually in DOORS Next (Jazz/rm).

Before delivery, I'll also run my profile helper to rename action/event names on activity diagram(s).

I'll now deliver the changes so that OSLC links can be seen in DOORS NG (Jazz/rm).

I can now add a column to DOORS Next to show traceability to model element(s).

My renamed actions are nicer to see here.

To finish off, I'll just publish the diagram to Jazz also. Here's the diagram in the web client.

People can review the requirements and use cases using a web browser. Using my profile, we've created formal requirements that tests and design elements can trace to, in less than 10 minutes ;-)

Interested in Rhapsody customization, MBSE methods or Rhapsody training, then feel free to email me.