[Zurück]

H. Kaindl, M. Smialek, D. Svetinovic, A. Ambroziewicz, J. Bojarski, M. el Jamal, W. Nowakowski, T. Straszak, J. Brogan, H. Schwarz, D. Bildhauer, J. Falb:
"Behavioural Requirements Language Definition - Defining the ReDSeeDS Languages";
Bericht für EU, ReDSeeDS, Projektnr. IST-2006-033596; Berichts-Nr. D2.1, 2007; 94 S.

Function and behaviour are mostly confused with one another or mixed up in requirements engineering. In addition, when specifying or handling requirements, it is usually not understood that actually representations of requirements are dealt with rather than requirements. In particular, indexing for reuse has to be done with concrete representations. While requirements are traditionally simply described in practice, mostly in natural language or some subset of it, requirements modelling as an approach to having accurate requirements capture, is being more and more introduced and utilised within software engineering methodologies. However, the conceptual differences between requirements capture approaches are not understood well.

The behavioural part of our requirements specification language 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 Envisionary 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 Envisionary Scenario, while the functions of the latter will make its execution possible. Related Envisionary Scenarios together make up a Use Case.

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 RRSL 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.

This deliverable contains the behavioural part of the requirements specification language, i.e., all the parts of the ReDSeeDS meta-model and other descriptions dealing with what happens over time across the system border. The language is capable of describing the dynamics of dialogue between the users (human or machine) of the system and that system precisely yet comprehensibly. This deliverable first gives a conceptual overview of this behavioural requirements specification language. In a second part, it provides a comprehensive language reference including concrete syntax.

Behavioural Requirements, Requirements Language

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

Projektleitung Hermann Kaindl:
Requirements Driven Software Development System