Exchanging requirements without loss

1. The contractor doesn’t understand exactly what you had in mind. For you, the requirements were clearly described, for him too, but the delivery does not correspond to what you had imagined in your mind’s eye.
2. In the course of time, you have developed further ideas, recognised improvements and formulated new requirements.

The obvious solution to these two challenges lies in communication between the partners. If the contract allows it, new requirements can be implemented in addition to or instead of the originally defined requirements. Nevertheless, the cooperation is not always that easy, because technical and process-related aspects have to be considered.

The format for the exchange of requirements

When a client sends requirements to a contractor, in what format does the exchange take place? The “classic” tools are Word, Excel or PDF, but none of them support the so-called Requirements Interchange Format (ReqIF)¹. ReqIF is an international standard for requirements exchange defined by the Object Management Group (OMG). To ensure that this standard is implemented correctly, manufacturers and users of ReqIF tools have been meeting for many years in the ProSTEP ReqIF Implementor Forum.² An open source reference implementation is available for orientation for tool manufacturers.³ What are the reasons for ReqIF and against Word, Excel or PDF when it comes to the exchange of requirements, i.e. the transfer of the customer’s requirements into the contractor’s requirements management system?

• The delimitation of requirements
  For the automatic exchange of requirements it is important to recognise where a new requirement begins and where it ends. Requirements must be clearly distinguished – naturally in terms of content from other requirements, but also in terms of appearance. This is still the case with Excel, because one row could correspond to a requirement with various attributes. With Word such an explicit delimitation is difficult to achieve and with PDF only with imprecise heuristics.
• The identification of requirements
  A requirement must be identifiable, i.e. every requirement needs an ID. In Excel this can be realised by saving the ID in a separate column of the request row. Unfortunately there is no clean solution for the other formats.
• The attributes of requirements
  Requirements have various attributes such as name, description, priority, comment, status, etc. In Excel this can be implemented with additional columns, but this becomes very difficult once sketches or graphics are added to the requirement description. In Word and PDFs there is no satisfactory solution.
• The linking of requirements
  One requirement in a specification sheet becomes several requirements in a specification sheet. How can you trace this? So the linking of requirements is important, neither Excel, Word nor PDF offer reasonable solutions for this.

In a comparison of the classic tools, Excel still scores best, but the limitations in handling sketches and graphics are very large. And it is also difficult to trace changes; overwriting the original text would be negligent, adding rows or columns would reduce – especially with many changes – the clarity. In contrast, ReqIF has none of the above-mentioned weaknesses, because it was designed explicitly for the exchange of requirements and not as a spreadsheet or text editor.

Dealing with changes

Requirements change. Imagine that you, as the customer, send a request to your contractor, who returns it with the status “Accepted”. Now you have a new idea and extend the existing request. Of course this change is not accepted, because the status “Accepted” refers to the original request. The same applies to the links between requirement specifications and functional specifications. If a requirement in the specifications changes, the corresponding requirements in the specifications must be re-examined. Thus, the maintenance and versioning of requirements are important. Fortunately, there is a useful template for exchange processes: The Herstellerinitiative Software (HIS), a working group of the automotive industry, has defined the so-called HIS process for the exchange of requirements. The process is divided into six use cases for orientation:

• Initialisation
  During initialisation, the client and contractor agree on the technical and logistical details.
• Export and packaging
  For each exchange it is necessary to prepare and export the “correct” requirements for the transmission.
• Transmission
  The transfer of requirements is very different. Some organisations have no problems when requirements are transmitted simply and quickly by e-mail, while others require that the data transmission be encrypted and provided with a digital signature. Again, coordination between the parties involved is essential.
• Import
  In addition to a pure requirements import, it is important to perform a plausibility check, among other things.
• Evaluation of the requirements
  Of course, requirements in terms of consistency, completeness, comprehensibility, etc. must be evaluated.
• Review of the evaluation
  The results of the evaluation are then sent back to the partner, who in turn has to check them himself.

The HIS process covers all important aspects for a successful requirements exchange. It is mainly about the “what” and less about the “how”. For example, it requires that you as the client agree on an exchange format with your contractor, but does not specify one.Since ReqIF was developed explicitly for the exchange of requirements, it is certainly a good choice for implementation.

Conclusion

The loss-free exchange of requirements between companies is very important for the joint success of a development. However, a structured exchange of requirements is not always easy, as changes, new wishes and requirements often arise in the course of a project. Here ReqIF offers a robust, technical basis for safe working. You can optimise this work by using professional tools with which you can exchange requirements, but of course also collect and manage them. The HIS process also provides a description of what you should consider when exchanging requirements. Understand it as the basis for a process that you can define and live together with your development partner.

Notes:

[1] Requirements Interchange Format
[2] ProSTEP ReqIF Implementor Forum
[3] ReqIF-Studio, a RE tool based on the open source Eclipse Requirements Modeling Framework

Dr. Michael Jastram has published another article in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.