ProR / Requirements Engineering

8. Juni: Vortrag in Bonn (kostenlos)

Für die Leser, die Deutsch sprechen und nächsten Montag in der Nähe von Bond sind, könnte die folgende Veranstaltung interessant sein: Michael Jastram wird beim Eclipse DemoCamp den Vortrag "Systementwicklung mit Eclipse in der Lehre" halten. Details hier >>

Teilnehmer erhalten ein kostenloses Exemplar vom formalmind Studio Handbuch (solange der Vorrat reicht)!

This article was published first at Formal Mind.

Why ReqIF is better than RIF

When the ReqIF standard was created, it was called RIF.  Only when the OMG took over the standard, it was renamed: Unfortunately, there was already an established standard called RIF, the W3C Rule Interchange Format.

Today, both ReqIF and RIF exist and are in use.  Many tools support RIF as well, so potential adopters may wonder why to go with the new ReqIF, when there is an established RIF standard around.  Which one to pick?

This article was published first at Formal Mind.

Finally See Big Cells as a Whole

Thousands of users are using formalmind Studio on a regular basis, and we get a lot of positive feedback and words of encouragement.  But there is one thing that drives many users mad: If an attribute is large, then it is not shown as a whole, but "truncated".  This is particularly annoying for embedded images.  While there has been a work-around (using edit mode), this was cumbersome and not really that user-friendly.

Therefore, we finally addressed this issue, by building a new Specification editor.  Don't worry the old one is still there, in case you prefer it.

This article was published first at Formal Mind.

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:

This article was published first at Formal Mind.

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

This article was published first at Formal Mind.

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.

This article was published first at Formal Mind.

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.

This article was published first at Formal Mind.

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 /

This article was published first at Formal Mind.

Reporting for ProR - We need your opinion!

ProR doesn't yet support mature reporting features. Right now only a simple HTML-Version of a requirements document can be generated (you can access this via the print menu). A better visual representation of the requirements document has been requested many times by users. For instance, such a reporting mechanism would support analysis and traceability.

We are pleased to announce that we will develop better reporting in collaboration with the Heinrich-Heine University of Düsseldorf.  This work will be realized in the context of a Master's thesis.  Consequently, the resulting solution will be donated to the Eclipse Foundation and will be open source.

There are several reporting frameworks which could be used for the report generation of ProR. These frameworks offer a diverse range of reporting features.  The choice should be based on the stakeholder needs.

This is where you come in:  We would like to know which reporting features you consider important or not in the scope of requirements management. To ease elicitation, a survey was created to identify these features. It consists of very few questions and should take about three minutes. Based on the survey results we will identify the essential requirements for a reporting tool for ProR and decide which reporting framework would be the best fit.

If you are interested in participating in this survey, just follow the link:

Also, please feel free to forward this request to colleagues, friends and other interested parties.

Image (Reporting) courtesy of [Pong] /

This article was published first at Formal Mind.

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.

This article was published first at Formal Mind.

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.

Contact us

+49 (211) 58 38 84 58


Subscribe to our monthly Newsletter (see what to expect)

By providing your email and clicking "Subscribe", you allow Formal Mind GmbH to send you regular emails regarding requirements knowledge, as well as the occasional message regarding their products and services. I can withdraw my agreement any time.