RDL

RDL language

RDL is textual language for functional requirements description. It allows to define requirements with a pseudo natural language (ie a constrained natural language). The RDL language allows to specify simple and conditional requirements (if/then/else). Simple requirements represent the bevahiour of system in terms of observable properties with their values and actions the system can perform.

The RDL language describes the actions performed by the system in terms of service activations. Each service activation has a subject and stake holders in the service are treated as complements of the service. The stake holders in the service can be actors or business concepts. The services are categorized based on their occurrence in time. For instance, service activation can represents a service which can be activated in the future; service activation did represents a service which has been occurred in the past; service activation does represents the service in activation state.

Beside services, the RDL language also represents the state of the system as observables. An analogy can be drawn between the observables and attributes of an actor or business concept. Observable properties can be logically related to each others using logical operator (and/or). The RDL language defines two types of observable properties: those whose value remains stable after an activation of service or action performed by the system (keywords must be, is, is not), and those whose value changes due to an activation of service or action performed by the system. Stable observed properties can be described

The requirements can be related to each others using logical operators (and/or), or based on their temporal properties. Temporal requirements can be further categorized into synchronous and asynchronous. Synchronous requirements are based on when, after, before keywords, while asynchronous requirements are based on until and while keywords.

Import of RDL requirements

For the model-driven R2A platform to be able to process them, textual requirements specifications, such as RDL ones, need to be imported into models. To this end, the R2A platform makes use of the parser facility of the generis Sintaks tool.

Sintaks is a model-based generic tool that makes it possible to get a model representation of a text (parsing), but also to pretty print a text from a given model. Sintaks has been built with a model-centric approach: the bridge between an abstract syntax (ie a metamodel) and a concrete syntax (ie a grammar) is specified by means of a dedicated Sts model. This model allows the designer to define the links between the elements of a model and their representation in textual files. Further information about the Sintaks tool is available on the Sintaks web page.

The R2A platform provides all required items for being able to import RDL requirements into the R2A core metamotel. These items include:

• the RDM metamodel, which is the metamodel-based definition of the RDL language.
  
• the RDL Sts model, which describes how to bridge the RDL grammar (concrete syntax) and the RDM metamodel (abstract syntax).

Support for additional textual languages

Requirements specifiers may have their own textual languages for requirements specifications. The use of the Sintaks tool greatly eases the process of importing a textual requirements description into the R2A platform. In case the concepts of a requirements language can be mapped to concepts already defined in the RDL language, the designer just has to provide the Sts model that makes it possible to build a RDM model from its specific requirements language. In case the concepts handled of a requirements language cannot be mapped to the RDL language, the designer will have to provide both its own input requirements metamodel (equivalent to the RDM metamodel) and the associated Sts model. Furthermore, it will also be necessary to define the way these input requirements must be interpreted into concepts of the R2A core metamodel (for further details, see Requirement to Analysis Core section).