ReqIF – the devil is in the details…

Once upon a time there were some German car manufacturers which were convinced that using Word and Excel for managing their requirements is not feasible. So, they started using a professional requirements management solution. But collaboration with dozens of suppliers becomes a nightmare. Their approach was trying to force the suppliers to use the same tool. But who likes to be forced to do something? It gets even more complicated if many manufacturers (using different tools) want to collaborate with many suppliers and those need to collaborate with other suppliers. Today even the manufacturers themselves start working together in some dedicated areas…

The only possible solution: they all need to agree on using the same tool in probably the same version. Realistic? No!

So, the major German car manufacturers and suppliers met in order to discuss alternative ways to improve collaboration across company borders without losing the benefits of professional requirements management solutions. The Requirement Interchange Format (RIF) was born in a first version… The overall idea of RIF is allowing requirements data exchange between different tools.

First implementations were developed and it turned out that RIF did not work as expected. Over time RIF was improved and finally - to get more acceptance on both the tool vendors and the users side – standardized by OMG. Since there was a naming conflict at OMG RIF was renamed to ReqIF (keeping its meaning). The final OMG approval on ReqIF 1.0.1 happened in April this year. http://www.omg.org/spec/ReqIF/

But why the hell all the major players in the requirements management domain have not implemented ReqIF yet?

Because it will still not work between different tools if each tool vendor just implements ReqIF on its own. The standard just provides an XML schema where tool vendors put their data in. This data may contain attributes with a certain name and value. Unfortunately the different tools typically use specific attributes to store, for example, the description of the requirement. Let’s assume tool A calls this attribute “description” and tool B uses “requirements text” for the same kind of information. The ReqIF export from tool A will probably contain the attribute name “description”. If tool B tries to import this ReqIF file it does not know that “description” should be mapped to “requirements text” in tool B. So, tool B would probably create a new text attribute “description” to store the data there instead of storing the data in “requirements text”.

This is just a very simple example. I could imagine far more imcompatibility issues when exchanging data between different tools. Just think about a situation where tool A supports a certain data structure which is not supported in tool B.

To avoid as many of these issues as possible Visure Solutions - among other major tool vendors - agrees on participating in a follow-up activity of the ReqIF standardization group which is called the “Implementor Forum”.

In this “Implementor Forum” the tool vendors will try to find a harmonized glossary for the individual data models of the different tools in order to provide implementations afterwards which are compatible to each other. Right now (November 3^rd, 2011) I’m currently attending to the first meeting …

That’s why these major tool vendors have not yet implemented ReqIF. Before implementing we will capture and analyze the requirements… J

Stay tuned. I will give an update about the progress next week.

By: Andreas Plette

Compliance to standards

Today there is almost no industry not being penetrated by standards and regulations such as IEC 61508 and its derived standards for the different industries.

Those standards are typically provided in PDF format and contain often hundreds of pages from which only a certain subset might be relevant for a specific project. For another project a different subset of the standard might be relevant. So how to prove compliance efficiently with such a standard if there is no way to:

• Trace the project requirements back to individual statements of the standard?
• Check if all relevant statements from the standard are covered in the project requirements (how to identify quickly the relevant aspects contained in a huge PDF and whether they are already covered by the project?)?

Appropriate solutions by Visure Solutions may help here: first of all you would need to import the relevant part of the standard into a requirements management solution where each statement is its own referenceable unit. Of course this should be done in an automated way (who really likes to copy/paste thousands of sentences from a PDF to some other tool?). Then you can use the capabilities provided by such a tool to create relationships between individual statements of the standard and the requirements derived from them, proving compliance to the standard by using the numerous capabilities provided by requirements management solutions for analyzing traceability and coverage

But what if you need to see the details of a statement in the original PDF?

Just navigate there!

By: Andreas Plette