RASAS is short for ‘ReqIF as a Service’, and exercises in the context of ReqIF. ReqIF is an XML based data format standard for requirements documents. The key concern of the ReqIF standard revolves around the interoperability between various software tools from the realm of requirements engineering and is therefore associated with a document's exchangeability between organizations. With RASAS and as a member of ReqIF Implementor Forums (ReqIF IF), Individual Standard IVS supports the aim of interoperability but facilitates an advanced means for data sharing in automatic processing.
Instead of exchanging ReqIF files between software tools, RASAS propagates a service-based approach, concrete REST. REST hinges on a client/server model, that is, a server provides a service to which the clients can send four different types of requests. Here are examples for these request types:
With these types of operations one also speaks of CRUD operations. The communication with a REST service is normally realized per HTTP(S), and such is also the case with RASAS. This means: Requests are sent from the client in the form of URLs, extended with parameters if necessary, using the HTTP methods GET (corresponds to READ), PUT (corresponds to UPDATE), POST (corresponds to CREATE), or DELETE.
What is RASAS exactly though? RASAS is simply the standards-compliant specification of a REST-API for ReqIF documents. The specification complies with the rules of the OpenAPI specification for REST-APIs (also known by the name of Swagger).
We provide RASAS as open source product, free of charge and thereby hope to empower the requirements engineering community to further develop the specification and with their software tools make use of the advantages of a REST interface for ReqIF exchange.
We want to contribute to the community by making requirements engineering maximally interoperable. This means that tools for requirements management (RM tools) must be able to exchange data as simply as possible. Various organizations, particularly suppliers and OEMs, often use different tools for requirements management. Without common interfaces or exchange formats, cooperation is naturally a challenge. Aside from requirements management tools there are quite a number of other tools used in requirements engineering (third-party tools) - for example for validation and analysis of documents. In practice, tools still exist which are bound to specific requirements engineering tools without any trace of interoperability.
With RASAS we pursue the following target vision: Applications which manage (requirements) data and wish to make them available or workable from an outside source, will implement a RASAS-based service (server). Applications who wish to access another service, implement a RASAS-based client. In some cases both service and client are needed. For example, a requirements management tool wishes to make its data available and modifiable from the outside (service) while at the same time being able to import data from other requirements management tools (client), i.e. in the course of exchanging requirements between contractee and contractor.
Should these conditions pertaining to requirements management tools be addressed, the development of third party tools would be radically simplified. Simply integrate a RASAS conformed client and you're automatically not only compatible with a particular requirements management tool, but rather with all the tools that support RASAS.
The greatest advantage of a REST-based exchange of ReqIF data compared to file-based exchange is obvious: While a ReqIF file must always be transferred whole, with a REST-API numerous, smaller transfer actions can be undertaken (see the aforementioned example for CRUD-Operations). This affects not only the amount of data transferred, but also enables more direct traceability and processing of changes for the software tools, as well as more local validation possibilities.
Alternatively, single requirements can be called upon with a diversity of tools via OSLC, but unfortunately OSLC is not as expressive as ReqIF (i.e. it lacks heirarchies). The focus of OSLC lies rather on the linking of ALM artifacts. OSLC is therby more abstract and more universal. This also hinders the development of reqirements engineering tools which would cope much better with a data model that is closer to the actual structure of requirements documents, such as the ReqIF data model.
A further technical advantage of RASAS is in respect to the OpenAPI standard and what the corresponding tool kit (Swagger) offers. Out of the RASAS specification, interface code/documentation can be generated fully automatically, for both client and service/server, and this with an expansive selection of programming languages and geared to an array of frameworks and libraries. By and large, the integration of RASAS in a software tool is reduced to the implementation of data mappings and validation logic (see details).
RASAS is available as open source under the Apache license version 2.0. Click the following link for further details.
Copyright 2018 Individual Standard IVS GmbH
Licensed under the Apache License, Version 2.0 (the “License”); you may not
use this file except in compliance with the License. You may obtain a copy
of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Click on the button below to download RASAS.
Client as well as service/server can be automatically generated out of the RASAS specification. For this task, open source tools from Swagger can be used. For one thing, a web editor is available for online or offline use, and by which the generation can be initiated. Alternatively, a command line based Java program, Swagger Code Generator, may be used to carry out the generation. A generated client contains API methods, which are already fully functional and can be directly put to use in accessing a service. A generated service in contrast, contains API methods whose bodies are empty and need to be filled in (with the implementation of data mappings and, if applicable, validation).
Access to a completed RASAS conformed service is accomplished via a URL. Host name and port number of the service must be known. Should the service run on the same computer as the client application, the host name is ‘localhost’. The following example illustrates how a service is accessed. A conventional web browser serves as client.
In this example, the URL https://localhost:8081/v1/reqif/specifciations delivers a result in JSON format, which contains all SPECIFICATIONS of a ReqIF document. The returned result is navigable, which means that clicking the URL of an ATTRIBUTE-DEFINITION leads to its definition. Operations of the kind CREATE, UPDATE und DELETE cannot (for test purposes) be executed directly over the web browser. For such purposes, a web interface is available which Swagger directly provides when the service is generated.
Individual Standard IVS has in addition, created a reference implementation of a RASAS service. This service utilizes a ReqIF file as data basis in backend, meaning that data accessed through the service is pulled from this file and changes over the service will be carried over to it. In the following, the user interface is portrayed by which this service may be configured, started and halted. For more information, we are happy to demonstrate this reference implementation and provide insight in how it's realized.
Do you have any questions or need support in the use of RASAS? Then contact us per email at rasas[at]individual-standard.com.
Please note that the latest version of the RASAS specification has no claim to completeness regarding the possibilities offered by ReqIF. Do you notice anything in the specification or have an idea or suggestion for improvement/expansion? The don't hesitate to contact us at the aforementioned email address.