IRQA Demo - Requirements Engineering Solution

IRQA Demo - Requirements Engineering Solution - Visure Solutions from Visure Solutions on Vimeo.

Requirements Management – processes and tools

It’s no secret that professional requirements engineering solutions help improving efficiency when working with requirements. They also help minimizing the number of mistakes which would typically lead to costly corrections when found in later phases of the development lifecycle.

Therefore many companies are looking for such requirements engineering solutions. But unfortunately the same rule than for almost any other type of software tools also applies to requirements engineering solutions: a fool with a tool remains a fool…

The best-in-class requirements engineering solutions like IRQA from Visure Solutions are very flexible being able to support almost any kind of requirements engineering process. Of course, we – as a tool vendor – are happy to sell you some software but we are conviced that this alone won’t help you. Instead we want to help you being successful in using our products.

So, before purchasing a requirements engineering solution please make sure that you have a proper requirements engineering process defined with certain activities assigned to certain roles. Of course, we can also share our experiences with you in this area. If you know the detailed characteristics of your process it’s much easier for you to find an appropriate solution which fits the needs of your process.

I’m quite confident that IRQA will be your preferred choice…

By: Andreas Plette

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