[Zurück]

H. Kaindl, M. Smialek, D. Svetinovic, A. Ambroziewicz, J. Bojarski, W. Nowakowski, T. Straszak, H. Schwarz, D. Bildhauer, J. Brogan, K. Mukasa, K. Wolter, T. Krebs:
"Requirements Specification Language Definition - Defining the ReDSeeDS Languages";
Bericht für EU, ReDSeeDS, Projektnr. IST-2006-033596; Berichts-Nr. D2.4.1, 2007; 233 S.

Requirements specification languages are abundant in the field of Requirements Engineering. However, most of them focus on formal representation only and are not used much in practice. Others provide a subset of natural language only and do not provide means for conceptual modelling. So, natural language is still the most widely used language for writing requirements specifications in practice. Generally, requirements specification languages do not integrate userinterface specifications, although requirements and user interfaces have a lot to do with each other.

Therefore, we defined a new language, the ReDSeeDS Requirements Specification Language (RSL). Our approach is intended to be comprehensive for practical use and includes, therefore, even unconstrained natural language. RSL integrates descriptions - constrained and unconstrained -, conceptual modelling-based on object-oriented ideas-and even user-interface specifications. RSL is, however, not simply an aggregation of existing concepts and language constructs. It has several distinguished and even unique features.

The behavioural part of RSL distinguishes between Functional and Behavioural Requirements. While the former specify the required effects of some system, the latter specify required behaviour across the system border, in the form of Envisioned Scenarios. Functional Requirements are further specialised into Functional Requirements on Composite System and Functional Requirements on System to be built. The former are fulfilled by an Envisioned Scenario, while the functions of the latter will make its execution possible. Related Envisioned Scenarios together make up a Use Case.

The structural part of RSL deals with models and descriptions of objects existing in the domain (environment) of the software system to be built - domain objects. These objects are part of a conceptual Domain Model (to-be). In addition, the concepts can (and should) be described in a defined vocabulary with phrases, containing terms which are organised in a terminology representation that integrates a dictionary with a thesaurus. RSL is the first language that integrates conceptual modelling with thesaurus features. The descriptions facilitate a better understanding of the concepts, which in turn facilitates a better understanding of the requirements.

We distinguish strictly between requirements and representations of requirements. Strictly speaking, only the latter can actually be reused. Requirements representations can be descriptive or model-based, and our RSL language makes this distinction explicit. The former describe the needs of certain requirements, while the latter represent models of the system to be built. A requirement is then to build a system like the one modelled.

The user-interface part of RSL contains language features for specifying user-interface elements and their dynamics. It deals with descriptions of various user-interface elements that can express various graphical or other types of elements existing in a user interface. It also includes user interface storyboards that show dynamic change in the user interface.

Based on the previous deliverables D2.1, D2.2 and D2.3, this deliverable contains a comprehensive description of RSL. First, it gives a conceptual overview and explanation of the approach and the language. In the second part, it provides a complete language reference including concrete syntax.

Requirements Language

http://publik.tuwien.ac.at/files/pub-et_13409.pdf

Projektleitung Hermann Kaindl:
Requirements Driven Software Development System