Task: Define System Limitations and Constraints

Based on the expressed wishes of the stakeholders, the developer is now able to define the limitations and constraints that these requirements mean for the system to be built.

Disciplines: Requirements

Purpose

This step is optional. It allows the model-driven synthesis of observers that monitor the system behaviour and allow reactions to violations of the constraint if embedded in an observer/controller architecture. The constraints identified in this step can also be the basis for a formal model of the system.

Relationships

Parent Practices	Goal-driven Requirements Elicitation
Roles	Primary Performer: Developer	Additional Performers: Stakeholder
Inputs	Mandatory: System Goals Document	Optional: Conceptual Domain Model
Outputs	System Goals Document

Main Description

An adaptive, open system has to be able to observe itself and its environment to identify system states in which undesirable behaviour can occur or in which the system functionality can not be upheld. Such conditions can be identified during requirements analysis and (semi-)formally described for use later on in the process. The formal description uses concepts, associations, and fields of the agents as captured in a domain model. During the process of formalising the constraints, additional concepts can be identified and added to this artefact.

The formal definition of the system's limitations can also facilitate the identification of so far hidden assumptions about the agents or the environment. If such an assumption is identified, the stakeholders can discuss it during the next iteration and either adapt the requirements accordingly or ensure during deployment that the assumption holds.

This task resembles the operationalisations of goals into constraints as described in [Dardenne et al., 1993].

Steps

Identify requirements that can be expressed as constraints

Requirements that express that a certain state or condition has to hold are natural candidates to be expressed as constraints.

Formalize system constraints and annotate requirements

The requirement has to be expressed as a (semi-)formal constraint. OCL is a natural candidate for the definition of the constraints since it allows statements over the elements of the domain model. Another possibility is the use of predicate logic.

Extend domain model and requirements if necessary

As constraints are defined on the elements of the domain model, the previous steps can serve as validation for the domain model. If constraints must be defined on elements that are currently not part of the domain model or if the data they evaluate must be collected by the agents, extend the domain model accordingly and define new requirements.

This material is made available under the Creative Commons—Attribution-ShareAlike License v3.0.

Parts of this material is based on the Eclipse Process Framework Practice Library, distributed under the Eclipse Public License V1.0.