In order to design a software system, we start by eliciting a set of functional requirements and a set of non-functional requirements that describe what behaviors and what characteristics must be exhibited by the implemented system.
Usually natural language text is used for non-functional requirements because of its flexibility and adaptability. However, drawbacks such as ambiguity, inconsistency, and contradictions make this kind of information more difficult to analyze. There is a strong need to deal comprehensively with such requirements in order to improve the development process and to avoid errors that often lead to greater expense in software products.
In our project, the International Standard ISO/EC 9126 (1991) will be used as a starting point to identify non-functional attributes of products that are potentially relevant to be modeled in a software development process. In a later phase, more non- functional attributes will be included. The standard is primarily concerned with the definition of quality characteristics, which are expressed in terms of some high-level features of the software such as efficiency, reliability, and others. This standard collects quality needs with the main idea of defining a quality model and using it as a framework for software evaluation. A quality model is defined by means of general characteristics of software, which are further refined into subcharacteristics in a multilevel hierarchy. Measurable software attributes appear at the bottom of the hierarchy.
The ISO 9126 standard defines the characteristics of functionality, reliability, usability, efficiency, maintainability, and portability are being placed at the top of the hierarchy. An informative annex of this standard provides an illustrative quality model that refines these characteristics.
Software quality metrics allows developers to quantify up to what degree a software system meets non-functional requirements. Metrics, in the ISO 9126, typically give rise to quantifiable measures that are mapped onto scales. The rating levels definition determines what ranges of values on those scales count as satisfactory or unsatisfactory. Since quality refers to given needs, which vary from one evaluation to another, then there are no general rating levels possible: they must be defined for each specific evaluation. To determine objectively whether a given software product is satisfactory or not, one needs to define precisely the specific attributes (basic attributes) rather than express them in general qualitative terms (e.g., reliability, maintainability, portability, efficiency, etc.).
A language called NoFun (acronym for “NOn-FUNctional”) is a notation defined within our research group (Botella et al., 2001; Burgués & Franch, 2000; Franch, 1998) that
120 Salazar-Zárate, Botella & Dahanayake
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
focuses on representing non-functional aspects of software systems, at the product level within the component-programming framework. It is a formal language for description of software quality requirements using ISO/IEC 9126 framework (see Figure 1) to summarize quality characteristics. NoFun has also been used to represent quality models for particular software domains.
NoFun Overview
To achieve the goal of formalization within NoFun, we basically provide three different kinds of capabilities. First, there are modules for defining the different kind of concepts in the standard. Second, values for these attributes may be given and bound to particular software components, (i.e., the ones under evaluation). Third, additional constructs for representing quality requirements and assessment criteria are included. Concerning the first category, there are three main modules: characteristic, subcharacteristic, and attribute modules. Modules may import others, and nesting is allowed also. Nesting of modules enables stating of auxiliary definitions, although visibility rules must always be taken into account (symbols defined in nested modules are not exported). Following the standard, characteristic modules may not be defined as one in terms of another one. No such restrictions appear on the other types of modules; therefore, hierarchies of subcharacteristics and attributes may (and will) arise.
The upper part of Figure 1 shows an example of distribution of a quality model into modules. There are two characteristics defined in terms of four subcharacteristics. Following the ISO/IEC appendix, sharing of subcharacteristics between characteristics does not take place (although the language does not explicitly check this situation).
Subcharacteristics do indeed form a hierarchy; they may depend on zero or one or more subcharacteristics and attributes and a subcharacteristic may influence more than one subcharacteristic. Finally, attributes are defined at the bottom of the model, although attribute hierarchies may also be defined. Attributes depending on others are named derived attributes, as opposed to basic ones, whose values must be explicitly stated. Quality characteristics, subcharacteristics, and attributes (hereafter, quality enti- ties) are declared for a particular type. In addition to pre-defined types (called domains), mechanisms to define new ones are introduced. New domains may also be defined; encapsulated in yet another kind of module. Type constructs are rich enough to allow modeling of the usual quality entities. There are sets, functions, and tuples (for more details see Botella et al., 2001).
Assignment of basic attribute values are encapsulated in new modules (behavior modules), which are bound to the corresponding software components that are being evaluated. Behavioral modules are abstractions of software components in the sense that they contain all of the relevant information for quality evaluation.
Finally, quality requirements may be defined as restricting the values of the quality entities. Assessment criteria can be seen as a set of quality requirements; therefore, we do not distinguish between them. Quality requirements are stated using operators over the quality entities and these requirements may be categorized according to their importance. Requirements normally refer to characteristics and subcharacteristics, and rarely to attributes, due to their lower-level nature.
The rest of Figure 1 adds the behavior and requirement modules. The three software components under evaluation include a behavior module measuring the basic attributes.
Introducing Non-functional Requirements in UML 121
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written Figure 1: Layout of a quality model under ISO/IEC framework
Values of the attributes propagate up to the other quality entities (following the arrows in reverse direction). The requirement module containing assessment criteria for the evaluation refers in this case to one characteristic and two subcharacteristics. Here the result is simplified to only express success or failure; but, in Botella et al. (2001) it is shown that things are a bit more sophisticated because of the categorization of requirements. In addition to these elements, an orthogonal concept is the one of refinement. Refinement allows definition of quality models in an incremental manner, by specializing the more general ones. This kind of inheritance-like relationship yields to a structured representation of quality: models can be formulated first in a general way, later refined in particular domains (OO classes, ERP products, bespoke software, etc.), and further specialized for companies, projects, etc.
NoFun can be used to formally represent all the previously mentioned non- functional information. To illustrate what NoFun looks like, we present here an attribute module that shows basic and derived attributes:
attribute module DELIVERING_ISSUES
explanation date of delivery of components attribute Month declared as Integer [1..12] attribute Year declared as Integer [1970..] attribute Date derived
declared as Tuple(Integer[1..12], Integer[1970..]) defined as (Month, Year)
Products to evaluate Attributes Characteristics yes / no Req expressed in terms of Subcharacteristics Behavior Software Components Assignment C1 C2 SC1 SC2 SC3 SC4 SC5 SC6 Comp1 A4 A5 A3 A1 B1 B2 B3 SC7 A2 Comp3 Comp2
122 Salazar-Zárate, Botella & Dahanayake
Copyright © 2003, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited.
explanation name of company delivering the product. “Own” states for software produced in the company; use it instead of the name attribute supplier declared as string
end DELIVERING_ISSUES
and a requirement module:
requirement module DATE_FACTS on DELIVERING_ISSUES for
ACME
explanation requirement on the date of creation of ACME delivered software
definition
ACME-delivery-date: advisable
explanation Software made by ACME must not be dated
before April 1998, which is the date the company started to use OO methodologies
defined as
Supplier = ‘ACME’ implies
(Date.Year > 1998) or (Date.Year = 1998 and
Date.Month >= 4)
end DATE_FACTS
Both examples have been extracted from Botella et al. (2001). In this reference, as in Franch (1998) and Burgués and Franch (2000) a description of NoFun and some detailed examples can be found.
Using the formalizing ideas of the NoFun language and following a product- oriented approach, we aim to extend the UML language (Booch et al., 1998) in order to capture non-functional information.