Rhapsody TechBlog

BLOG about IBM Rhapsody. Contains technical information as well as more private travel stories.

Tag: Requirements

Standard Quality Control Certification Assurance Guarantee Internet Business Technology Concept.

RXF Cert

August 14, 2019 / / 0 Comments

Introduction

The RXF can be bought in a version that is certifiable. So that does not mean it is certified. It is certifiable. That means we have done all work that is done in a certification process, like writing down requirements, connecting them with model elements, creating tests, performing tests and caring about MISRA, coverage etc.

What is the RXF?

It is not an RTOS or an RTE or any other Operating System, also not a driver layer that will give you hardware control.
It is just the functionality that the UML offers that is not available in ‘C’ or ‘C++’. Much of that functionality is implemented by using an RTOS. the RXF is then a sort of Abstraction Layer that makes a unified RTOS API.

When you create an active Class in the UML you tell your audience that this class runs in its own thread. (Or Task or even process but that has some additional difficulties see this article.) This class then should have behaviour, described in either a state-machine or an activity diagram, as it is defined in the UML. There is no other “standard” mechanism, you have to build that yourself. (Remember, the UML is a language, nothing more)

When you use timers in your behaviour diagrams ( like tm(xxx) in a state-machine ) then you will have to use something that times. Either a hardware timer or if you use an RTOS you can use the tick time. But either way: there is no standard ‘C’ or ‘C++’ mechanism for that.

The RXF also takes care of sending and receiving asynchronous events that are used in state-charts.

Certified vs Certifiable

It is very difficult to certify a “half-product” like the RXF. You have to predict all possible uses and much of the functionality depends on the rest of the system. So at best it can be made certifiable. That means that all possible work for a certification is already done, many documents are already there. If you have never gone through a certification process, this is an excellent starting point. The use of modelling is more or less recommended by an increasing number of certification institutes ( They tend to be quite conservative and that is OK! ) so using Rhapsody and the RXF is a huge step forward for setting up your own process.

What is there in the RXF-Cert?

  • Bill of Material (BOM)
    Contains a directory of all documents and deliveries. With exact version numbers and MD5 hashes. Also describes the RXF-Cert system borders and its influences on software development and code generation.
  • RXF-Cert Architectural Model (RCM)
  • High Level Requirements and Specification (SPEC)
  • Requirement Traceability Table (RTT)
    Showing full coverage of requirements through system specifications down to module specifications / implementation and tests.
  • User Manual (UM)
     How to use the RXF in Rhapsody. Includes installation guide and detailed technical descriptions of the RXF-Cert.
  • Validation Plan (ValP) and Validation Report (ValR)
    Describes how we validate the RXF-Cert. Documents reviews of requirements, code and documentation. (Four-eye principle)
  • Test Documentation: Verification Plan (VerP) and Verification Report (VerR)
    • Test Concept and Test Process Description
    • Acceptance Test Specification and Results
    • System Test Specification and Results
    • Unit Test Specification and Results (Model Based using the TestConductor)
    • MISRA Conformance Report:
      how MISRA compliance is implemented and what is done to certify that violations are handled correctly
    • All Tests are part of the delivery and can be re-executed by the customer.
  • Software Safety Plan
    Describes the strategy of safe software development we have followed during development of the RXF-Cert. Explains traceability, document review guidelines and our personal competence.
  • Software Safety Manual
    How is the RXF-Cert intended to be used, what are the restrictions and safety application conditions. Also contains a description of all the functions of the RXF that can be directly called by the user.
  • Tool Manual (TM)
    Lists all tools used in RXF-Cert development including reason for usage, classification, statements for safety related usage and detailed version information.
  • Software Modification Procedure (SMP)
    How modifications and updates of the RXF-Cert are handled.
  • Final Delivery Report (FDR)
    Documents final checks that have been performed when delivering the RXF-Cert.

Vacation time

So. That is what the RXF-Cert is really doing. Literally man-years were invested in creating that. As said, it is a great start for someone who needs to certify his software, many of the pitfalls are already covered.

So. It’s August, it’s vacation time. For me, unfortunately, there is no beach or mountains,, I am moving from my old house to my new house. The latter is not finished so I have to stay in a holiday home for about 4 months. So a sort of vacation… Luckily there is internet there so I will keep writing, don’t worry!

Sunny modelling with Rhapsody and the RXF

Walter van der Heiden ( wvdheiden@willert.de )

Using Rhapsody in vacation time…

August 14, 2018 / / 0 Comments

Vacation!

Hi! And sorry for the low BLOG frequency. It’s vacation time. Not that I am on vacation, that would actually mean I have more time to write… No, I am busy at the moment, others are on vacation which leads to more work and I have a lot to do  privately: I’m building a new house.
That is… I have other people build me a house… As I always say: I have two right hands but unfortunately I am left-handed… (BTW: Today August 13 is international left-hander day!!)
So I do not build but that does not mean my work is done… there is a lot to do besides physically building.
So we did not planned a holiday because the house should have been finished around this time….
“Should have been”?? Yep. It’s not.

When software projects go rogue and take longer than planned, one of the things people (non-involved people…) say is: “These software projects… always late… they should learn how to plan just like the people who build houses.”
Well…. That is just sooo not true.. building projects also go rogue. Mine does but others do as well.
Builders plan but the same way software people plan. So plenty of space for mistakes and “unknown”
In my case the architect designed my house with a CAD tool. Not a very advanced one, I am still waiting on a 3D view…, but that is how he did it. The guy is an artist and he draws beautiful houses. We were very enthusiastic about it and we even got the permission to build it from our community (Yes that is needed in the Netherlands)

There were a lot of prerequisites that we had to comply with, it had to fit in a certain part of our (own!!!) ground and it had to have a straw roof (To make it look like the other farms in the neighbourhood)
I did not want that, I wanted Tesla Tiles that create power, but hey…
So the architect draw the straw roof. The drawings of the architect then have to be enhanced by a constructor that knows how you build a house. Then the builder starts organising sub contractors to deliver parts.
It turned out when he ordered the roof that the angle was not steep enough. So the roofer would do it but with our guarantee.
So back to the drawing board and half a year delay (New permit, new calculations…)
So don’t tell me building houses goes better than building software…

So I asked myself: Would modelling have helped here?
I think so. The fact that a straw roof needs an angle of more than 45º is basic knowledge that should have been a design rule in the CAD program.
Moreover, I have not seen anybody work with a tool like Doors or Polarion to fix the house requirements. It is more advanced than the last time I built a house (1986) but it is with Mail, WhatsApp and Word that the house is built.

Back to Rhapsody

Vacation time is a good time to work on improving your Rhapsody models!
Sometimes customers ask me to do a review on a Rhapsody model. What do I do in a review?
It depends of course but for totally new models I do a couple of steps which I want to share with you:

  1. Check how old the model is. You cannot see it all but you can ask (..) and check if the model has CGCompatibilityPreX.Y Settings. They tell you the conversion already performed on the model (And the fact that the creators did not know what to do with it)
  2. Do a Check Model ( “Tools”, “Check Model”, “<name>” ) This should give you a lot of information about the model. Most common warnings are: “Default Names” and “Empty Description” but there are many more.
    The more warnings, the less precise the model is built
  3. Use Metrics to determine the number of elements in the model. Check for requirements, sequence diagrams and classes. There should be a fair number of requirements and a lot of sequence diagrams. unfortunately IBM stopped using the Metrics in 8.2. There is a more complicated system to still do it.
  4. Use the built-in document creator ( “Tools” “Report on model”, then select only “Include Overridden Properties” ) to look at the overridden properties. This should be limited to profiles.
  5. Do a general check.
    1. How do the names look? Consistent?
    2. How many packages compared to classes?
    3. Are there requirements used?
    4. Are there any Sequence Diagrams?
    5. Little number of properties is OK but not much
    6. What is the number of elements on diagrams. Yes that can be more than the “normal” 7+-2 but they should be understandable
    7. Are comments used?
    8. How is the diagram navigation?
    9. How many level of state-chart are there? One level or at most one sub-state-chart is OK. Everything else must be documented and proved necessary.
    10. Are model elements described in comment?

This is something that you can check yourself…. Do it sometimes.

Happy Modeling with Rhapsody

Greetings from Motown!

Walter van der Heiden (wvdheiden@willert.de)

Development of Safety-critical Software

April 5, 2018 / / 0 Comments

Content

This is also published TechLetter 6, written by Eike Römer. Translated by me and published on the Rhapsody BLOG to allow more people to read it.

The development of safety-critical software is often associated with a certification process. Experiences from the certification environment are presented together with possible work steps.

The procedure is based on the V-model. This Tech-letter covers requirements management, implementation, testing, and end-to-end traceability.

The presented experiences can be adapted to own projects.

Grph - Entwicklung sicherheitskritischer Software-290.png

Practical experience and possible work steps

Creating software for embedded systems in safety-critical areas often requires certification as well. Standards such as IEC 61508 or industry-specific standards are intended to ensure functional safety for safety-critical application areas. In this Techletter practical experiences of the Willert Software Tools GmbH in the range of the software certification are presented.

Example RXF-Cert

Willert develops a so-called semi-finished product, that, being only a part of the software, is being built together with the application software of customers later to create a unit. This unit then must be certified as a whole.

In the specific case, it is the “RXF-Cert” [1], a framework on which the code generator can be based on the UML tool IBM Rational Rhapsody [2] (see Figure 1). In addition to the framework source code and UML model, a “Certification package” is delivered consisting of documents and test suites that facilitate certification in the overall context.

Screen Shot 2018-04-03 at 16.43.06

Figure 1 – RXF-Cert as semi-product in the context of the customers application

Management of Requirements

Probably the most important part of the accompanying documents are the requirements. In order to manage their relationships, versions and status changes, many tools have become established in the market. Such tools are, for example, IBM Rational DOORS® [3] and Polarion [4]. Willert has chosen Polarion for his own use as part of the RXF-Cert project.

Screen Shot 2018-04-03 at 16.44.55

Figure 2 – Specifications and their links in the V-Model

The organization of the requirements has been made in the following levels (see Figure 2)::

  • Customer Requirements (Role of the Customer)
  • System-specification (Role of the SW-Architect)
  • (Software-)Module- and Operation-specification (Role of the developer).

The linking should be defined fixed from the lower level to the next highest level, as a “Satisfies” relationship.

A specification should always have one or more relationships with overlying specifications or requirements. Also links from the resulting software or the source code to the specifications are required here. This makes it clear which code section is used to implement which request (s).

The RXF-Cert comes with a Rhapsody UML model. In addition to the module specification and implementation with the associated code generation, this also contains visualizations of the architecture and of scenarios for more complex processes. In case of a certification diagrams bring the advantage that an auditor can more quickly grasp the construction and implementation of the software. Model elements should also have links to the specifications here.

To create representations for requests in UML tools, there are, for example, the IBM Rational Rhapsody Gateway tools [5] and the Willert ReqXChanger [6] tools. For the RXF-Cert the ReqXChanger, developed by Willert Software Tools, is used that connects e.g. Polarion via the standardized Requirements Interchange Format (ReqIF) and directly supports Rhapsody. Thus, representations for UML elements are also created in the requirements management tool and related to the associated requirements. The associated workflow is visualized later in the document in Figure 5

 

Ensuring functionality through Testing

Certification also requires proof that the functionality is being verified by testing. In a first RXF-Cert project, unit tests and code coverage analyzes were conducted on the basis of manually written C test cases and the gcov tool (from the gcc package) [7] in a test environment. Currently, the effort has been greatly reduced by using the model-based Test-tool BTC TestConductor [8]. In addition, these tests are also performed on the hardware of the target system instead of a PC environment. The results are returned to the test model from the target environment (see Figures 3 and 4).

The test case specification for the unit tests has been linked in the UML model with the implementations of the modules, so that also the test specifications from the model are mirrored in the requirements management tool and in conjunction with the specifications, herewith also a cover and Impact analysis up to the unit tests possible (see Figure 1).

Test Conductor

Figure 3 – Test execution on the target with feedback of the test results into the test model.

Coverage

Figure 4 – Results of the Code Coverage Analysis on the target environment

Cross-phase coverage and impact analysis

Coverage analyzes are important in order to determine, for example, whether all requirements have a test or whether all requirements are linked with software elements. In the approach presented above, coverage analyzes of the UML model can also be performed. From this documents can be generated that can be presented to an auditor.

Impact analyzes are necessary if, for example, requirements are changed during development. One goal is to be able to determine through all levels what needs to be adjusted as a requirement changes. The ReqXChanger can mark changed requests with stereotypes when retransferring requests to the UML tool (see Figure 6). For the certification process, it can be ensured that the software always takes into account the current state of the requirements.

Preparation of documents for certification

Traceability

Figure 5 – Exchange between UML Model und requirement Management

Impact Analysis

Figure 6 – Changed Requirement / Specification obtains Stereotype “Changed” in the model

Creating Certification Documents

From the standard it can be extracted which documentation components are expected. However, combining these into suitable documents and maintaining them involves some work. It therefore makes sense to create an overview document of all delivered goods. Here are source texts, documents and other artifacts of the delivery described and clearly identified including the consistent version numbers. The basics also include adding structure elements to each document, such as a table of contents with page references, a version history, and a cover page with the unique identifier and version. Likewise, a page number indicating the total number of pages on each page in order to be able to verify the completeness.

When recording the requirements, it should be noted from the outset that the corresponding documents must be created for certification. Printing the documents from our internal requirements management with Polarion in an appropriate form requires a lot of effort. The documents managed in Polarion itself can not be used to print the specifications if the links and thus the traceability should also be printed. It is not possible to filter only for specific link types or links to desired targets in the view. One of the consequences of this is that requirements list a relation to the IDs of their chapter headings (these have a hierarchical relationship in the document to each other). A certifier will now stumble upon references that he can not find because headings in the references show the Polarion internal ID, but the header itself does not display an ID. It is therefore strongly recommended that when selecting a tool it is taken into account that it can generate the documents accordingly or how to configure it accordingly. Also with Polarion it is possible via wiki or info pages to prepare the documents for printing accordingly.

Conducting (internal) Reviews

The review of the specification and elements of the software should be done in the requirements management tool. It is helpful to specify that for a “review attribute” (here: “status”) of work items (eg requirements) certain values ​​can only be set one after the other (see Figure 7).

Req Review.png

For the “Specify action”, Polarion has been configured to invite specified users to “approve” the work items. Here are two responsible persons. Only when these persons have both given their “Approval”, a status transition to “Reviewed” is possible. This fact is explained in the supplied validation plan and thus ensures the four-eyes principle in the review process.

Also reviews of models can be managed with this mechanism. In addition, the module specifications specify which SVN revision number (of a checked-in model unit) a review was carried out for. For new revisions, new reviews must be made accordingly.

At the code level, we have had good experience with the Crucible tool [9] and have created a PDF export plugin there that can be used to create code review reports suitable for certification.

Evaluation by a certification consultant

In order to assess the described status independently, we have obtained an evaluation of our procedure by an external certification consultant. This has brought many valuable experience. Among other things, we understood better what content and documents are required by the standard. For example, A security officer must be named in the company, who of course also lives up to his task, and there must be a corporate policy statement on the handling of software security in a “Safety Policy” document.

We have received a lot of positive feedback on the approach and process in development, as well as the approach to meeting the standard. For us in the consultation also the large difference in the standard, whether something is certified as software or as a tool (tool), clear. When you certify a tool, you only have to deal with about one-tenth of the IEC 61508 requirements than with a complete software certification. Nevertheless, we strive to classify our RXF-Cert as software in general. This must also be clearly documented and the user should be made aware of the field of application. If our RXF-Cert were e.g. Not only supporting the development of software, but also the systems engineering, would be added to several other requirements.

In conclusion, we still see the effort associated with certifying software as considerable – but it also shows for us that the requirements of the standard are absolutely meaningful. The development process becomes more sophisticated, the software quality can improve significantly and almost as a by-product the software becomes certifiable.

Passed certifications

The RXF-Cert has now been deployed in several functional safety software projects along with the customer applications. The areas Railway, Automotive and Space are represented. Some of these projects have already successfully passed the certification with the RXF-Cert package, others are currently or will only be in the project status in which the certification will be carried out in the near future. Thus, it has already been shown that the general procedure, meaningful use of tools and careful work steps described in this Techletter make it possible to plan and implement certification according to a standard based on IEC 61508.

Referenced Tools

[1] Willert RXF-Cert, Framework for modeling and code-generation of safety-critical Software:
https://www.willert.de/uml-rxf-cert

[2] IBM Rational Rhapsody, UML-Tool:
https://www.willert.de/rhapsody

[3] IBM Rational DOORS®, Requirements Management:
     https://www.willert.de/doors

[4] Siemens Polarion, Application Lifecycle Management:
https://www.willert.de/polarion/

[5] IBM Rational Rhapsody Gateway, Tool for the exchange and trace of Requirements:
https://www.willert.de/gateway

[6] Willert ReqXChanger, Tool for the exchange and trace of Requirements:
https://www.willert.de/reqxchanger

[7] gcov (from the gcc package), Open Source Tool for Code Coverage Analysis:
https://gcc.gnu.org/onlinedocs/gcc/Gcov.html

[8] IBM Rational TestConductor, Model-based Testing:
http://www.willert.de/testconductor/

[9] Atlassian Crucible, Code Review Tool:
https://de.atlassian.com/software/crucible

 

Happy Modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)
Eike Römer (eroemer@willert.de)

 

 

Nantes – Jules Verne

February 5, 2018 / / 0 Comments

Introduction

The coolest thing about traveling: you always learn new stuff. Not necessarily about modeling but also about the cities and countries that you visit. I had to do work in the nice city of Nantes in France for 3 days. Nantes is about 1000km through the air and a lot more in a car or by train so we took the plane.
When flying, you have the choice when you’re on location, hire a car or use public transportation.
I’ve been to Nantes before and I remembered that they had Uber there and that the traffic is not really “my style” so I decided to do that. The Uber driver told us a lot about Nantes and one of its famous inhabitants: Jules Verne. There is even a museum there. Also there is a warship museum in the harbor where the film “??” was recorded. Not that we had time for that… but nice to know for the next visit.

What Diagram shall I use?

As long as you use UML to document your software, it does not really matter which Diagram you use for what. It does not even matter if you use the UML correctly. Or even worse, you don’t know while you cannot check if you use the UML correctly. At least in Rhapsody you can generate code to check if your model does what you specified. But there is enough left to do wrong… you can only generate code from Class-, Object-, Package-, State-machine- and activity Diagrams.

Admitted, the UML is not clear on when to use what diagram. The argument for not having that is that it is a programming language. “C does not tell you when to you which statement either”. Correct but if someone else does something in a certain way, that does not force me to do the same….

So the UML lacks a “process” that divides your development in stages with deliverables and rules on what to use when and how.

V-Model

The V-model is still used widely in software development. As it should be because it is a proven way to develop software. The exact way it is used changed over the last decades. From a waterfall model where each stage was finished completely before starting the next to the agile process we use now that makes the V-model more a system where you store your development artifacts.

Process

There are numerous processes that describe how to develop software. Some of them are more common and some of them specify UML or even Rhapsody specific, like IBM’s Harmony. Older processes are still used like RUP from rational, Ropes from Bruce and many more like Automotive Spice (a-spice)
You don’t need to try and follow these processes, you can use them to describe your own process. How thorough you do that is mostly depending on the safety level of your software. Railway systems or cars or planes have huge processes that require really thoroughly described steps.

Requirements

When you don’t know what to do, you cannot do it. So you first have to be clear on what it is that you are building. This is a difficult part for experienced software developers… We (Yes I am a software developer…) are very solution oriented. If somebody describes a problem to us we immediately start to think solution. Write down the real requirements of your product. Concentrate on “What do I need” not on “How do I do that”. You can use a Requirements Management Tool like DOORS (Next) or Polarion or even Word or Excel (Not good for linking and traceability but will work)

May be you are lucky and you will receive the requirements from your stakeholder, like in the Automotive industry.

Then import the requirements in your UML model. In Rhapsody you can use either the Gateway of the Willert RequirementXChanger. These tools will create a package with your requirements. They can even synchronize them if the requirements change and mark the changed requirements accordingly so you can do impact analysis on changes.

What diagram should you use for requirements? That is a good question since the UML does not know a requirement diagram. There are a couple of possibilities in Rhapsody, you can stereotype an OMD (Object Model Diagram) as a new term “Requirement Diagram”. Very elegant way, Rhapsody creates a category for new Terms so that you see them as a folder in the browser. Another possibility is to not show the requirements on diagrams but to create a table where you have the requirements on one axis and your linked model elements on the other. Have a dependency with “trace” stereotype as cell item and you can link requirements very easily. Also possible is to drag your requirements in the diagrams where you have the model elements that you want to link. This will make your diagrams messy but there is a solution for that too! You can apply filters (actually queries) to your diagrams and blend out certain elements.

Analysis

The next step is to analyze your requirements and create diagrams where you extract behavior.
The Diagram of choice here is a Sequence Diagram (At least that is my opinion) The nice thing about Sequence Diagrams is:

  • Even non-techies understand SD’s
  • They are easy to draw
  • They can be used for tests!

You just start drawing the first diagram by treating your system as a black-box, defining what output you expect for certain input. You then create new SD’s by refining the first one  in horizontal way (splitting up the system in sub-systems, then sub-sub-systems until you are at Class level) and vertical way (split the functions in sub-functions and so on…)
You can use Class Diagrams (Or Object Model Diagrams) to already start drawing your system architecture that you find out when drawing the SD’s.
Some use Activity Diagrams or even State-charts for this part. There is nothing against that, I just don’t like it. Activity Diagrams are more or less OK but I think State-charts are just too complicated and distract your mind too much during analysing your system. Also if you need to speak with non-technical people about the exact requirements of the system, State-charts are much less “natural” to use.

Design/Implementation

Here you use the same diagrams as in the Analysis and now it is time for state-machines. Together with the state-machines you start creating tests for all your sequence diagrams, in that way you can immediately test if what you have created is correct. And even better: you can do so whenever you have made changes.
This allows you to do Analysis/Design/Implementation in a sort of spiral model. Just keep adding small pieces of functionality, keep starting automated tests (using Test Conductor) and you always have a working system.

Some pictures from Nantes

That’s it for today, happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Even Paradise has Requirements

November 20, 2017 / / 2 Comments

Just another day in Paradise

Just before flying back to Europe I spend a weekend at my Friend Arno’s place in Florida. The USA contains both paradise and hell. Florida is paradise, Las Vegas is hell. I hate Las Vegas. But I love Florida, especially South-West Florida. Weather is really nice there, nature is beautiful. You can see all kinds of plants and animals that we don’t have at home. Hence the title picture. Normally I buy photo’s, this one was taken by me.

The USA has it’s nice things, Unsweetened Ice-Tea, free Re-Fills, brilliant weather. It has its flaw-backs as well…. But not too much in Florida…

This morning I woke up early to have some time to take a cup of coffee with Arno, who has to work today, before leaving for the airport. When I got out to the terrace next to the pool I noticed that it was not too warm. My friend Arno and his wife were both freezing… they already live in Florida for a long time and think that 14º C is very very cold. My European body reacted totally different, i thought it was nice and almost warm… That was 7am, on 9am it was already way over 20º…. things were back to normal… Also paradise has its requirements…. no temperature under 70ºF….;-)

Requirements

Speaking about requirements…. How do you get requirements in Rhapsody? There are a number of ways to do so. It also depends on what Requirements management tool you are using.

  • Managing them in Rhapsody. You can do that but you will not like it that much. It is tiresome to handle requirements, there is not much overview and linking is a pain in the….. For a small program like a Stopwatch it is OK but anything bigger this is a no-go.
  • Use DOORS to manage your requirements. Wait… Doors is old? Well, that depends. There are a large number of companies out there that use Doors since years and have large databases full of requirements, and mostly a complete workflow around the Tool using scripts and much more. Since Doors is still supported and even developed (to some extent) by IBM it is not a bad choice. You can synchronize your Requirements from Doors to Rhapsody using GateWay (Which is actually a Tool called Reqtify and is being maintained by a french company called Dassault (Yes, the ones that bought NoMagic) It can sync your Requirements between Rhapsody and Doors and it is fully configurable so you can also use it for other tools then Doors and you can select how you sync the Doors information in Rhapsody. It is and add-on tool, you have to pay for it. A cheaper and also very nice way to sync your Requirements between Doors and Rhapsody is the Willert Software Tools ReqXChanger. It uses the ReqIF format to exchange Requirements, it is also configurable so you can determine the exact information that you want to sync. In the latest version it can also exchange diagrams between Doors and Rhapsody!
  • Use Doors Next (DNG) to manage your Requirements. This uses the Jazz Database to store Requirements and something called OSLC to sync the Requirements with other Tools. You would have to use Design Manager or the new Model Manager in Rhapsody to sync your Requirements with that. Design Manager and in lesser extent Model Manager need powerful hardware to run on. So if you are looking for a more “light-weight” solution, you can also consider our ReqXChanger, it is a low-price and low-performance using solution to exchange your requirements. You can still use it in a batch way (For instance in a nightly-build) to automatically keep Requirements and tracing information up-to-date.
  • Use non-IBM Tools (like Polarion) to manage your requirements. Syncing can still be done with ReqXChanger. This is a big advantage of the ReqXChanger, it is very flexible in where you can use it. If you change your Requirement Management Tool (Or even your modeling tool…. but we will not talk about that….) you can continue using the ReqXChanger. If you use another tool then the named one and you would like to sync with Rhapsody, feel free to contact me!

Kicked out of Paradise

So. It’s time to pack and leave paradise… Modeling is definitively nicer if you do it in the sun with a glass of Ice-Tea. But modeling beats text-based programming always. Even when it’s cold outside.

Happy Modeling (and requirements implementing) with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

© 2026 Rhapsody TechBlog

Theme by Anders Noren — Up ↑