ReqIF – the devil is in the details… (part 2)

On November 3^rd the first meeting of the so-called “ReqIF Implementor Forum” took place in Germany http://bit.ly/vaatse

Visure Solutions and other major tool vendors in the requirements management space first tried to define naming conventions for those attributes that are provided out-of-the-box by the involved tools. We identified a couple of common system attributes:

• a unique identifier
• the user who initially created the requirement
• the time when it was created
• the user who did the last modification
• the time when the last modification was done
  
• and finally – probably the most important one – the attribute which holds the requirements text itself

For those attributes it was fairly simple to agree on a dedicated name and type to be used in the generated ReqIF files. It is important to note that we have not yet discussed how an importing tool shall handle all these information but it is obvious that neither of the tools is able to create a requirement on import and assign the original creation date found in the ReqIF file to the corresponding system attribute in the respective tool (of course a system attribute “Creation date” will automatically get the actual date of the import).

On the other hand having a commonly agreed attribute name for the requirements text helps the tool vendors to identify this information in a ReqIF file. The importing tool is then able to write this information into the appropriate system attribute of the tool.

Vendors not participating in the “Implementor Forum” will probably use (export) and expect (import) a different attribute name in the ReqIF file for the requirements text. It’s very likely that exchanging data with such an incompatible ReqIF implementation will result in a mess. It must be clearly stated that if a vendor claims to support ReqIF this does not necessarily mean that you can exchange data with other requirements management tools also supporting ReqIF. It is the main goal of the “Implementor Forum” to achieve compatible ReqIF implementations – at least for those tools represented in the “Implementor Forum”!

Apart from the common attributes we also took a look into the different tool-specific system attributes (out-of-the-box attributes not provided by all involved tools). IRQA for example provides a version number for each requirement which is not available out-of-the-box in other requirements management solutions. For these kind of attributes we have also defined appropriate names and types to be used in the generated ReqIF file – once again with the intention to help the other vendors to identify this specific kind of information in order to handle it appropriately.

Unfortunately we already found some tricky aspects which need further discussion. As an example we can talk about IRQA discussions: In IRQA any user may add comments to any of the requirements (as long as they can read them). It is very likely that these discussions contain valuable information that needs to be exchanged using ReqIF. But: a discussion entry is not just a string attribute. It consists of the user who created the comment, the date when the discussion entry was created, the version to which the comment is related and the comment itself. So, if we export to ReqIF shall we export only those discussion entries that are related to the current version of the requirement which is also exported? Or shall we export all discussions attached to a particular requirement? We may also decide to skip export of discussions…

On Nov 18^th a conference call will take place where the participants of the “Implementor Forum” will try to finally agree on the naming conventions of system attributes.

In addition we also started first discussions about test data since the tool vendors, of course, need some proven example data for testing their importing tool. We agreed that we will start with easy example files focusing on specific topics. The initial files will be provided by the participants who has driven the standardization of ReqIF. Later on each tool vendor will provide the same kind of example files generated with their respective exporting tool in order to allow other tool vendors testing the compatibility. For any of the test data provided somebody needs to check whether the files are ReqIF compliant.

Indeed, the devil is in the details…

By: Andreas Plette

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