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

Implementing a Requirements Management Tool on a Complex System

Many years ago I spent several years working on a very complex weapon control system. As you can imagine the requirements were large, complex, and changed often. We spent a lot of time just trying to manage those pesky changes that continued to be submitted, both from customers and from the developers. In those early days, we did not have any requirements management tools to help use assess these changes. We were using Interleaf and Excel (I can hear groans of pain now). Everything was manual, including our complex traceability. We had a couple of folks who did nothing but maintain the traceability matrices and assess the impact of changes. At this time we only had traceability from the Concept of Operations to System Requirements to Subsystem Requirements. I say “only” but at that time just having this level of traceability was a big accomplishment.

When we had enough changes we issued a new system requirements document and new subsystem requirements document. Those poor contractors had to go through the massive subsystem requirements and manually determine what had changes. I can’t imagine the time the contractors spent just trying to figure out what changes they needed to be concerned about.

It was in the middle of this upgrade project that the customer said enough and tasked my team with evaluating and selecting a requirements management tool. The tool we selected is not important to this particular discussion, but what we learned from this tool selection and implementation is important. Here are some lessons learned.

(1) - There is not a single tool which is going to please everyone. We had users who loved our selection and those who fought us every step of the way. Without a customer supporting and enforcing the change it would not be possible on a large program like this one. One user complained about the column size of the tool generated traceability matrix, totally ignoring the fact that it saved him days of manual effort.

(2) - Our manual traceability was not very clean. Once we imported all of our information into the tool and linked it up we found many gaps in the traceability. What was more disturbing was that we had links that really didn’t make any sense. We had to do a lot of work to clean up our traceability matrices.

(3) - Just tracing requirements was great, but now we could use the same effort to link requirements to test plans, and went so far as to link subsystem requirements to design documents that we could review. This didn’t happen overnight, but it did happen. Eventually we could trace system requirements to a subsystem requirement to a design document to a code module. We even used a tool to determine the complexity of code modules and used this to help determine how difficult a change would be to implement and test.

(4) - Metrics from a requirements tool are key to understanding completeness of testing activities. We often thought we were 50% complete with testing. After all, 50% of the tests were completed. However, what we found was that we were prone to testing the simplest and most understood parts of the system first. So even thought we were 50% complete, everything left was very high risk. We learned to prioritize our testing by looking at requirements priorities and software complexity, information we could not determine through manual traceability.

(5) - It was very easy to get overwhelmed. Start simple. We had to back off our ambitious ideas and begin with a simple traceability model. As we learned and gained more experience with the tool, we added more information to our model. We were constantly assessing our process to figure out what else we could do to make it better.

- Don’t skimp on training and mentoring. We trained everyone on the project and created experts who helped users get over initial hurdles. We sent our experts to our contractors for weeks at a time to help them get up to speed in using the tool. We even had our own internal users group. Be prepared for this kind of effort.

What a great leargning experience this was for me. If you´re interested in embarking on a change like this to improve your requirements process, contact Visure Solutions. We will be happy to discuss your process with you.

By: Marcia Stinson