Open Up

But about two years ago, a frenzy caught the tool market, triggered by a format called ReqIF, which stands for Requirements Interchange Format [ReqIF]. ReqIF is a format for exchanging requirements, including their associated metadata and traceability information. It is an open, international standard by the Object Management Group (OMG), which is best known for standardizing the Unified Modeling Language (UML). With ReqIF, it is possible to exchange requirements lossless between parties.

Outsiders were wondering where this standard suddenly came from. Insiders remembered that in 2004, a trade association of the automotive industry [HIS] got together to discuss requirements exchange. The meeting was triggered by the fact that back then, requirements exchange was either lossy (using PDF or Office Export), or locked into a proprietary solution, which all parties involved had to use. This group commissioned the creation of both a standard and an implementation. Both were realized, and there was some talk about this at relevant conferences. And then it seemed as if the topic had died.

But hidden from public eyes, work continued. After a few revisions to the standard and a more and more stringent standardization, interest and visibility returned. Today, there are dozens of tools that support (or claim to support) ReqIF. Big automotive OEMs are preparing pilots for ReqIF-based supplier exchange. It feels as if the critical mass has been reached, and that ReqIF is here to stay.

It's not the first time that an open standard disrupted an industry, and the effects of industry acceptance of ReqIF cannot be underestimated. A prominent example from the past is the standardization of UML, the unified modeling language. In the early 1990ies, there were several moderately successful modeling languages, typically with proprietary tool support. But the breakthrough came only after the main proponents got together to unify their modeling languages. The three drivers were Booch, Jacobsen and Rumbaugh, also known as the “three amigos”. UML was standardized in 1997 by the OMG, and this triggered a frenzy of activities. New tools appeared, but most importantly, organizations were willing to train their personnel in UML, as they were not afraid of vendor lock-in any more. Some notable results of the standardization of UML are cheap tools (e.g. Enterprise Architect by Sparx Systems), open source reference implementations (e.g. Eclipse Papyrus) and an ongoing evolution of the standard.

1. Problem & History

Ever since people started developing things, they have been concerned with recording the requirements that describe the problem that has to be solved: the thing that has to be built. This worked reasonably well for a long time. But towards the end of the last century, three things happened: (1) Systems were quickly getting significantly more complex, (2) production was increasingly outsourced to suppliers, and (3) electronic data processing triggered a move from a paper-based workflow to a digital one. Consequently, the first requirements tools felt more like text processors and were designed to mimic the paper-based artifacts.

A prominent tool that quickly gained popularity especially in the automotive industry was DOORS, today the property of IBM. When DOORS was introduced roughly 25 years ago, people liked that it could import documents from Microsoft Office in a way that would broadly keep their appearance intact, while enhancing it with features that were necessary for professional requirements management. Users could work with arbitrary attributes (i.e. status fields, priorities, etc.) and create traces between artifacts. DOORS was using a central database for teamwork within organizations, but for collaboration with suppliers typically exports in formats like PDF or Word would be created.

1.1. Lossy Exports

As users discovered the power of DOORS and similar products, they started to use more and more of the advanced features. This in turn resulted in more and more information being lost in an export.

As an example, consider an OEM creating a requirement specification for a supplier. Typically, the supplier needs to provide comments, requirement by requirement. Doing this using a PDF is hard to automate. Using Excel with additional columns is doable, but Excel will struggle with visualizing all original content (e.g. images or embedded objects).

Eventually, the supplier will produce a technical specification that describes how the supplier intends to realize the OEM's requirements. With formats based on Word or Excel, a traceability to the requirements can be done only with hacks like using text labels, but this is error prone at best and does not scale well. In contrast, professional requirements tools typically have extensive support for both managing traceability and analyzing it.
Considering that the automotive industry regularly exchanges tens of thousands of requirements, the problem quickly becomes apparent.

1.2. Tool Vendors to the Rescue

As customers were struggling to keep as much information as possible intact upon exchanging requirements, both the tool vendors and system integrators got busy filling this need in the market. DOORS Exchange allowed the lossless exchange of requirements, but only if both parties used DOORS. Third-party tool vendors developed solutions, and armies of consultants started to develop scripts for their customers that would provide custom-tailored solutions.

This provided a welcome relief for OEMs and suppliers, as they had a solution for the time being. The proprietary solutions worked well, and the immediate obstacle for moving away from paper-based requirements was removed. Nevertheless, the OEMs in particular realized that the inclusion of the supplier in the requirements engineering process was not just a convenience, but had strategic importance. And as such, relying on a proprietary solution from a single vendor was problematic. This was extensively discussed at the Herstellerinitiative Software (HIS), a trade association of the automotive industry.

1.3. RIF is born

In 2004, the HIS commissioned the creation of the Requirements Interchange Format (RIF). Crucially, they also commissioned a prototypical implementation that was freely available to the members of the HIS. There was quite a bit of talk about RIF around that time, in the form of conference talks and publications – but it was left at that, just talk.

Even though the format continued to evolve through various stages and revision numbers, it got quiet around RIF. A few tool vendors even included RIF support in their tools, but all too often these felt more like marketing stunts than industry-strength implementations. The author is not aware of the use of RIF in a production environment – however, there were pilot projects and experiments.

To those not looking closely, RIF pretty much felt dead. This changed in 2011, when the standard was officially release by the OMG under the new name ReqIF. The name was changed to avoid conflict with the Rule Interchange Format, another OMG standard that was already abbreviated as RIF.

The release coincided with ReConf, a big industry conference, where attendees were surprised by a large number of talks, and even more importantly, by pledges from many vendors to support ReqIF in the near future. Also, the Eclipse Requirements Modeling Framework had just been published as an open source reference implementation of ReqIF.

2. ReqIF Today

Since the release of ReqIF 1.0.1 in April 2011, activities around the format have accelerated. Development of the standard continued under the OMG, which released ReqIF 1.1 in October 2013. This version is schema-compatible with version 1.0.1, and merely consists of clarifications. This demonstrated that ReqIF had reached a high level of maturity. Also, by not changing the schema, tools do not distinguish between 1.0.1 and 1.1. This prevents fragmentation of the tool market for now and keeps the cost of adoption down.

2.1. ProSTEP Implementor Forum

The ProSTEP iViP association is an international association that has committed itself to developing innovative approaches to solving problems and modern standards for product data management and virtual product creation. The ProSTEP supported the creation of the RIF standard since the early days, and was responsible for the hand-over of the standard to the OMG, amongst other things.

The ProSTEP is still actively supporting the introduction of ReqIF. Specifically, they helped to establish an implementor forum [REQ-IF] in 2011, which is still active. The objective of the forum is to ensure that the various implementations of ReqIF are actually interoperable – not a matter of course for any reasonably complex standard. Most importantly, the most prominent users of ReqIF were present, including BMW, Continental, Daimler and Volkswagen. Likewise, the most prominent tool vendors were present as well, including IBM and PTC. The forum also included a number of consulting firms, service providers and system integrators.

Particularly exciting is that over the years more and more partners joined the forum. When the forum was established, four tools were being tested: PTC integrity, Requisis Rex, IBM Rational DOORS and IBM DOORS Next. To Date four more tools joined the effort, these being Reqif Server from enso, Atego Exerpt, ReqTeam ReqEdit and Formal Mind Studio. New users and service providers also joined the mix.

The implementor forum does not cover all ReqIF-related activities: There are many more tools in the marketplace that support ReqIF in one form or another, from new tools (e.g. QuakeSafe from Orange Moon) to established tools (e.g. Polarion Requirements), and many more.

2.2. Open Source Implementations

Open Source can sometimes take on a special role with respect to standards. For instance, they can help to strengthen it by acting as a reference implementation, thereby demonstrating how it is supposed to work. This allows interested parties to play around with data, without having to make a big investment.

There have been a few attempts to provide an open source implementation of ReqIF. The most active one is the Eclipse Requirements Modeling Framework [RMF], which is hosted by the Eclipse Foundation, which also guarantees that the code is IP-clean. The project includes a user interface, which can immediately be used as a ReqIF editor. The project is described in more detail below.

Another open source implementation is QuakeSafe from Orange Moon [QS], and there are relics of the ERA ReqIF editor [ER], which seems to be inactive right now.

3. A Brief Overview of the Standard

Next, let's have a closer look at the standard. ReqIF is an XML-based file format. The underlying data model and the XML format are described in the OMG standard, which also provides the format in digital form as a CMOF model.

3.1. The ReqIF Data Model

The top-level container is called ReqIF and consists of a header (holding some metadata), tool extensions that can be used by tools as they see fit, and the actual content, as shown in this diagram (Source: OMG ReqIF 1.0.1 Specification):

The really interesting part is the ReqIF Content, which in turn consists of six element types, as shown here:

The actual requirements are so-called SpecObjects. By themselves, these only hold some information for internal administration, like an internal ID or a last-modified timestamp. SpecObjects have a SpecType, which defines the attributes the SpecObject has. Attributes are typed. There are basic types like strings, numbers, booleans, etc. There are also complex types like enumerations and rich text (XHTML). Rich text, in particular, also allows the embedding of arbitrary data, including files, images or OLE-objects.

SpecObjects are arranged in Specifications. These consist of a hierarchy that references the SpecObjects. The separation of the structure of the requirements document (in the form of Specifications) and the actual requirements themselves means that requirements can be referenced multiple times – something that not all tools in the market support.

SpecRelations allow relationships between SpecObjects to be established – the foundation for traceability. SpecRelations can also be typed, giving them arbitrary attributes.
There are many more features in the standard, like the ability to group SpecRelations or access information, allowing importing tools to determine which information is editable.

3.2. What ReqIF does not do

Sometimes it is useful to explicitly look at what is outside of the scope. In particular, there are tools that use ReqIF as the underlying data model. But ReqIF has been designed as a format for data exchange, not a data model. This means that features like versioning, for instance, are explicitly not part of the standard.

A particularly interesting aspect is process support. ReqIF is initially agnostic to process. At the same time, it has been designed with a process in mind. And while the standard strictly excludes process specific features, it explicitly references the HIS Process for requirements exchange.

3.3. The HIS Exchange Process

The objective of ReqIF is to support manufacturers in sharing requirements data with their suppliers, and to make it easy for suppliers to give feedback on requirements. This is the most important use case of ReqIF, which has been visualized in the standard:

The picture shows an OEM (Partner 1), who wants to get feedback on a requirements specification from a supplier (Partner 2). Not all requirements are relevant, therefore a subset of the requirements is exported as ReqIF (those elements shown in dark blue). The supplier receives the ReqIF file through a mechanism that is not further specified – maybe a file sharing portal, or even email. The requirements are then imported into the supplier's database, which may contain supplier-specific requirements as well.

The OEM typically supplies attributes for the supplier to edit, e.g. a status attribute (“accept”, “reject”, etc.), a comment attribute, and so on. Of course, the supplier can incorporate the requirements into their system by creating links, or by adding attributes that are used only by the supplier.

Once the supplier has edited their attributes to their satisfaction, they will perform a ReqIF export out of their system. Again, they may perform only a selective export of those requirements and attributes that are relevant to the OEM. The OEM in turn will perform an import, which updates the relevant attributes of those requirements that had been exported in the first step.

This is the easiest use case, but it demonstrates nicely what ReqIF has been designed for. Note that the exported attributes and their use are process-specific. But as ReqIF does not prescribe the use of any specific attributes, the standard itself is process-independent.

3.4. Implementor Guide

An important outcome of the ProSTEP implementor forum is an implementor guide. This guide includes a number of recommendations that make interoperability easier. Of course, implementations should not assume that the recommendations from the implementor guide have been honored. The ReqIF standard is prescriptive, not the implementor guide. The implementor guide gives recommendations in a number of areas, like the handling of read-only system attributes, embedded tables and embedded objects, and more. Particularly noteworthy are the following two conventions:

File Extension. The guide recommends the use of the .reqif file extension for ReqIF files (instead of just “.xml”). As soon as embedded objects are used, it is necessary to create a zip archive, containing all files. The guide recommends the use of the file extension “.reqifz” in this case. This makes processing much easier.

Naming conventions. The guide provides standard names for attributes that all or most implementations use in some form. For instance, every tool has an attribute that holds the actual requirements text. The guide recommends exporting this with the name “ReqIF.Text”. Many more conventions exist.

4. ReqIF in the Field

The OEMs that participate in the ProSTEP implementor forum (Daimler, VW, BMW) are actively working on pilots to try ReqIF in the field with their customers. Once the pilot phase is completed successfully, requests to the suppliers will go out to switch to ReqIF for data exchange.

Most, but by no means all, activity takes place in the automotive field. Requirements engineering with sophisticated tools is also practiced in medical and telecommunications technology, aviation and rail, to name just a few. The tool diversity there is much wider compared to the automotive domain. And a diverse tool landscape is fertile ground for an open, lossless standard.

Lastly, requirements engineering is also a large topic in research. Often, research is accompanied by a tool implementation for the ideas investigated. In the past, these were often incompatible hand-knit solutions that disappeared into the drawer after the research was completed. We now see researchers picking up ReqIF and Eclipse RMF for their tool implementation, increasing the chances that their research will survive in the field.

In the following section, we'll have a closer look at the rail industry and academia.

4.1. openETCS: Systems Modeling for Rail

The ITEA research project openETCS [oE] has grand ambitions: It's objective is to model the on-board software of trains. The European Train Control System (ETCS) already allows trains to cross borders, without passengers noticing. But there are high safety standards that must be fulfilled. While ETCS systems are on the market today, they are not completely interoperable, due to ambiguities in the underlying specification. This drives up operating costs for service providers like Deutsche Bahn.

In addition to modeling the ETCS requirements formally, the project's objective is to support this work with an open source toolchain. This requirement addresses primarily the issue of long term maintenance. In rail, it is not unusual to have a product line lifetime of decades, sometimes 70 years and more. This is not limited to rail, aviation struggles with the same challenges. There is no guarantee that a commercial tool is available throughout the product's lifecycle – vendors go bankrupt, or get acquired and decide to discontinue tools. Open source has been recognized as one defense for ensuring long-term maintenance.

Deutsche Bahn is also the main driver behind openETCS. The project's objective is to model the ETCS specification formally. But the requirements are managed by the European Rail Agency (ERA) using Microsoft Word.

The challenge in the project is to provide an open source, integrated toolchain that covers all aspects of systems modeling in a seamless fashion. The openETCS team decided to use ReqIF as the open standard for managing requirements, and the open source reference implementation RMF for managing the requirements.

As mentioned above, the Eclipse Requirements Modeling Framework (RMF) is considered the open source reference implementation of the ReqIF standard. It consists of a core and a user interface. It has also been used by the ProSTEP implementor forum to generate synthetic test data.

4.2. Eclipse and RMF

RMF is based on Eclipse. Eclipse is an open source platform for building rich client applications, and is probably best known as an integrated development environment (IDE) for Java, but it can do much more than that. Eclipse was founded in 2004 by IBM as part of a strategic decision to build a common platform for their services. Today, Eclipse is managed by an independent foundation, consisting of dozens of sub-projects, tens of millions of lines of code and hundreds of committers that actively continue the development. While initially focused on software development, Eclipse started to attract interest from the systems development community, with backing from organizations like Airbus, Bosch, Ericsson and many others.

For openETCS Eclipse was attractive, as it already contains a number of open source components for systems engineering. Particularly visible is the open source PolarSys [PS] tool platform, which is financed primarily by Airbus and Ericsson for systems modeling (PolarSys was formally known as Topcased).

RMF consists of a core that allows the reading, processing and writing of ReqIF. It uses the Eclipse Modeling Framework [EMF] for this purpose. The core can be used for processing ReqIF files, extracting or modifying information, performing model transformation and so on. While it is based on Eclipse technologies, it can also be used outside the Eclipse context.

RMF includes a user interface called ProR. ProR is essentially a stand-alone ReqIF editor. For people interested in getting a “feel” for ReqIF, ProR is a good starting point. It allows ReqIF files to be opened and to be viewed and edited in a similar way as would be done with traditional requirements tools. In contrast to many legacy tools, however, all features of ReqIF are supported. Consider DOORS: In DOORS, all requirements in a document must have the same attributes. But the ReqIF standard does not include this restriction, neither does ProR.

ProR is available for download from the RMF project website. But the easiest way is to download formalmind Studio [fmStudio] instead. This is a free pre-build version of ProR that also includes a few productivity enhancements, like the ability to render rich text with formatting.

4.3. ReqIF in openETCS

The openETCS tool, which integrates ProR, can be downloaded from the openETCS website [oE] for Windows, Linux and Mac. In addition to ProR, it contains Papyrus, the Eclipse component for UML/SysML modeling. Seamless integration is an important aspect of the project, and as of this writing, a traceability solution [oEtrace] for connecting SysML elements with ReqIF requirements is part of the platform.

The original requirements from the ERA (the so-called Subset-26) were available as Word documents. The first step was the conversion to ReqIF. This has been done using Rational DOORS, which can import Word and export ReqIF. The resulting ReqIF was good enough to get started. The resulting ReqIF models are freely available on the openETCS repository [Subset26].

However, requirements change. With a subsequent import, any modifications to the requirements would be lost. Therefore, some project partners are working on a Word-to-ReqIF converter that preserves internal IDs. With such an importer, incremental updates to the requirements would be possible. The following screenshot shows the openETCS tool with an open ReqIF document. The traces on requirement 9 are made visible. The actual values can be edited anywhere by double clicking, and a lot of functionality is provided through context menus (e.g. adding or deleting elements). Traces to the SysML model are established by dragging SysML elements from the model explorer directly onto a requirement in the main editor.

4.4. ReqIF in Academia

A lot of research in the areas of requirements engineering and systems modeling involves case studies, and case studies are typically described in the form of requirements. If the research involves industrial partners, they often provide requirements that already exist in a requirements database. No wonder that ReqIF triggered interest in the academic community.

In the past, it was common for such projects to build their own requirements solution. The data is structured according to the needs of the project at hand, which discourages reuse. The data is persisted in whatever format the researcher considers useful: This could be plain text (e.g. CSV), a generated XML schema, or even Latex. Whatever was used, the format rarely survived for long after the completion of the project.

Academia uses ReqIF on two levels: Some projects simply parse the XML that ReqIF consists of and extract whatever information they need. Considering that the XML is relatively simple and that XML libraries exist for all common programming languages, this is practical for small projects and quickly realized.

More complex projects appreciate and use the RMF project to deal with ReqIF data. In particular, there are many research projects that are based on Eclipse (examples include UniCase, PolarSys and Rodin, to name just a few). Using Eclipse has the added advantage of using the plug-in mechanism for seamless integration.

An example of such an integration [Rodin] is the Rodin project. Rodin is an Eclipse-based tool for formal modeling in the text-based modeling language Event-B. For the research projects Deploy, traceability between model elements and textual requirements was needed. This was then realized with a traceability plug-in that connected Rodin with ProR. Most importantly, no modification to either Rodin or ProR was needed; all the logic was encapsulated in the integration plug-in. Once completed, the plug-in allowed traces to be created with drag and drop; it showed the formal model elements in-line with the requirements; and entities from the formal model were highlighted in color in the requirements text. This is shown below.

5. Outlook

Good things come to those who wait. While it took ten years for ReqIF to mature, it is rewarding to see a frenzy of activities unfolding around the standard. Seeing the willingness of tool vendors and automotive OEMs to bet on ReqIF, it is clear that ReqIF is here to stay.

It is also clear that for now, the most serious undertakings are happening in the automotive industry. OEMs are starting pilots right now (mid 2014), and once they are successful, they will roll ReqIF out to their suppliers.

But the impact of ReqIF will not be limited to the automotive industry. Advanced requirements engineering is widely performed in the medical devices industry, in aviation and the space industry, and many others. While they currently do not experience the same pressure as the automotive industry, they do work with suppliers, and they use the same tools. Therefore, ReqIF will be available everywhere. Whether users take advantage of this is to be seen.

But as argued in the beginning, acceptance of open standards will trigger many more changes, expected or not. The interoperability due to ReqIF will make many new ideas possible. For instance, specialized tools can work on ReqIF files that are subsequently merged back into the originating tool. One example is the use of text templates, or domain-specific languages (DSLs). In such a scenario, a user could export a textual specification as ReqIF (e.g. from DOORS) and edit it with a specialized tool that provides an advanced DSL editor. This would lead to a higher internal consistency. The result could then be merged back into DOORS. Such a DSL editor has already been implemented as an academic prototype for ProR.

Having a free base implementation of ReqIF invites industry and academia alike to think of new, exciting ways to integrate requirements and the tools that support this.

Acknowledgement: This work was partly funded by the German Federal Ministry of Education and Research (Grant No. 01IS12021) in the context of the ITEA2 project openETCS.

• [EMF] https://www.eclipse.org/modeling/emf/
• [ER] https://github.com/3GF/era_dev/wiki
• [fmStudio] http://www.formalmind.com/studio
• [HIS] https://www.autosar.org/index.php?lang=en
• [oE] http://openetcs.org/
• [oEtrace] http://www.formalmind.com/en/blog/traceability-between-uml-and-requirements-pror
• [PS] http://polarsys.org/
• [QS] http://orangemoonsystems.com/en/products/quakesafe-r-open-source - link not available anymore
• [ReqIF] http://www.omg.org/spec/ReqIF/
• [REQ-IF] http://www.prostep.org/en/projects/internationalization-of-the-requirements-interchange-format-intrif.html
• [RMF] https://www.eclipse.org/rmf/
• [Rodin] http://www.formalmind.com/de/blog/using-rmf-integrate-your-models
• [Subset26] https://github.com/openETCS/modeling/tree/master/model/subset26