Posts Tagged ‘RIF’

RIF meets ReqIF

August 9, 2011 6 comments

ReqIF is the new OMG standard for requirements interchange. RIF is the predecessor to it and already supported by many tools like DOORS. RMF delivers both the standards as Ecore models. However, there are quite a few differences between the two standards making them type incompatible.

The main differences lies in,

1. Element naming.
For example, the element RIF is now called REQIF, SpecHierarchyRoot is now Specification and so on.

2. More specification types.
If you know the RIF model already, you would know the concept of SpecTypes. This element allows creation of new types. In RIF and ReqIF, SpecObjects (the instance values)  and SpecRelations (relations between instances) are typed. However, in RIF, both refer to the same SpecType element, where as ReqIF has different types called SpecObjectType for SpecObject, SpecRelationType for SpecRelation and some more new types.

3. More attribute definition and value types.
RIF had only a single attribute definition type called  AttributeDefinitionSimple. ReqIF extends this for different the different data types as AttributeDefinitionIntegerAttributeDefinitionRealAttributeDefinitionString etc. Same for values as AttributeValueIntegerAttributeValueRealAttributeValueString etc.

4. RIF XML uses no XML attributes where as ReqIF uses a lot of them.
For example, IDENTIFIER is an XML element in RIF whereas it is a XML attribute in ReqIF.

This brings us to the question – how do I convert my existing RIF files to the new ReqIF format? Considering the fact that there are a lot of industry samples in RIF format, we thought of writing a RIF to ReqIF converter. The transformer takes in a RIF file and transforms it into a ReqIF, retaining all its contents. You could also do an in-memory transformation between the two models.

This is how a RIF source than we passed to our converter looks like after transformation.

RIF Source

ReqIF Target

2 Fast thrice Furious

August 3, 2011 1 comment

Preparing to make the initial code contribution for RMF, we ran our RIF/ReqIF metamodels through several performance tests. To start with, we tested the load and save times of RIF files based on some industry samples. To get some comparison data, we generated XMI files using the same data held in RIF XML files and tested the load/save time against it. The results are quite promising.

Before we go into the details of the tests, its better to define two components involved in our test comparisons.

  • The customized RIF XML loader (a.k.a RMF Loader) and serializer (a.k.a RMF Serializer) for loading/saving OMG RIF XML files into RIF Ecore metamodel (read more on the metamodel implementation here).
  • The default RIF XMI loader and serializer for  loading/saving RIF XMI files into RIF Ecore model (this is not in the scope of RMF. We use this only to get some comparison).

Here are some highlights from our tests.

  • A 32MB RIF XML file is loaded in 14.4 seconds by RMF loader where as the same data in XMI format is loaded by the default EMF XMI loader in 22.2 seconds (and 70 mins(!!) without any optimizations to the XMI loader)
  • The average time taken to load per MB of data from RIF XML is 0.5 seconds, whereas RIF XMI takes 1.63 seconds per MB. For save, average time taken per MB of data to RIF XML is 0.09 seconds, whereas RIF XMI takes 1.22 seconds per MB
  • The load and save time for RIF XML files by RMF loader/serializer increases linearly with size

Tags: , , , ,

Dissecting RIF/ReqIF metamodel

July 29, 2011 9 comments

RIF/ReqIF is the new OMG standard for requirements interchange. RMF (currently in proposal phase) provides an EMF Ecore based metamodel implementation for the RIF/ReqIF XML format. The metamodel is a clean implementation of the format without any “XML noise”. The Ecore metamodel also conforms to the CMOF metamodel delivered by OMG (as it has been derived from it). The metamodel reads/writes RIF/ReqIF data in conformance with the RIF/ReqIF XML Schema.

The challenge in the Ecore based RIF/ReqIF implementation was the customization of loaders and serializers to make them RIF/ReqIF XML Schema conformant. EMF provides different ways of customizing the XML output.

1. Using ExtendedMetadata annotations.

2. Implementing new XMLLoad, XMLSave and XMLHelper.

Both approaches are quite tricky to implement when the expected XML output has structural differences compared to the Ecore metamodel. For example, the XML output has wrapper elements for lists (ELists) in the Ecore metamodel.

We went in for a third approach.

We imported RIF/ReqIF XML schema using EMF importer to create a RIF/ReqIF XML Ecore model (Anyone who has done this, knows it’s an “ugly” metamodel that EMF generates here). The next step was to create the real RIF/ReqIF metamodel, by importing RIF/ReqIF CMOF file. We then wrote a generic (of course reusable) Ecore XML to Ecore converter to do a model to model transformation in both directions. The whole processing is cleanly hidden in a new EMF Resource implementation such that the user hardly knows anything about these.

The following are the advantages we saw in the approach.

1. You don’t do customizations at a XML level, but at a higher EMF model API level. That is, you don’t hack some XML SAX events, but work with familiar EMF APIs.

2. The generic Ecore converter has enough hooks to plugin in the transformations.

3. Easy maintenance as the customizations are available in one place.

The drawback of this approach could be the processing involved in the model to model transformation. However, the highly optimized model to model transformation we implemented doesn’t make it all that slow. Our performance tests proves this (which would be the topic of my next blog post). It is infact upto 300 times faster than having the same data in the default XMI format (Yes I meant 300! Ed Merks is going to get back to me on this I hope ;) )


Ed did get back to me. With the performance optimizations applied to XMIResource loader to use cache for Intrinsic Ids and URIs, the performance improved dramatically. The XMI resource loader now takes only 22,2s to load a 32MB sample, compared to the earlier 70mins. I am glad that our RIF XMLResource however takes only 14,4s for the same contents.

Tags: , , , , ,

Requirements Modeling Framework (RMF)

July 18, 2011 2 comments

Over the last few months some guys at itemis and Düsseldorf University have been working closely to bring out a solution to the open in an effort to lessen the big gap we have currently in Eclipse Ecosystem in the area of Requirements Management (RM). Requirements Modeling Framework (RMF) has been proposed to Eclipse Foundation as an open source project under Model Development Tools Project.

Scope of RMF

The scope of the project, as described in the proposal, is to provide an implementation for the OMG ReqIF standard (just as the Eclipse UML2 project provides an EMF based metamodel for OMG UML). Requirements management tools could then base their implementation on the provided ReqIF metamodel. It is also in the scope of the project to deliver a requirements authoring tool, again based on the ReqIF metamodel and optionally a generic traceability solution.

Significance of ReqIF

ReqIF (Requirements Interchange Format) is an open standard from OMG for requirements exchange (I had blogged a while ago on how we arrived at ReqIF (earlier called RIF)). Many tools like DOORS already support a snapshot export to this format. Having an EMF based metamodel for ReqIF, opens up the Eclipse framework for integration and new tool development in the area of Requirements Engineering.

ReqIF in a nutshell

ReqIF offers a generic metamodel to capture requirements (The generic nature is at times highly criticized. More on that later). The figure above shows a bird’s-eye view of the metamodel. The metamodel allows creation of requirement types (SpecType) with different attributes types and also instances for it (SpecObject). Since ReqIF also carries the metadata (in the form of SpecTypes), it makes it possible for any tool that understands ReqIF to process the data.

ReqIF also allows creating hierarchy for requirements, grouping them and controlling user access. To support rich text, the metamodel reuses XHTML.

Generic nature and “meta”ness of ReqIF

Anyone expecting a requirements metamodel might be surprised at first when they have a look at ReqIF. You hardly find a term called “requirement” in there. ReqIF is more at a higher meta-level, that is M1. It has been designed this way for a reason.

Requirements Management is an evolving field and until recently never crossed company boundaries. With tighter collaboration between partner companies the benefits of applying RM across company borders became known. The field being highly dominated by commercial products gave barely any chance for standardization. A group of companies in the automotive field, realized that with such a diversity existing hardly any unification is possible. They gave birth to this generic requirements interchange format which was later adopted by OMG and standardized.

The generic structure of ReqIF allows companies to use the tools of their choice to do requirements management and use ReqIF as the standard exchange mechanism and even do round trips. ReqIF is not the only standard to allow this generic nature in the field of Requirements Engineering. DOORS, for example, has an extensible database allowing users to add/delete attributes. The changes to the schema are often communicated to the partners by external means to replicate the changes in their database. Since ReqIF carries the meta-information with it, the changes are migrated automatically across tools/company boundaries. Transmitting the meta-information in ReqIF could however be controlled by tooling. This nevertheless would beat the purpose of ReqIF.

It is also questionable, why such a generic model is required when we have metamodels like UML or EMF already available. The reason for this is very much the same as why EMF co-exists with UML. ReqIF is not a general purpose modeling language like UML or EMF, but more focused on requirements domain.

Integrating ReqIF

RMF provides ReqIF as an EMF based metamodel. This could be used by tool vendors as the internal tool model or an export model by means of model to model transformation. The provided loaders and serializers make sure that the ReqIF file is read/written according to the ReqIF XML Schema.

Using ReqIF natively brings all the advantages of ReqIF to the tooling as well. For example, ReqIF based tools could model the requirements domain of the company within the tooling and share it with partners along with the instance data.

What next?

The initial code contribution is planned by early August 2011 and will be made available as soon as the IP review at Eclipse is complete. If you have any suggestions/comments about RMF, would like to contribute or like to be listed as an interested party, please provide it here.

Images from
Tags: , , , ,

Formal Requirement Specification with Xtext & ProR

May 17, 2011 3 comments

Requirements engineering is a critical yet difficult part of software development. Although a lot has been said and written about using formal methods in Requirements engineering, it is often not practiced. Systems requirements are mostly couched in very high level terms and made comprehensible to end users.  “Formal” Requirement Specifications almost always remains a myth or a specialist thing. A good alternative here would be to use DSLs (Domain Specific Languages) for requirements specification. Or better mix DSLs with an standard requirements specification format like OMG ReqIF. A DSL offers the flexibility of fine tuning the specification language so that it is moderate enough for customers to understand and also for a specialist to process it.

To realize this and as a first step towards filling the void I was talking about last year, a open source toolset has been developed by itemis in collaboration with Düsseldorf University in the scope of VERDE project. The toolset consists of a OMG ReqIF based metamodel, a UI (named ProR) to edit requirements in a DOORS like table view manner and an Xtext extension to integrate DSLs. The tutorial talks about the Xtext extension to ProR editor.

To see the tool in action have a look at the screencast by Ömer Gürsoy

ProR with Xtext Integration


Creating a formal language

Please follow the  Xtext Userguide to learn how to create formal languages using Xtext

Integrating the formal language to ProR

  • Create a new Eclipse plugin Project
  • Add the following plug-in dependencies to the new project.

The last two dependencies are the newly generated plugins for your language by Xtext

  • Create a new extension for the extension point de.itemis.pror.presentation.xtext.configuration.
  • language is the id of the newly created language.
  • extension is the file extension of the newly created language

Please note that this is not the project/plugin id but the language id 

For injector, implement the interface de.itemis.pror.presentation.xtext.core.IXtextInjector or extend de.itemis.pror.presentation.xtext.core.AbstractXtextInjector. The getInjector() method should return the Google injector of your Xtext language UI project. For example,

public class DomainModelInjector extends AbstractXtextInjector {

	public Injector getInjector() {
		return DomainmodelActivator.getInstance().


Please note that it might be necessary to export the *.ui.internal package from the UI project to access the XXXActivator instance as above. We will improve this as soon as Xtext makes the injector public in a different way.

Running ProR with formal language integration

  • Launch the newly created plugins from your workspace which has ProR already in the target

Needless to say, build the newly created plugins and add them to the ProR target after testing

  • Create a new RIF file in ProR
  • Follow ProR documentation and create a datatype for the newly created language. In the example below we use an existing datatype in ProR, T_String32k
  • Create a new Presentation Configuration.
  • For Language enter the Language id of you new language as before

  • For Presentation Datatype, select an existing datatype. T_String32k in the example below

  • Double click on the requirement attribute which is linked to the new datatype in the ProR grid. Description in the example below.
  • A pop-up dialog opens up with a full-fledged editor for the newly created language. The editor supports most Xtext features like syntax highlighting, auto completion, error highlighting etc.

  • Enter your formal description in the editor
  • Click on a different cell to accept the new value
  • Save the file to persist the contents as usual

Filling the void

September 6, 2010 11 comments

The search…

As Andreas blogged a while ago, we at itemis are working on a requirements editor as part of a public research project. Developing a full-fledged requirements management tool is not in the scope of the project. What is of interest is to have a solution to enable traceability from requirements to design, all the way to source code. Looking around for an eclipse based open source solution for requirements management, we realized that this space is currently empty (except for ORMF which somehow didn’t fit our needs or give us confidence).

Having decided to move on with a solution of our own, the next step was to shop for a suitable meta-model for requirements. We weren’t quite unlucky as before here. We had two choices here, SysML or RIF.

SysML or RIF (now ReqIF)

SysML is a general purpose modeling language for systems engineering applications. RIF on the other hand is an interchange format for exchanging requirements between partners. Although SysML and RIF can capture requirements, we found RIF more apt for our needs, as its scope is limited to requirements management. Currently, RIF is up for standardization at OMG with a new name ReqIF.

RIF offers a schema based XML format as well as its UML meta-model in Enterprise Architect. To add to our confidence in RIF, IBM had already incorporated an importer/exporter for the RIF in IBM Rational DOORS . Several other companies, like MKS, are also working on an implementation of the RIF specification.

Bringing RIF to Eclipse world

The first step in building some tooling around RIF was to bring it into an eclipse compatible meta-model. Naturally, the first choice was Ecore, the now de-facto eclipse meta-model. However, converting RIF from an Enterprise Architect format to a Ecore XMI was a herculean task. After failing to do the conversion with the steps I detailed here, we went on a journey of export-import-export from tool to tool and finally had a RIF compatible Ecore meta-model.


The RIF Model

The RIF model is a generic requirements meta-model. (From another perspective, too generic to be called a requirements meta-model). The meta-model allows to define requirement types and requirement objects, fitting one of those types. Take for instance, a typeFunctional Requirement” with attributes such as “ID“, “Name” and “Status“. You could use RIF to create a SpecType named “Functional Requirement” with matching AttributeDefinitions for “ID“, “Name” and “Status” . The AttributeDefinitions could also have DatatypeDefinitions. Based on the defined SpecType you could create SpecObjects having AttributeValues for all the AttributeDefinitions.

This is a birds-eye view of the RIF meta-model.

The Editor

We retained the generic nature of RIF in the editor as well. To start with, you could create type specifications using a tree based editor.

Based on the type specifications, the editor at runtime creates an eclipse forms based user interface, lays it out neatly and lets you edit your requirements. As you could see below, the editor creates a tree to display the requirement hierarchy on the left. On the right, the editor lets you edit the requirement attributes by creating matching UI elements to handle the basic datatypes like StringIntegerEnumeration etc.  you created during RIF type specification using the tree editor.

Editor Extensions

You could easily build extensions to the editor using the provided extension points. If you need a specific UI behavior, you could define a new complex datatype and build UI customizations for this complex datatype.  For example, we extended the basic editor to have an embedded DSL editor (using Xtext) to capture detailed requirements.


The RIF editor loads and writes out XML conforming to the RIF schema.

Filling the void

We aren’t quite there yet. We, of course need more community interest and support to take this forward. Once we do, we hope to fill the void completely and have an open source solution for requirements management.