AUTOSAR Requirements in Req-IF format

The AUTOSAR partnership provides the requirements that it collected for the AUTOSAR standard in Word format. These cannot only be used for the internal use for AUTOSAR, but also for tool providers. E.g., you want to make sure that you fullfil all the requirements when implementing an RTE.

However, traceability to your development artefacts is not really comfortable with a Word document. With our Word-Table-2-Req-IF importer we simply converted e.g. the AUTOSAR RTE requirements in Req-IF format.


Based on that import into Eclipse RMF, traceability is easily achieved with Yakindu CReMa to:

  • Implementations in C (e.g. for RTE code fragments)
  • Code Generators
  • Models and Model-Elements (e.g. UML)
  • Java-Implementations (e.g. to AUTOSAR tool implementations)
  • Any other artefacts, including word documents



ReqIF/RMF and BIRT: Creating “physical” requirements specifications

Printed documents still play a major role in requirements specifications, since a printed and signed document could be required for legal reasons. A lot of companies have written their own document generators for existing requirement tools to fit their specific needs. However, such reporting tools are very often tied to specific tools APIs and difficult to maintain and evolve.

With ReqIF becoming the requirements exchange standard, the idea of generating a document out of the ReqIF and being independent of specific tools is obvious. There are various technologies that could be used. Obviously, Eclipse RMF provides a full ReqIF reader out-of-the-box. Various technologies could be used to generate reports. We have used, e.g. Apache POI.

However, we also have implemented an ReqIF/RMF data source for the BIRT reporting engine, which gives you a visual designer. Assume that we have a simple ReqIF:


A requirements document in RMF

A requirements document in RMF

Suppose we want to create some reports. With our connector, BIRT is able to analyze the ReqIF definition and provide exactly the attributes that you defined in your ReqIF in the WYSIWYG editor. The elements in brackets are field specifications. The values are taken from the ReqIF document.

Visual BIRT Editor

Visual BIRT Editor

In the Preview Pane, we can immediately see what the report will look like, without having to generate first:

BIRT Preview Pane

BIRT Preview Pane

We can then export to a number of formats:

Report Export

Report Export

And generate pdf. Of course, you can really do fancy layouts with BIRT, not just the plain thing shown here:

ReqIF generated PDF

ReqIF generated PDF

The ReqIF BIRT connector allows for easy reporting of requirements documents. Contact itemis if you are interested.

Requirements and Product Lines (Variants / Feature Models) with ReqIF/RMF

Product Lines and Handling of the complexity of variants is one of the current challenges in many industries. In the engineering process, it is important to find the correct views on the engineering data for the product lines and variants. Requirements engineering is no exception.

Requirements and Variants

In the publicly funded research project IMES, itemis as one of the partners is investigating new tool platforms that seamlessly integrate the software engineering artifacts of OEMs and 1st-tier suppliers. This blog article describes our current implementation of variant handling for requirements. This solution allows the specification of presence conditions (i.e. specifying which requirements are applicable to which features) and the tailoring of the requirements models. We are using the Eclipse technologies Xtext, EFM and RMF – but everything is usable in standalone mode as a Java program from the command line, so it could be generally applied to any tool that handles ReqIF.

Eclipse Feature Model

For the modeling of features, we are using the Eclipse Feature Model Project, which contains meta-models for feature and variant models contributed by Pure Systems, a company specialised on tools for product line and variant management. The project does provide the basic EMF editors, and we added Xtext-based textual editors for features (but they are not part of this blog article).

Presence Conditions

For each requirement, we want to specify for which features the requirement is applicable. A simple selection box is not sufficient, since we might want more powerful expressions (e.g. a requirement applies for a specific car, if it is “sold in the Asian market and it has more then 200 hp”). Since the 2.x version of Xtext, it is easy to write for these expressions. Our Xtext solution examines the feature model and provides the features in the expression language.


The Eclipse Requirement Modeling Framework is the Eclipse-EMF based implementation of the ReqIF standard meta-model for requirements. It is expected that most tools will support the standard with some of the next releases.

Combining technologies

To support product line / variant management with requirements, we have the following steps:

  1. Model the features in the feature model
  2. Model one or more variants in a variant model
  3. Add an additional attribute for the presence condition to your requirements
  4. Define the presence conditions
  5. Run the tool

You will now have a tailored version of your requirements that provide a specific view on the variant. We are using a feature of the ReqIF standard: The hierarchy structure of requirements is not stored in the requirements. Instead, you can have one or more so-called “specification hierarchies”. The elements of these hierarchies are just used to build up the structure, they do not contain any data but only point to the actual requirements. So a requirement can be referenced by zero to one hierarchies.

We create a second hierarchy, that is a copy of the first hierarchy, with the presence conditions applied. So the original data is preserved.

Command Line and GUI

For the standalone version, only the variant model, feature model and an ReqIF file with presence condition attributes are required. So you could basically enter the presence condition in any tool with text input.

For Eclipse-based tooling, we provide additional support for the presence condition. The Xtext editors for the language can be embedded into the ProR editor of RMF, so you will get full content assist, error checking and navigation for your feature models.

ReqIF – Towards a scripting and constraint language

ReqIF is a very flexible meta-model and exchange format definition. The possible attributes of requirements are not predefined, but can be defined within the standard itself. This makes implementation of queries and constraints somewhat more complex. But with Xtext, we can easily create a language that knows about the data model of a ReqIF file and implements a language.

A simple definition of a string attribute “Description” for a requirement type “XType” would look like this in XML:

Because of this flexibility, you will not find just an attribute with the name “Description” in your requirements, but so-called AttributeValues that reference their attribute definitions, which actually define the attribute names.

To retrieve the value of an attribute, you’d have to traverse a requirement’s attribute value, compare the names and fine the object. There is a helper object for that (ReqIF10Util) that comes with RMF:

So, in your code you would have something like ReqIF10Util.getAttributeValueForLabel(element,”Description”). But since AttributeValue is an abstract class, your following code would have quite some case-statements depending on the actual type of AttributeValue, since the ReqIF meta-model does not define an abstract method for retrieving the actual value.

A user friendly language

We don’t want that. What we’d like to do is to have a language where we could just write requirement.Description. Actually, this is very easy to do in Xtext. As an example, we create a Xtext language that allows to specify expressions on requirement objects. It simply references the ReqIF object SpecObjectType and then is followed with an Expression. All is needed is a JvMModelInferrer that creates JvmTypes from the referenced ReqIF model. And voila, a complete editor that knows about the types of the referenced ReqIF and provides their attributes directly:







Description is a defined attribute in ReqIF and can be accessed directly know.

A constraint interpreter

Specifying expressions is nice, but executing is what’s interesting. As you see in the screenshot above, there is an error marker at the expression. It says:


This is because we simply added an interpreter for the language that is executed on the ReqIF model and is integrated into the validator. So if we have a requirement that causes the expression to evaluate to false, an error is flagged.

Further uses

Of course, the constraint evaluation can be integrated in the tabular editor that comes with RMF, called ProR. In addition, there are further uses of the approach

  • Could be used as a query language to filter requirements
  • In combination with Xtend2 expressions might be used for reporting infrastructure
  • It is not only possible to query models, but also to modify models.

Since the Xbase expressions can be both interpreted as well as compiled to Java, this is a fast and flexible infrastructure.

ReqIF and Word Import

About a week ago we’ve uploaded the initial code contribution to  Requirements Modeling Framework (RMF). In addition, we’ve been using the tool and created some additional (not published) utilities.

Word documents are one popular way to document requirements. We too have some requirements in Word format to be imported into ReqIF format. It takes about one page of source code to implement a tool that takes a Word document and converts it to ReqIF (although we are currently not handling text formatting).

ReqIF uses xhtml to store formatted text. So quite some functionality of a Word to ReqIF conversion would go into this transformation.

We have been asked for a PDF to ReqIF conversion as well. However, my experience with commercial pdf to word conversion tools does not make me too optimistic about the feasibility, because the information in the .pdf is probably too low-level.

It turns out that our framework is a powerful tool to provide tools and functionality around ReqIF.

Icon from: <A href=””></A>

Links for the ReqIF Talk at Eclipse Con Europe 2011

If you attended my talk at Eclipse Con Europe on the RMF project, here are a few links that might be useful:

Additional Topics

Next Chance to see:



ReqIF’s XML overhead

XML formats can have a tendency to be a little bit verbose (the AUTOSAR exchange format can be an example for this). To get an impression on the overhead of the ReqIF standard, I fed a document from Project Gutenberg to our Requirements Modeling Framework (see Eclipse Proposal). Breaking down “Antarctic Penguins A Study of Their Social Habits” by George Murray Levick into one requirement per paragraph (what text would be better suited for an open source project than a text about penguins), results in a document with 636 requirements.

The original file size is 198936 bytes, the .reqif is 560221 bytes. That is an overhead of (560221-198936)/636 = 568 bytes per requirement.

The paragraph

is in XML:


In addition, to build an hierarchical structure, each requirement/paragaph needs to have a spec hierarchy.

Bildquellenangabe: tokamuwi  /

ReqIF / RIF and Excel Import and Export

About a week ago we’ve started the Eclipse Project Proposal for a Requirements Modeling Framework. We are having promising results with the data sets that we get from our partners. In addition, we’ve starting implementing some very useful tooling.

As Spreadsheets (i.e. Excel) are very common as a means of data exchange, it would be very useful to have an Excel to ReqIF conversion utility. These would obviously reduce the need for the use of application specific conversion tools, since the data could then be transferred to any tool that supports ReqIF.

In the current import, each line of the Excel table is considered to be a requirement, and the requirement definition for ReqIF is taken from the first line. A small table like

will result in the following parts of the ReqIF-exchange file:



The fragment above is the type definition section of ReqIF. After that, every line of the spread sheet is considered to be a requirement (SpecObject in ReqIF-lingo):


The hierarchical structure is not part of the objects themselves in ReqIF, but an extra section. In this example, the hierarchy is derived from the numbering of the ID field, but we can use any algorithm (right now it is easily adjustable based on regular expressions). This results in the hierarchy structure.

It turns out that our framework is a powerful tool to provide tools and functionality around ReqIF.

 Icon from: <A href=””></A>