Part 1a of “Using Rational Engineering Lifecycle Manager to answer hard Systems Engineering questions” blog series

Preamble: Our users have been asking us for more practical examples about how to unleash the power of linked lifecycle data in Rational Engineering Lifecycle Manager (RELM), so we have decided to kick off a blog series on the Jazz Team Blog to answer some of your most pressing questions! All of the examples that we will be providing in this blog series were created with problems IBM System Engineering domain users encounter, so many SSE customers will find these examples very relevant to their own process, and will be able to easily adapt the proposed solutions to their own needs. In previous blogs and postings related to RELM, members of our team explained the conceptual value of linked data, as well as provided overview of the Systems & Software Engineering (SSE) solution along with deployment tips, so you may want to start there if you are new to RELM and SSE. Without further ado, let’s dive into the first use case!

When we discussed model based system engineering process with a leading customer from the aerospace and defense domain, we talked about “understanding the impact of change”. In many cases, when we discuss impact analysis, the change flows “top down” along the lines of “a user requirement changed, now let’s understand the impact on system requirement”. The customer explained that coping with change is often way more complicated than this and tracing changes could is more of an exercise of understanding links from “top down” as well as “bottom up” with added “sideways” links. The example the customer gave us was along the lines of:

We took some time to think about the user’s challenge and we quickly realized that RELM could easily solve this type of problem. We decided to test this out: The next step was to build the SSE data that support the scenario. We built a Rational Rhapsody model, a Rational DOORS module, and Rational Quality Manager (RQM) test plan, with OSLC links across the lifecycle. Cross-tool links are OSLC links (e.g. use cases in Rhapsody to Requirements in DOORS), but many of the links in the scenario described above are in fact internal to Rhapsody (e.g. activity diagram nodes calling operations on blocks).

For example – these are snapshots of a diagram and a matrix showing relations of DOORS requirements to Rhapsody model elements. These are <<Satisfy>> links that you see on the diagrams (or matrix cells) and they are in fact OSLC links:

Rhapsody Matrix Showing Use Cases and DOORS requirements linked using OSLC

Rhapsody diagram showing Use Cases and Requirements

On the other hand, this is the Rhapsody diagram showing mapping of physical blocks to logical blocks. The links in the diagram are SysML <<allocate>> links, internal to Rhapsody:

Rhapsody SysML diagram showing Physical to Logical block allocation mapping

Armed with the sample data, we took the next step: building a RELM view that shows… well… what the customer asked to see. The idea was to build a view that clearly shows the “big picture” (no pun intended) by walking the trace graph:

• Physical blocks to Logical blocks
• Logical blocks to Operations
• Operations to the activity diagrams they are called from
• Activity diagrams to the Use Cases they serve
• Use Cases to the Requirements they satisfy
• Requirements to the Test Cases covering them

The result can be seen here:

RELM View showing a Physical Block with lifecycle links (across tools)

On the very top-right side of the view (in orange color) you can see the Physical Block name is “WaterMeter”. However, note that we treat this view as a utility – it is not hard wired to a specific named physical block. Instead, it takes physical block as an input parameter. As RELM introduces the concept of parametrized view, it made sense to use this capability, like this – note the dialog box titled “set parameter value for the view”:

RELM View Parameter Setting Prompt

And, when another physical block is set as input, the result is of course different, as seen here:

Same view - different results

Note that in the first picture, some test cases are in fact not RQM test cases but Rhapsody TestConductor test cases mapped directly to operations on blocks. On this second view however, no such test cases exist. You may also notice that in the first view, the physical block is mapped to a single logical block, whereas in the second view the physical block is mapped to two logical blocks.

This view can retrieve the end-to-end information in a concise manner, very quickly, saving a lot of time and effort – following the user needs.

Take a look “under the hood” in part 1b of this series, “Under the hood: Understand the impact of proposed changes using Rational Engineering Lifecycle Manager“.

Doron Ben-Ari
STSM, Systems & Software Engineering
dbenari@us.ibm.com