Part 2a 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.

In part one of this series we introduced the concept of practical examples to utilizing Rational Engineering Lifecycle Manager (RELM) technology and our products, and provided the first example. For part two of this series, we will follow up and explore other RELM based solutions that help answer tough System Engineering questions.

Let’s dive into the second use case.

Many users struggle with the detection of propagated requirement changes. These changes could be of two types:

• Within the requirement tool. This is the case, for example, when users have a Rational DOORS “User requirement module” which is tracing to downstream “System Requirements Module”.
• Across tools. This is the case, for example, when users have a DOORS “User requirement module” which is covered by test case in a “User Requirements Test Plan” in a Quality Management tool such as Rational Quality Manager (RQM). Another typical example is mapping requirements to model elements (such as Blocks or Use Cases) in a modeling Architecture Management tool such as Rational Rhapsody.

The focus of this blog post will be the second type – the cross tool use case.

Many possible workflows can tackle this challenge. These workflows vary in the level of complexity and sophistication, and user usually match the process they employ with the complexity of their data, organization, supply chain etc. Some workflows are more structured and controlled (e.g. using change requests and approval cycles), others use the notion of “Suspect Links” , and some may simply need to create situational awareness to change propagation. By situational awareness we mean that users need to be able to answer the following few simple questions in a quick and efficient way. Examples of these questions might be:

• For all the system requirements changed since last Monday, did we also modify (or review/approve) the test cases?
• For all the requirements changed during this quarter, did we also update the use cases?

The main focus of this blog post is rapid, lightweight situational change awareness. We will describe other change propagation mechanisms and methods (such as suspect links) in another blog post.

Readers of part 1 of this series may have already guessed what follows here (and if you have not read Part 1, you should!). We built a sample data set to demonstrate this usage pattern using a RELM view, like this:

RELM view showing Requiremets, Test Cases, Use Cases - and color coding modification dates

The yellow boxes in the picture above are recently changed requirements (we’ll touch upon the definition of recently in the next section). Each such requirement is mapped to related test cases (using the Validated By OSLC link type) and Use Cases (using the Satisfied By OSLC link type).

The important thing to notice in this view is the red and gray color coding for the Test Cases and Use Cases. As can be seen in the legend on the right:

• Gray: Artifact CHANGED AFTER the requirement had changed
• Red: Artifact NOT CHANGED AFTER the requirement had changed

Obviously, the mere notion of change and time stamps does not enforce compliance. It just means that a user modified the test case after modifying the requirement.

Now let us explore the flow. If a user clicks on the AMR-SR-56 Test Case (showing up in red) RELM will open the RQM window. Once in RQM, the user can modify the test case to accommodate the requirement change. Once saved in RQM, coming back to the RELM view and refreshing the diagram, will immidiatly change the Test Case color to Gray like this:

Same view, after change made to a test case

Back to the definition of “recently”. You may recall (and as we demonstrated in part 1 of this series) – views are parametrized. In this example, we chose to use a date and time as input parameter to the view. This essentially constitutes a cutoff date for the requirements change, and practically defines the set of requirements participating in the view results. See example here:

Change of cutoff date for requirements inclusion in view

After change of cutoff date, the set of requirement may be narrowed as seen in this picture, which only includes two requirements:

Same view - limited to a narrow time window

With this information users can very quickly navigate to both Use Cases and Test Cases – and assess the impact of requirement changes. Again, as in part 1 of this series, a 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.

Now, we’ll take a look “under the hood” and provide additional in depth information on this view and the queries behind it. Also, stay tuned for part three of the series, which will explore other aspects of this technology, serving more complex needs.

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