3.3 Non-Functional Requirements

NF-requirements are the means to state conditions on implementations of software components. Syntactically, they are usual boolean expressions enriched with some ad hoc constructs for non- functionality. Their purpose is to express relationships between NF-attributes and to represent the environment where implementations are to be inserted:

• Completing NF-specifications. NF-requirements are used in NF-specifications to state the conditions that every implementation of a software component must fulfil. In fact, they may appear at three different places: system modules, in which case the NF-requirement applies in all the components of the system; attribute modules, so that the NF-requirement is valid in every component importing this module; and NF-specification modules, to state a NF-requirement locally to a component.
• Relating measurement units. Efficiency is stated in components using different measurement units, but there has been no way to relate their value up to now. It seems natural to leave measurement units unrelated in the modules introducing them, because this yields components that can be reused in many contexts; however, it also seems convenient to relate the units once the components are considered as part of a particular software system. This kind of information is useful not only to complete non-functional specification of systems, but also to allow the evaluation of expressions involving different measurement units, which is essential in order to find out if an implementation satisfies this kind of NF-requirements.
• Fixing implementations of imported components. NF-requirements appearing in the NF-behaviour module bound to an implementation V in a system S state the conditions that the implementations of the software components imported by V must fulfil in S . In the general case, V will include a list of NF-requirements for every imported component; NF-requirements in the list are considered in order of appearance (which corresponds to the usual case of having requirements with different degrees of importance). As an alternative to the list, an implementation for a particular software component may be fixed directly by its name.

  Note that a single software component may be required in different ways at different places in the system due to the existence of different NF-requirements for it. Eventually, this will cause different implementations of the same component to coexist; this situation is supported by many programming languages (for instance, the O.-O. family using inheritance to represent the implementation relationship), although free interaction is usually restricted (see [Sit92, Fra94] for different proposals to avoid such restrictions).