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.
Friday, 27 November 2020
IBM Engineering Rhapsody Tip #90 - Switching requirements from Rhapsody to DOORS Next (Intermediate)
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.
Friday, 20 November 2020
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.
Thursday, 12 November 2020
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).
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.
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!