EN 
DE More effective system development with the open standard
Author: Dr. Michael Jastram, Formal Mind
Contribution – Embedded Software Engineering Congress 2017
Product development today is under enormous pressure: increasing complexity, a growing number of suppliers, regulations, and the decades-long availability of development artifacts. The ReqIF standard addresses these challenges in two ways: firstly, standardization ensures that requirements remain readable even after decades; secondly, the standard enables integration for the seamless, traceable exchange of requirements.
motivation
The exchange of requirements is becoming increasingly important, primarily for two reasons: Firstly, there is a growing reliance on suppliers and external service providers. Secondly, traceability requirements are becoming ever stricter, particularly in developments involving functional safety aspects.
Until a few years ago, requirements were exchanged either in lossy formats (PDF, Excel, Word), or proprietary solutions had to be used. But since 2011, there has been an open standard called ReqIF that enables the lossless exchange of requirements [ReqIF].
ReqIF stands for "Requirements Interchange Format" and originates from the automotive industry. There, requirements were increasingly being sent to suppliers, who were then expected to evaluate and comment on them. This scenario can be implemented with ReqIF. The manufacturer sends the requirements as ReqIF files to the supplier, who then populates the evaluation attributes with values and sends them back to the OEM.
The story
ReqIF 1.0.1 was published in 2011 as a standard by the Object Management Group (OMG) and can be used license-free by users and tool manufacturers. However, the history of ReqIF began in 2004, when a consortium of several OEMs launched the first version of the standard, named RIF, and funded the prototype development of a tool that enabled RIF-based requirements exchange.
The standard went through several iterations before being handed over to the OMG in 2011. Since the OMG already had a standard called RIF, the format was renamed ReqIF, and the version number was also reset to 1.0.
Although commercial tools were supported before 2011, their implementations have only recently become truly practical. The format is also slowly gaining recognition outside the automotive industry.
The current version of ReqIF is 1.2. However, this is identical to ReqIF 1.0, which sometimes leads to confusion. Only the accompanying text has changed, not the format itself.
The Eclipse Requirements Modeling Framework (RMF) [RMF] has been a reference implementation of ReqIF since 2009, which has also contributed to the spread of ReqIF [OS13]. This open-source project is used by several commercial tools as a library for processing ReqIF and can also be used independently as a simple requirements editor under the name ReqIF Studio [Studio].
The Requirements Interchange Format
ReqIF is an XML-based file format. In the ReqIF data model, requirements are called "SpecObjects" and can have any number of typed attributes. Views of the SpecObjects are implemented via "Specifications," which arrange them in a tree structure. The data model supports linking SpecObjects via "SpecRelations," which also have any number of typed attributes.
A ReqIF file now contains the specifications to be transferred, which include linked requirements. The ReqIF file also contains the definitions of the elements, i.e., the requirement and link types used. All common attribute types are supported, such as plain and formatted text, lists, numeric values, etc. The format is rounded out with a simple permissions concept.
ReqIF use cases
The most important use case is shown in the figure (see figure). PDF) can be seen there. A round trip between two partners is shown. A typical ReqIF exchange proceeds as follows:
- Partner 1 configures the export in their tool. This defines which specifications, requirements, and attributes should be transferred. Typically, the partner should not see all requirements, nor all attributes of the elements to be transferred.
- Partner 1 performs the export, which produces a ReqIF file (.reqif). If the export also contains images or attachments, a ReqIF archive (.reqifz) is generated.
- Partner 1 transfers the export to Partner 2. In the simplest case, this could be done via email.
- Partner 2 imports the ReqIF into their system. In the simplest case, this is a straightforward import, but it's also possible to integrate the data into existing requirements. For example, if the round trip has already been performed in the past, this data could now be updated. Partner 2 can also supplement the imported requirements with their own requirements or attributes, or link them to other specifications.
- Partner 2 now processes the data, and the various use cases will be presented in the next chapter. Once this is complete, the result can be exported again as a ReqIF and sent back to Partner 1.
- Partner 1 can now automatically integrate the result into its database.
Based on the process described above, various use cases can now be implemented. The three most important ones are described here; many others are conceivable.
ReqIF-based review
In the simplest case, a supplier is to evaluate the manufacturer's requirements. To do this, the manufacturer adds evaluation attributes to the requirements, typically a status attribute ("Approved", "Rejected", "Clarify") and a comment attribute, which allows additional information to be added as free text.
Because this use case is so important, the [HIS] working group that created RIF also designed a standard process, the so-called "HIS process". The HIS process makes recommendations for the evaluation attributes and was published online by the working group.
Open issues list
Another use case is the shared management of an open issues list. This is useful for collaborations involving large volumes of requirements but a small number of open issues. Both parties can create open issues, which are then linked to the relevant requirements via traceability. This is possible because ReqIF can also transfer links.
Requirements specification
It is also possible to transmit two specifications simultaneously, such as a requirements specification and a functional specification. This allows for regular updates to both specifications, with the manufacturer retaining control over the requirements specification and the supplier over the functional specification. Traceability between the two can also be shared, which would be difficult without ReqIF.
compatibility
Unfortunately, standard doesn't automatically mean compatibility. And ReqIF also has several characteristics that can lead to incompatibilities between tools. For example, the format is so powerful that it supports features that many tools themselves don't. If a (valid) ReqIF uses such a feature, the importing tool may encounter difficulties.
Fortunately, this was recognized early on, and with the release of ReqIF, an industry consortium was also founded to ensure the compatibility of ReqIF implementations. To this end, the ReqIF Implementor Forum (RF) published a guideline for RE software vendors, which aims to increase compatibility.
The previously mentioned reference implementation [RMF] also increases compatibility. Firstly, tools that consume RMF are de facto compatible, since RMF is 100% compliant. Secondly, RMF can also be used for testing. RMF includes a validator [Val]. This checks not only whether a ReqIF file contains correct ReqIF data, but also whether the Implementor Forum conventions are followed.
Effectively use ReqIF
Many users, especially suppliers, have little choice: if the customer demands a ReqIF-based requirements exchange, then there is hardly any alternative. If this leads to the introduction of a new tool, the issue of compatibility should definitely be examined more closely.
But even if there is no external pressure, its use could be interesting for the following purposes:
- Use with one's own suppliers, especially if the legislator mandates traceability to the supplier.
- Long-term (lossless) archiving of requirements
- If a new tool is introduced for other reasons, attention should be paid to ReqIF support in order to avoid vendor lock-in.
Conclusion
ReqIF is a mature technology, supported by a growing number of tools and increasingly used. Anyone working with requirements should be aware of ReqIF's capabilities and limitations.
Literature and sources
[HIS] The HIS process was available for a long time on the HIS website (https://www.automotive-his.de/). However, this website has been inaccessible since 2016. Alternatively (registration required) at https://reqif.academy/reference/his-process-documentation/
[ReqIF] https://www.omg.org/spec/ReqIF/1.2/
[RF] https://www.prostep.org/projekte/reqif-implementor-forum/
[RMF] https://www.eclipse.org/rmf/
[OS13] Michael Jastram: „ReqIF-OLUTION: Using Eclipse and ReqIF to create an open-source ALM toolchain“, ObjektSpektrum, 2013
[Studio] ReqIF Studio Download, registration required at https://reqif.academy/software/reqif-studio/
[Val] Consequent is the ReqIF validator. The source code is available at [RMF]. The executable program can be downloaded (registration required) from [link missing]. https://reqif.academy/software/consequent/
author
Dr. Michael Jastram is a systems engineer specializing in requirements modeling. He is the founder and project lead of the Eclipse Requirements Modeling Framework, an open-source requirements modeling project that implements the open ReqIF standard as a reference implementation. As an advocate for openness, he shares his knowledge through books, articles, presentations, and as an event organizer, as well as through his weekly German-language blog. System Engineering Trends and the English-speaking Formal Mind Blog. Mr. Jastram has twenty years of professional experience, ten of which were in the USA, where he earned a degree from MIT and worked as a software engineer and architect in several start-ups. He is the founder of the Düsseldorf Java User Group (rheinjug eV.Today he is the managing director of Formal Mind GmbH and runs the ReqIF.academy, an online library for exchanging requirements. Furthermore, he supports Jama Software as Senior Solutions Architect.
Open Source – our training & coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of Open Source / Embedded Software Engineering.
Training & coaching on the other topics in our portfolio can be found here. here.
Open Source – Expertise
Valuable expertise in the field of Open Source / Embedded Software Engineering is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
