Traceability between UML and Requirements with ProR

Working with Requirements should not be an isolated activity - they interact with many aspects of the development process: progress is tracked by checking how many requirements have been implemented; tests demonstrate that requirements are correctly implemented; elements of the system specification show how requirements will be realized; and much more.

Link UML/SysML elements with Requirements

We demonstrated in the past how requirements and formal specifications can be integrated. We also explained our vision of a similar integration with UML/SysML. A first implementation of such an integration is now available, realized as part of the openETCS project.


For now, the integration is only offered as part of the openETCS tool, rather than as an installable feature.  There are technical reasons, as Papyrus, the component for UML/SysML, has very specific system requirements.  So for now, please download and install openETCS (free), if you are interested in trying out this feature.  This functionality is described in the openETCS documentation.  Therefore, we will focus on the result here, rather than on the steps to get there.

Requirements and UML Model

As a simple example, we will create traces between requirements and a UML Use Case Diagram. As a preparation, we created a use case regarding ProR: Creating a new Requirement.  We also created a UML model, containing an Actor, the Requirements Engineer.  This is shown here:

In order to use the tracing plug-in, some data structures have to be created (the link type and its attributes), and the plug-in must be configured.  This is all described in the openETCS documentation.  Once this is done, linking is performed by dragging from the Model Explorer onto the Specification Editor.  This results in a trace that behaves like a regular link in ProR:

You can see that a link has been created, with the label of the link target being a concise description of the target element (in this case, <Actor> Requirements Engineer).  In the Properties View, you can see all the attributes of the UML element.

Of course, this functionality can be combined with other elements from ProR Essentials, specifically the Suspect Link Feature.  This extends to the UML model.  In other words, if the UML model element changes, than this is detected as well.  Let's try this out and rename the "Requirements Engineer" to simply "User".  This is done in the UML model (the elements in ProR are read-only).  After installing the Essentials and configuring suspect links, this is what you get after renaming the actor:

The link content got updated, and an exclamation mark is shown next to the Target Flag.  If you had updated the link source (the use case title), the Source Flag would have been updated.

Next Steps

For now, the integration only shows a textual representation of the UML element.  In the long run, it would be really powerful to incorporate the graphical representation of the model elements.  Imagine showing a State Diagram in-line with the requirements text: Not as a pasted picture, but as a living model element, that seamlessly integrates both visually and functionally.  That would be a huge step forward.


Reporting for ProR - the Results

Half a year ago, we announced that a student, Said Salem, would work on creating a better reporting solution for ProR in the context of his master thesis.  The good news is: He completed his thesis and passed the exam.  The bad news: The resulting implementations did not mature beyond a prototype stage, meaning that we will not incorporate the results into the RMF code base for now.  He pledged to publish his code on gitHub (some is already there), allowing other parties (including Formal Mind) to pick it up and develop it to maturity.

Download the Thesis (German)Reporting for ReqIF: From Analysis to Evaluation (Master Thesis)

The master thesis is available as PDF, written in German.  The main parts include a problem analysis, three prototypical implementations, and an evaluation of those prototypes with respect to the results of the initial problem analysis.

In the following, you find the highlights from this work.

Problem Analysis

The problem analysis includes the responses to the questionnaire that Mr. Salem distributed, and which resulted in 59 responses.  Many responses came from subscribers of this newsletter, and therefore the result is probably not representative for users of requirements tools, but more for the ProR community:

Next, users had to indicate which features they would consider important in a reporting solution.  Here we observed that some of the dearer features were in fact not related to reporting alone, but were highly desirable features for the user interface.  Filtering, for instance, was the feature with the highest votes, and which would clearly add value in the user interface, in addition to a reporting solution.

In retrospect, the phrasing of the features was in many cases not as good as it could be, leading to ambiguous results:

You'll find more statistics in the actual thesis.

After some analysis, Mr. Salem decided to handle the filter functionality separately and to implement it in the ProR Core, rather than in a specific reporting solution.  Due to the prototypical (incomplete) nature of the implementation, it has not yet been added to the ProR code base.

Reporting with Birt

Birt is a popular reporting framework for Eclipse, which has a rich set of features.  Further, Birt already supports many features "out of the box" that were desired by users, and more.  For instance, Birt supports the creation of reports in various formats, and has an extensive feature set for branding, data analysis (e.g. generation of graphs) and more.

On the flip side, Birt expects its data in a certain structure, and transforming the ReqIF data from ProR into such structures turned out to be tricky.  In addition, Birt does not support hierarchical information natively.  To work around that, in the prototype, the hierarchy is flattened (see Figure).

Reporting with JSON/HTML

This approach introduces an intermediate data format (using the JSON notation).  This accounts for the fact that ReqIF is more complex than needed for generating a report.  The idea is that the intermediate format can be used not only for generating a HTML report, but to generate reports in other formats as well.

Reporting with Excel

Reporting with a tool like Excel is compelling.  For one, many users are familiar with it and know how to customize it.  But more importantly, Excel contains powerful functions for advanced analysis.

In the implementation, the user must provide a template, which allows for reusable branding.  Existing libraries make it easy and fast to implement this functionality.  However, Excel has the same limitation as Birt: It cannot deal (easily) with hierarchies, and in the prototypical implementation, the structure is flattened as well.


By giving weight to the user wishes and evaluating the various implementations against them, Mr. Salem made an attempt to find the "best" solution.  The winner is Birt, closely followed by Excel, with HTML/JSON being a far third.

This result is mainly influenced by filtering, tables, and the desire for Excel as a reporting format.  Thus, this result has to be taken with a grain of salt as well: If a good filter is implemented in the ProR Core, then it would not affect the HTML rating.The maturity of Birt and Excel explains the remaining advantage of those two technologies.

We believe that the findings from this work are quite useful, both to the users of ProR in general, and the developers in particular.  The big downer, of course, is the fact that the resulting prototypes did not reach the level of maturity that we had hoped for.  Should Formal Mind pick up this work to develop it to maturity, we will inform you via our Blog and Newsletter.

What's keeping you from using ProR in production?

The ProR tool already made an impact, both as the reference implementation of the ReqIF standard, and as an important puzzle piece for Eclipse-based Systems Engineering.  But we also know that there is still some work to be done, before ProR becomes fit for industrial use.  For this, we need your help.  Read on to learn how you can tell us what's keeping you from using ProR in production. But before that, we'd like to point out another change:

Newsletter Changes

But before talking about ProR, you may have noticed some changes in the appearance of the newsletter.  First, we used to have two newsletter categories (for requirements and formal methods), which we now unified into one.  Second, we switched to a provider to fulfill the newsletter delivery.  We hope you like the changes and the new appearance.  Of course, you can still receive the content via our RSS feed.

What's Keeping You from Using ProR in Production?

To help you answer this question, so that we can get ProR to a point where it is truly useful, we set up an online forum where you can suggest new features and vote on feature requests.  In particular, please use the vote option to indicate what you would like to see implemented next.  Visit the Forum >>

There is also a community area, where you can engage with other users and ask questions.

We set this forum up specifically for the ProR Essentials, the free extensions to ProR.  In case you don't know, the Eclipse RMF project has its own forum.  But don't worry about posting on the "wrong" forum - we'll monitor all of them.

Last, you'll also see the option to submit requests - this is intended for bug reports and the like.  Again, this is intended for our free Essentials, the Eclipse RMF project has its own bug tracker.  Again, we monitor both and make sure that your concern will be recorded in the right place.

Like ProR? Then Google-Plus it!

If you like ProR and the Requirements Modeling Project, then you can help us with a single click by recommending us on google+.  Visibility helps us to reach more users - and ultimately customers who are co-financing the development of the open source components.  And while we're at it, we are currently in the process of updating the Eclipse RMF Website.  We hope you like the new look, and welcome feedback.  You can google+ us directly on the website, too, with the button in the upper right.

Meet us at ReConf 2014 in Munich

Last, ReConf, the biggest European conference on Requirements Engineering, is coming up in March.  Michael Jastram has been a regular speaker there since 20xx, and will talk about ProR this year in the talk ReqIF als Dreh- und Angelpunkt für Eclipse-basierte Systementwicklung (ReqIF as pivot point for Eclipse-based systems engineering).  A matching article is currently available in the special edition of the German magazine iX Developer Embedded Software.

If you plan on visiting ReConf but haven't booked, yet, then you can get a 7% discount by using Promocode HS_RW_290107.

Mailbox image courtesy of sscreations /
Sign post image courtesy of Tanatat /

Formal Mind wishes you a peaceful holiday season

Another year has passed, and we would like to thank our customers and the users of our technologies for working with us.

The holiday season is a good time for reflecting, and we are proud to see our motto - science for systems engineering - applied in practice.  What we achieved has been made possible by customers who believe in our technologies and who subscribe to our principles.  One of our most valued principles is openness: science should not be an end in itself: It is a means for making this world a better place. We believe that openness acts as a multiplier that increases overall wealth.  Here are three examples of our modest contributions in this respect in 2013:

Prostep ReqIF Implementor Forum: ReqIF is an open standard for the exchange of requirements.  In the implementor forum, competing organizations were peacefully working together to make the standard a success.  We saw Daimler collaborate with Volkswagen and BMW, and we saw IBM collaborate with PTC, and many others.  We acted as a service provider and used the Eclipse Requirements Modeling Framework to make the testing activities efficient and effective.  We are delighted to continue this work next year.

itea 2 openETCS: We are an active participant and work package leader in the openETCS project, which strives to develop an integrated modeling, development, validation and testing framework for leveraging the cost-efficient and reliable implementation of ETCS, the European Train Control System.  A fundamental principle of openETCS is open proofs, where an open toolchain is used for creating an open system description.  This results in lower costs and the avoidance of vendor-lock-in. We look forward to continuing our work in this project next year.

Eclipse RMF Activities: Formal Mind was the main driver in the ongoing development of the Eclipse Requirements Modeling Framework, ensuring releases every two month.  The 0.10.0 release is planned for end of January 2014.  Over the last year, we saw a steady grow of interest in RMF, which is already used in production environments.  Projects like Polarsys, openETCS, ReqCylce, Yakindu and many others either integrate RMF or provide interoperability.  Expect to see lots of progress in 2014.

Much more was happening this year, and while a lot of our activities benefit the community, we don't see a contradiction in our principles if we exploit these contributions commercially, on the contrary: Without a business case, community activities would have to cease altogether.  Therefore, we will continue to serve the commercial market with training, coaching and tailoring of technologies.  Please talk to us - without any obligation - if you think that our technologies could make your organization more efficient and more cost-effective.

We look forward to more innovations and the spread of openness in 2014.  We wish you a peaceful holiday season and a successful 2014.

If you need to comply with ISO 26262, IEC 61508 or similar standards, you may need to work more formal

It's quite impressive how safe cars, planes and trains are today.  Looking at this, it seems that we understand really well how to build reliable systems. This is in part due to safety standards.  When they are not followed, as it seems to have been the case with Toyota, things can go wrong.  Safety standards evolve, for two reasons: They evolve as we learn more about safety, and they evolve, as they need to adapt to the complexity found in today's systems.  That's why they started to recommend the use of formal methods.

Before we look into formal methods, and how they relate to requirements, let's get an overview of safety standards.  The following figure has been taken from the Deploy Wiki, which provides quite a bit of analysis.

Safety Standards

Of particular interest is IEC 61508, as it serves as the basis for domain-specific standards, like ISO 26262.  For instance, it introduces the concept of Safety Integrity Levels (SIL), a relative level of risk-reduction provided by a safety function.  In other words, the SIL level prescribes how reliable a function must be from SIL 1 (low) to SIL 4 (high).

The standards recognize that the use of formal methods is expensive, but they also recognize what formal methods are capable of.  It's no wonder that the standards therefore focus on SIL 4, with respect to formal methods.  As the result, in IEC 61508, formal methods are "highly recommended" for SIL 4 functions.  EN 50128 (rail) even "recommends" them for SIL 1 and 2, and "highly recommends" them for SIL 3 and 4.  In fact, the rail industry is a leader in the adoption of formal methods.

An interesting exception is ISO 26262, which "recommends" formal methods, but "highly recommends" semi-formal methods.  According to the above source, this was due to lobbing by the automotive industry, being concerned about the cost overhead.

What about formal requirements?

When we talk about formal methods, we typically mean that the system description - the specification - has been formalized.  Requirements make up a significant part of the system description.  In practice, there are two approaches: Either the requirements are formalized as well, or a traceability between non-formal requirements and formal specification exists.

While formalizing requirements is possible, acceptance is low.  Rarely are stakeholders putting up with learning the formalism, so that they can understand the requirements.  Nevertheless, it is important to recognize that reading formal models is much easier than writing them.  In safety-critical domains, it can be possible to convince the customer to invest in training the stakeholders to read the formal specs.  Writing can be limited to a small circle of experts.

The opposite approach is to keep the requirements informal, but to establish a traceability to the formal model.  This is often preferred by the stakeholders, but requires discipline in keeping the traceability up to date, especially in the light of change management.  The desire to do this is reflected in the success of SysML, a dialect of UML that embraces the concepts of requirements and requirements traceability.

Seamless traceability

Rather than surrender to the static traceability model of SysML, it is worth while exploring alternative traceability models.  We at Formal Mind developed an approach that leaves sufficient room for stakeholders to express their requirements in natural language, while providing a structure that makes traceability in a formal model (Event-B, in this case), systematic and scalable.  There are countless other approaches, of course, and the challenge is to find the right approach for the project at hand (and taking the existing processes into account).

An important requisite for scalability is tool support, and Eclipse provides a powerful platform for integrating various tools for seamless traceability, as we have shown before.  These solutions have been realized using open source tools, and of course, there are plenty of commercial solutions for traceability around (like reqtify or agosense, to name just two).  Nevertheless, Eclipse contains some industry-strength components, like RMF/ProR, that are used in production environments. Alternatively, Eclipse makes it possible to quickly build prototypes at low cost, to explore different approaches.

More Information

We regularly publish our knowledge and present it at public events, like recently at TdSE (organized by the German chapter of INCOSE), and hopefully next year at ReConf 2014.  We also provide in-house trainings and workshops, covering topics like functional safety, safety standards, requirements traceability or formal modeling.  Please contact us to find out how we can make you more productive.

Image courtesy of tungphoto /

ReqIF is here - what now?

The Requirements Interchange Format (ReqIF) came a long way, ever since its inception in 2004, when members of the Herstellerinitiative Software (HIS), a trade association of five major car manufacturers, decided to commission the creation of a requirements exchange format.  Step by step, the standard became more mature and was changing patronage, until it finally became an international standard of the Object Management Group (OMG), a not-for-profit computer industry standards consortium.

Recently the focus for ReqIF changed from standardization (pretty much done) to applicability. In particular, users and tool vendors are actively ensuring interoperability of the various tools that support ReqIF, by working together in an Implementor Forum that is lead by ProSTEP iViP, an association for the manufacturing industry.  Eight tool vendors work peacefully together to ensure that requirements data exported by one tool can be processed by another.

This is good news for manufacturers and suppliers of industries where requirements are exchanged.  But what does this all mean?  Who is affected, what changes are expected?  This article makes an attempt to answer some of these questions.

Who benefits from ReqIF?

In general, all users that need to exchange requirements can benefit from ReqIF.  In the past, means of exchanging requirements were either lossy or proprietary: Exporting requirements as an Office Document or as a PDF is usually lossy, while proprietary solutions tend to be expensive.  Having an exchange standard makes proprietary mechanisms unnecessary and the exchange data has no or little information loss.

Who is affected by ReqIF?

In the short term, suppliers to automotive manufacturers (OEM), particularly German ones, will probably be affected.  The OEMs participating in the ProSTEP implementor forum are likely to migrate to ReqIF, thereby requiring their suppliers to receive and submit requirements information in the ReqIF format.

Which automotive suppliers use ReqIF, or plan to use it?

Participants of the ProSTEP Implementor Forum are (in alphabetical order) BMW, Daimler, and the Volkswagen Group. There may be more manufacturers that decided not to participate in the forum.

Which tools support ReqIF?

Eight tools are participating in the testing performed by the Implementor Forum: Besides Formal Mind's ProR, participants include PTC Integrity, Rational DOORS, Atego Exerpt, Requisis ReX, IBM DOORS Next, enso managers ReqIF Server, Visure Requirements.  More tool vendors plan on joining the testing effort, and there may be other tools outside the forum's activities.

The open source version of ProR can read and write ReqIF files, thereby allowing the inspection of ReqIF files without any investments.  Formal Mind provides a suite of free extensions called ProR Essentials that can compare ReqIF files (useful for finding out what's changed) and other useful things.  A commercial version that supports the requirements exchange process is in the works.

RIF 1.1a, RIF 1.2, ReqIF 1.0.1, ReqIF 1.1 - which version matters?

Today's activities clearly are concerned with ReqIF.  We are not aware of legacy data exchanges using RIF (any version) that are in production, although there have been pilots using RIF.  Further, all tools mentioned above do support ReqIF 1.0.1 and 1.1.  These two versions have the same schema and are therefore identical, from a tool's point of view. Therefore, we believe that RIF will quickly lose the little significance that it once had. 

Will ReqIF change further?

There is a well-defined change process at the OMG.  For instance, in April 2013, ReqIF 1.1 was released.  However, 1.0.1 and 1.1 have the same schema (only the textual description changed).  We don't expect any major changes in the near and medium future.

Is there an open toolkit for working with ReqIF?

Yes.  The Eclipse Requirements Modeling Framework (RMF) is an open source library that can read, write and manipulate ReqIF. RMF comes with a user interface called ProR, which is a full-fledged tool for working with requirements.  RMF is the first open source reference implementation of ReqIF. Formal Mind provides free and commercial extensions for ProR.

Does ReqIF matter outside the automotive industry?

Yes. For instance, the Topcased project (aviation, driven by Airbus) integrated ProR into their toolchain, thereby supporting ReqIF.  A number of projects that are concerned with Eclipse-based systems engineering are adapting ReqIF, like the Rodin tool for Event-B modeling.  While the automotive industry, as the driver of the standard, is acting as the early adapter, it is clear that impact of a solid standard is having an impact everywhere.

My question was not answered here - what now?

Sorry to hear that.  Please, drop us an email with your question, and we will extend this list over time.

Image courtesy of Master isolated images /

RMF/ProR 0.8.0 available

The RMF team is proud to announce the 0.8.0 version of RMF and ProR (Download) to spice up your summer.  The most visible improvements regards the handling of default values, which we will describe further below.  You can also import examples into your workspace via File | New | Example.... This should be useful to new users, to get an idea of what's possible.

But there are also a number of back-end improvements that either resolve issues or speed up things.  We hope that you will give ProR 0.8.0 a try.  If you have ProR already installed, you can update via Help | Check for Updates.

Creating Better Default Values

The better handling of default values was initiated by François Rey, an external contributor who improved the Datatype Configuration dialog.  In that dialog, you can configure your datatypes with their attributes. And attributes can have default values.  But until now, this was not very intuitive.  You had to right-click an attribute to create a child element, representing the default value.

François made this much more intuitive, by making the default value just another property of the selected attribute.  This is shown in the screenshot to the right, where the default value of a String attribute is set to "<DEFAULT>".

While this works, it makes removing default values difficult in some cases.  Therefore, a context menu has been added which allows the complete removal of the default value, which would be equivalent to removing the child element that was described earlier.

Showing Better Default Values

While at it, we also worked on the Specification Editor and Properties View.  First of all, removing values with a context menu is now also possible in the Properties View.  For instance, there is a conceptual difference in ReqIF between the empty String, or a String Attribute that is not set, even though both look the same.  Until now, a value could not be unset any more, once it was set.  Or to pick up the String example, once  a String was set, it could be changed to anything (including the empty string), but not removed.  Note that the context menu is not available in the Specification Editor, just the Properties View.

But wouldn't it be nice to distinguish default values from explicitly set values? We made that now visible by coloring default values in gray, both in the Properties View and in the Specification View.  This is shown in the screenshot to the right.  Look at the first column. In row 1 is the empty string, while the value in row 3 is not set, resulting in the default value "<DEFAULT>" being shown in gray.  Regular values, as in row 2, are shown in black.  The usefulness of this feature is even more dramatic in the second and third rows, where now manually set values and default values can easily be distinguished.

Use it in Production

ProR is already used in production environments, and we would like to encourage you to try it there.  There are a number of features in the pipeline that will make ProR even better, like advanced reporting and seamless traceability.  And Formal Mind offers the services that you need to feel confident about production use, including professional support, training, and tailoring.  Please contact us to learn more.


Using RMF to integrate your models

We've all seen it: You need to write a spec, so you open Word, write some text, you copy a state diagram from Enterprise Architect, and eventually send it off as a PDF.

Okay, things are slightly better now. In the Eclipse ecosystem, maybe you are using Papyrus for modeling with UML or SysML. You may even use a real requirements tool, like Eclipse ProR. But again, you need to get that diagram into the model, so you will still perform the dreaded copy & paste operation, which will inevitably convert your beautiful model into a lifeless bitmap.

There have been attempts to correct this, for instance by connecting the models with a traceability framework. This is a step forward and allows you to create and analyze your traceability, but it ignores the issue of presentation.

An RMF-based Canvas

What we've been experimenting with, and where we see a lot of potential is RMF-based model integration and traceability. The Requirements Modeling Framework is an established project for working with textual requirements, which uses ReqIF, an OMG standard, as the underlying data model. We noticed that ReqIF already contains everything you need for traceability: atomic requirements ("SpecObjects") that can by customized with an arbitrary number of typed attributes, and traces ("SpecRelations"), that likewise can hold any number of attributes. But on the downside, you are confined to the ReqIF universe: You can only create traces between SpecObjects.

But here is the idea: Introduce SpecObjects that act as proxies. These contain references, which are resolved upon rendering. ProR renders information in a grid structure, not unlike Excel (but with a hierarchy). Every box represents the value of a SpecObject, so it is contained in an atomic fashion, with a neat rectangular border around it.  We've already implemented this for traceability to Event-B (formal) models, but we are currently working on a generic solution for EMF-based models.

So this is the vision: You work within Eclipse, e.g. you create a UML state diagram in Papyrus. You then drag it into ProR (the RMF user interface), where a proxy element is constructed that renders the diagram seamlessly in your specification (in a box with a border around it). Suddenly, what used to be a requirements tool, becomes a drawing board with boxes that can be filled with content from anywhere - content that is referenced, and rendered on demand. The user does not care whether the content is retrieved from another model that is active within Eclipse, or via a web service, or OLSC, from half across the world.

We broadly identified three integration models, that we would like to present here:

Proxy element in text flow

A proxy element can be inserted simply into the flow of SpecObjects, as shown above.  This is the equivalent of "copy and paste" (no traceability), but at least the content is always up to date.  In the above figure, the proxy element is a child (as seen from the indentation), to indicate the parent-child relationship.

Proxy element with additional attributes

A proxy element can be enriched with "normal" attributes, which tightly connects all values - they represent one unit.  This is shown in the above figure, that shows a ReqIF-value and proxy-value next to each other.

Proxy element via SpecRelation

Last, a "classical" traceability can also be realized.  But in contrast to external solutions, we use (ReqIF) SpecRelations for the traceability.  As a result, the link target's name that is shown in the main view is provided by the model (in this example "safety_property (mac)".  The actual value can be inspected in the Properties View, by simply selecting the link target.

Put it to work

Of course, these three approaches can be mixed and matched, to maximize value.  For instance, it makes a lot of sense to establish a linked-based traceability, for instance to check the modeling coverage or to analyze the impact of changes.

There are a number of advantages to this approach: The user can find the most convenient presentation, referencing other content in-line (in a box) or via a link; to analyze the traceability, only the ReqIF data structures have to be known, the analyzer can be oblivious to where the content is pulled from; And last, is is possible to store a cashed version of the content, in addition to the ID. This means that by sharing the ReqIF model, the traceability is shared as well. You could open the exported .reqifz file in Rational DOORS, and you would see all the referenced content (which of course may be stale and cannot be edited here, but hey, it's in DOORS). Even better, you could use DOORS' powerful traceability analysis tools.

Next in line: Papyrus (UML and SysML)

What we just described has been realized and is available for the (Eclipse-based) Rodin platform, which supports the Event-B modeling language. But Event-B is rather exotic.  Therefore, we are working on a Papyurs-integration right now.

Image courtesy of digitalart /

Use Cases with ProR

Use Cases are a popular method for recording requirements.  With little effort, ProR can make recording Use Cases easy and traceable. To demonstrate this, we use ProR itself as an example.  Below is a screenshot of ProR, recording the use case "Create a new SpecObject".  You can download this requirements model from the Eclipse git repository.  In the following, we point out where this model specifically takes advantage of ProR's features, and conclude in the end how further integration with other models (SysML modeling, testing), could be realized.

Line 1: Headline and IDs

The Use Case has an ID (UC-1).  This ID is generated by the ID Presentation.  Also, the line is shown in a large, boldface font.  This has been realized with the Headline Presentation.

Line 1 (below): Link to Actor

Use Cases have a primary actor, which is realized with a link.  In this example, the primary actor is the "Requirements Engineer".  There is a separate document (Specification), where all actors are defined (see screenshot right).  The role "Primary Actor" is also selected from a list of pre-defined roles from a drop-down.

Line 1.1: Explanatory Text

Information text can be added anywhere and does not have an ID (as none is needed)

Lines 1.3, 1.4 and 1.5: Scenarios

Scenarios have their own SpecType.  Via the Headline Presentation, it is also formatted in a more visible manner. In addition, it has a status field, which allow the tracking of the implementation status of the various scenarios.


The result of this approach is a document-like description of use casees.  A handful of SpecTypes are used to manage appearance and to keep the model free of formatting information.  This makes reuse and linking of models outside ProR easier.  References (Actors) and selection lists (Status, Relationship) are used to prevent duplicating of information and to lead and support the requirements engineer in their work.


What we just presented can be realized with ProR stand-alone.  However, we are currently investigating simple integrations that could add significant value.  These include:

UML/SysML (Use Cases, Actors)

Papyrus is an Eclipse-Project that allow UML and SysML modeling.  The approach for modeling use cases could leverage Papyrus for UML/SysML integration.  Such an integration would:

  • Keep UML and ProR Use Cases synchronized: Creating a UML Use Case would automatically generate the corresponding elements in ProR.
  • While in Papyrus, only Use Case ID and name would be shown, the content could be managed (and enriched) with ProR.
  • Use Case-Actor-Associations could still be realized in Papyrus.  But the relationship would appear synchronized in ProR.

The benefit would be a textual representation, as preferred by many stakeholders, while allowing the reuse of modeling element is UML/SysML

Mylyn (Project Management)

Mylyn is a popular tool for bug and feature tracking that seamlessly integrates in Eclipse.  An Integration could create and track a Mylyn issue for each scenario.  The status shown in ProR could be taken directly from Mylyn.  Using Mylyn would abstract the tracking system from the integration: It would not matter whether Mylyn uses (for example) Bugzilla or Jira underneath.

JUnit (Implementation Status)

If would be possible to associate unit tests with individual scenarios. Then a status field could be managed automatically by analyzing the associated unit tests: If only one test fails, the scenario would be marked as broken.


We hope that this little example demonstrates how using a specialized tool can improve the requirements engineering process significantly.  While the integrations do not exists, they could be implemented with a few day's work each by an experienced developer.  The Eclipse ecosystem ensures that the resulting code is compact and maintainable.

Better Link creation with RMF ProR 0.7.0

We are proud to announce the release of RMF ProR 0.7.0 and ProR Essentials 0.7.0.  Download them now from the Eclipse website.  If you already have ProR 0.5.0 or newer, simply update via Help | Check for Updates.

In Version 0.7.0, 16 features and bugs have been implemented/fixed. The biggest visible improvement for users is a new way of creating links between requirements (SpecObjects).

The old way of linking...

Before 0.7.0, linking was established by using drag and drop.  By holding down a modifier key (platform dependent), using drag and drop would not move the dragged elements, but link them instead.  While this works fine, there are some disadvantages to this approach: Only one link at a time would be created; the resulting link was untyped (requiring additional clicks to assign a type); "long distance" linking was tedious.

The old way of linking still exists, but a new way of linking as been added.

... and the new way of linking

With the new approach, starting a link and completing the link are two distinct steps.  Further, linking is not limited to creating one link at a time, but "n to m" linking is possible.  And last, the links can be created with a specific type.  Here is a demonstration on the new link process:

  1. Right-click the element or elements that you would like to link with.  The context menu now contains an entry Initiate Linking.  The number in parentheses indicates how many requirements are selected (see screenshot).
  2. Select the requirement or requirements that you want to link to. Right-click the element or elements to link the previously stored requirements with.  You will now see two additional context menus: Complete Linking to selection and Complete Linking from selection.  The number in parenthesis indicates how many requirements have been stored previously.  In the screenshot below, two elements have been selected, but previously, one requirement has been stored.  You also see that it is still possible to create untyped links, but that all existing types are available (in this case Realizes Link and isRelated Link).
  3. The selection of requirements that the process has been initiated with is not cleared.  Therefore, you can repeat the previous step as many times as you need, to link from/to those stored requirements.

Please spread the word and tell us what you think

We are thrilled that ProR is now being downloaded 200 times every month.  We are genuinely interested in hearing how you use ProR, what is good, what is bad, etc.  Please take a minute or two and tell us.  You can just reply to this email, or use the Formal Mind Forum or the Eclipse Forum.

If you like to hear about ProR, RMF and requirements on a regular basis, consider subscribing to our newsletter.  We send relevant and useful information once or twice a month.  Also, please forward this newsletters to your colleagues.

Our Blogs

We want to share our latest insights regarding formal methods and requirements as well as the latest developments regarding our OpenSource tools, ProB and ProR.  We will post new information roughly twice a month, so you won't be overwhelmed.  You can either subscribe via email (below), subsribe to our RSS Feed or visit this page.


Dr. Michael Jastram

Geschäftsführer / CEO

+49 (162) 274 83 94