What is a requirement?

Whatever kind of system, software, product or service you would like to offer to the market all your efforts are based on requirements to be fulfilled. Indeed, this is not new. Most of us are writing requirements since decades. But do we really know what a requirement is?

There are almost as many definitions out there as books available about Requirements Engineering. But do these definitions really help in our daily work?

A couple of weeks ago I had the pleasure to participate in a workshop about requirements methodology. At the beginning we did a small exercise. We got the following text frament – taken from a real-life example (!) - and we were asked to count the requirements regardless whether they are “good” or “bad”:

Sounds like a simple question. But: although most of the participants had several years of experience working with requirements we got an interesting result (the constructor wrote down the answers of the individual participants):

Why that?

Of course, each participant has its own experiences and knowledge about the system to be build which highly influences the way they read the document. So, you cannot expect to get a single answer…

Then we started to analyze the given text sentence by sentence trying to formulate requirements with better quality based on two of the most important characteristics for a “good” requirement:

• You must be able to implement the requirement
• You must be able to verify that the implementation fulfils the requirement

Using these quite simple rules we came to the following improvement (which still may not be perfect):

From this example you can see one of the major drawbacks when using word processing tools for requirements: Authors tend to provide justifications for certain requirements in subordinate clauses (e.g. 3 is the justification for 2). Then it may happen that they introduce redundancy (e.g. requirements 2 and 5 in the example above) which makes it difficult to maintain these documents. Apart from the implicit relations the author has “created” using subordinate clauses there are of course more relations between the different requirements we identified above. If you try to represent these relations in a more structured way you may get the following [please do not use a word processing tool for this… = ) ]

So, finally we identified requirements from four different abstraction levels within the first three sentences of the original document!

Think about it…

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