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.

Reflections on last weeks training - picking a user's own example

Last week I did another 3-day remote Rhapsody training for customers of an IBM business partner again. It still amazes me how much there is in SysML and Rhapsody to teach and it's not easy in 3 days. What seemed to work well this time was to actually model the use cases of their system with them. I think this brought into perspective how it might add value in their context. I doubt that 3 days is enough to learn Rhapsody but I think that it provides a solid foundation level of knowledge to then use, to make decisions about how to apply, and also the importance of adapting the training to the participants to make it relevant and fun. 

IBM Engineering Rhapsody Tip #89 - Exploring how RMM has changed, 6.0.6 to 7.0.1 - Part 2 of 2 (Intermediate)

This is the second of two videos that explores how Jazz-based Rhapsody Model Manager workings have changed in the 3 releases from 6.0.6 to  7.0.1. It follows on from tip #88. The main change is that the /am functionality is now provided as an extension to the /ccm application. This means that work items and model management are stored in the same repository. There is also a new license that enables the /ccm server to be used for either just Rhapsody models, or Rhapsody models and source code. In this caption-based video I look at a few aspects of using 7.0.1, including associating changes to work items, and being able to do more functions like accepting change sets directly from the Rhapsody browser. I also recap how to establish links to requirements in the IBM Engineering Requirements Management DOORS Next application (/rm) - although this is not new.

Here's the transcript in case it helps:

In this silent video, I look at enhancements added between 6.0.6 and 7.0.1 in Rhapsody Model Manager (RMM) - the server-side technology for managing Rhapsody projects in IBM's Jazz platform.

Remember, in 7.0.x Jazz, RMM is now part of the /ccm application, not a separate /am application.

This makes integrated work item planning easier, as it's now managed by the same /ccm Jazz application as the change sets.

In 7.0.1, a new RMM license called "Model Manager - Systems and Software Engineer" is used rather than the "Design Manager" license.

Let's make changes to our model under RMM 7.0.1 control.

As in 6.0.6, I can also add OSLC links to requirements stored in the Jazz-based DOORS Next.

From Rhapsody menus, we can exploit Jazz governance and change tracking, e.g., associating changes with work items in /ccm.

Here we can see that the change set has been attached to the work item.

The Engineering Workflow Manager (EWM) Eclipse client still provide more advanced configuration management features such as work item editing.

Tight integration between model management and change management means that linked data and history is automatically captured.

You can also manage things like approvals and reviews using work items linked to elements under review.

Another key theme  in the 3 releases since 6.0.6 has been additional menus enabling more EWM commands in the  Rhapsody browser. Let's switch user.

Having got Bob to deliver his changes, I've switched user to Deb now.

She's notified of Bob's changes.

She can see there are changes directly in the Rhapsody browser from the descandant overlay icons.

She doesn't need to leave the Rhapsody client to know that changes have been made.

This is new! In 9.0.1 Rhapsody, she can accept incoming change sets directly from the Rhapsody menus.

Her Rhapsody model has been updated with the changes made by Bob.

To finish off, let's have a look at the RhapsodyModelManager > Requirements Coverage Table.

Here we can see the traceability that the elements in this package have with requirements, including those in DOORS Next.

Interested in RMM or Rhapsody training/customisations? Email me.

IBM Engineering Rhapsody Tip #88 - Exploring how RMM has changed, 6.0.6 to 7.0.1 - Part 1 of 2 (Intermediate)

One of the areas where the IBM Engineering Rhapsody development invested a lot of effort in the last 3-4 releases is in its integration into the IBM Jazz platform with the Rhapsody Model Manager (RMM) server-side technology. This is crucial, of course, for its integration with DOORS Next generation, IBM's web-based Requirements Management (RM) technology built on top of Jazz. RMM also enables web views of the model and linking with work items and planning and shared configured access to models. In version 7 of Jazz there was a significant change, in that the functionality provided by the /am application became an extension to the /ccm application, rather than a separate entity. Over the releases they've also done work to make more functionality available directly in the Rhapsody browser. In this first of two videos, I wanted to give some examples of things that have changed (especially to those who are user older versions and thinking of migrating).

Here's the transcript of Part 1:

Rhapsody Model Manager (RMM) is the server-side technology for managing Rhapsody projects in the IBM Jazz platform.

To enable me to create/update my training for different Jazz releases, I've installed a local 7.0.1 Jazz server using a Hyper-V virtual machine (in Windows 10 Pro).

In this silent video, I look at some of the key differences I've noticed in the 3 releases from RMM 6.0.6 to 7.0.1.

An obvious change is the renaming. Engineering Workflow Management is the new name for Rational Team Concert.

Not too many changes in the Eclipse client. It still performs the role of allowing access to  deeper workflow management features.

There's still lots of stuff available here like baselining, data feeds, diff/merge, work item editing, creating components and workspaces.

Let's launch Rhapsody 9.0.1 for the 7.0.1 server. This too has been renamed for 9.x (dropping the 'Rational' branding).

This project has been disconnected from the server, so l need to re-attach it to the server.

As before, status icons show use the status of units under configuration management.

There's some new functionality related to seeing the descendant unit's status though.

The smaller overlay icon in the top-right, tells me that a child unit has changed enabling me to know where changes are in the tree.

Also, the older Team Concert menus are now split across the Unit and Unit with descendants menus.

The Unit with descendants menus makes it easier to do SCM functions further up in the browser tree, e.g., deliver or accept changes.

The status icons are updated and the output window includes slightly more information than in 6.0.6.

Let's try making a diagram change.

As usual with Rhapsody, there are some properties that will control behavior, e.g. diagrams will be updated on deliver according to this policy.

The default Save policy will be to check in the changes and Deliver will deliver the changes and update the web views.

You may notice a bit more information in the web client (compared with 6.0.6) and the diagram was updated (actually this was in 6.0.6.1/Rhapsody 8.4 also).

So, here's the biggest change in 7.0.x. No, not the black bar, but rather  the /ccm application has taken on the role of RMM as well.

Let's review of the Jazz applications.

Engineering Insights is what used to be called RELM.

"DOORS Next" name makes an appearance in the menus (/rm).

Quality Manager is Test Management (/qm).

Team Concert is Workflow Management (/ccm).

/am is no longer a separate Jazz application. It's combined into the /ccm application (when installed correctly, the /ccm project area can be configured to enable model management)

This makes it easier to install/deploy but is something to consider when upgrading from pre-V7.0 servers. It also means that a same /ccm project area can provide access to both model information and work items.

I'll cover this in Part 2 and also the ability to accept changes from the Rhapsody menus (stay tuned ;-)

Interested in RMM or Rhapsody training/customizations? Email me.

Requirements Management awareness training - Star Wars, a new hope?

This week I did another (free) workshop with the engineering apprentices on Requirements Management. I learnt that there's hope for Star Wars yet. At least one 3 year girl with Star Wars wallpaper, duvet and a Lightsaber (I think this is a new hope?). I think this means it's just skipping a generation. 

What else? Well, requirements can get a bit messy to begin with, especially if you're messing around with different tools - Teams whiteboards/Google jamboards (hey that's like reality till you get proper in place right ;-). 

I also learnt that engineering apprentices are more creative at creating requirements for an Ironman suit than I am (no surprise there). Alas, I didn't get them all into an RM tool in time though.

Also, a well timed Kahoot quiz, leaves nowhere to hide ;-) This is actually quite a fun thing to do with online training. I might do a bit more using this going forward.

MBSE Awareness training - Star Wars is not a thing, apparently?

Last week I did some (free) MBSE awareness training with some engineering apprentices. I learnt that "star wars" is not a thing. Apparently, there is a film called "ironman" that I should've watched and that ironman is not ironman until he puts on some "special" suit, and that the suit actually can make it's own decisions (which is important to know upfront but sounds a bit dangerous to me ;-)

Subsequently, I did find out from Barclay Brown that Jarvis (actually an acronym) is the AI that Tony uses, and is distributed with parts of it executing in the suit and parts executing on servers in Tony's Malibu basement or elsewhere in the cloud we hope, at least when the Malibu house is destroyed. In any case, Jarvis should be an actor. Also, the suit is able to communicate with and control other suits (depending on which movie you are referencing). The suit may also communicate with some kind of enclosure, like the briefcase in Ironman 3 (?), though the briefcase could perhaps be considered part of the suit, especially if it goes WITH the suit after suit deployment. For yet more subtlety, it seems that the suit can have a 'guest' wearer, who is more like a passenger, with the suit being controlled externally, such as when Tony puts the suit on Pepper to protect her from the attack on the house, so perhaps guest/passenger should be an actor!