**2. The essence of quality - Requirements and quality requirements**

Reeves and Bednar (1994) have discussed different definitions of quality in business context. They state that the concept of quality has had multiple and often unclear definitions and look more closely at four of them: quality as 'excellence', 'value', 'conformance to specifications', and 'meeting expectations'. Excellence means meeting the highest criteria in some area like intelligence, strength etc. The value aspect introduced price, or value, as an additional determinant of consumer's decision. Different compatibility requirements in production of component based machines lead to equaling quality with conformance to specifications and to making quality measurable. Finally the most pervasive definition 'meeting customer's expectations', according to Reeves and Bednar (1994), grew out of services marketing. It is also the most complex definition and most difficult to measure. Reeves and Bednar (1994) conclude that a global definition of quality does not exist and different definitions are appropriate in different contexts. The IEEE Standard Glossary of Software Terminology offers a two part definition of system quality: "the degree to which a system, component or process meets specified requirements" and "the degree to which a system, component or process meets customer or user needs or expectations. It coincides with the fourth definition discussed by Reeves and Bednar (1994).

Defining quality can be started from the viewpoint that in very general terms information system quality can be seen as determined by the existence and intensity of something pertaining to the system, identifiable and desired by actors and stakeholders. This point of view is in a way similar to the definition of quality as 'meeting expectations' above. What is desired is referenced to by using adjectives and abstract nouns and commonly interpreted as characteristics or features that reside inside and constitute an integral part of the entity (system) being described. Quality definitions like in ISO 9126 reflect this viewpoint. It gives in the annex a general definition for quality taken from ISO 8402:1994 (replaced now by ISO 9000:2000): "the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs" (ISO 9126 (2001, 20)). Analysis of the meaning of adjectives and abstract nouns used for qualities discloses, however, that they refer actually to certain states of affairs or relationships between the system and things in its context. By taking, for example, ISO 9126 quality model's six main characteristics functionality, reliability, usability, efficiency, maintainability and portability as examples, one can see that they all refer to a relationship between information system and its context. Functionality is the capability of software to provide functions which meet stated and implied needs (ISO 9126, 7). It is clearly a relationship between the product, its users and business processes they have to carry out. Reliability is defined as the capability of software to maintain a specified level of performance under specified conditions (ISO 9126, 8). Again it is about a relationship, this time a relationship between the product, a specific instance of using it and certain conditions. Usability is the capability of software to be understood, learned, used and attractive to the user when used under specified conditions (ISO 9126, 9). This characteristic relates the product to the user and certain conditions. Efficiency is the capability of software to provide appropriate performance, relative to resources used and under stated conditions

quality requirements, quality models and their DNA like role in system development has to

Reeves and Bednar (1994) have discussed different definitions of quality in business context. They state that the concept of quality has had multiple and often unclear definitions and look more closely at four of them: quality as 'excellence', 'value', 'conformance to specifications', and 'meeting expectations'. Excellence means meeting the highest criteria in some area like intelligence, strength etc. The value aspect introduced price, or value, as an additional determinant of consumer's decision. Different compatibility requirements in production of component based machines lead to equaling quality with conformance to specifications and to making quality measurable. Finally the most pervasive definition 'meeting customer's expectations', according to Reeves and Bednar (1994), grew out of services marketing. It is also the most complex definition and most difficult to measure. Reeves and Bednar (1994) conclude that a global definition of quality does not exist and different definitions are appropriate in different contexts. The IEEE Standard Glossary of Software Terminology offers a two part definition of system quality: "the degree to which a system, component or process meets specified requirements" and "the degree to which a system, component or process meets customer or user needs or expectations. It coincides

Defining quality can be started from the viewpoint that in very general terms information system quality can be seen as determined by the existence and intensity of something pertaining to the system, identifiable and desired by actors and stakeholders. This point of view is in a way similar to the definition of quality as 'meeting expectations' above. What is desired is referenced to by using adjectives and abstract nouns and commonly interpreted as characteristics or features that reside inside and constitute an integral part of the entity (system) being described. Quality definitions like in ISO 9126 reflect this viewpoint. It gives in the annex a general definition for quality taken from ISO 8402:1994 (replaced now by ISO 9000:2000): "the totality of characteristics of an entity that bear on its ability to satisfy stated and implied needs" (ISO 9126 (2001, 20)). Analysis of the meaning of adjectives and abstract nouns used for qualities discloses, however, that they refer actually to certain states of affairs or relationships between the system and things in its context. By taking, for example, ISO 9126 quality model's six main characteristics functionality, reliability, usability, efficiency, maintainability and portability as examples, one can see that they all refer to a relationship between information system and its context. Functionality is the capability of software to provide functions which meet stated and implied needs (ISO 9126, 7). It is clearly a relationship between the product, its users and business processes they have to carry out. Reliability is defined as the capability of software to maintain a specified level of performance under specified conditions (ISO 9126, 8). Again it is about a relationship, this time a relationship between the product, a specific instance of using it and certain conditions. Usability is the capability of software to be understood, learned, used and attractive to the user when used under specified conditions (ISO 9126, 9). This characteristic relates the product to the user and certain conditions. Efficiency is the capability of software to provide appropriate performance, relative to resources used and under stated conditions

**2. The essence of quality - Requirements and quality requirements** 

with the fourth definition discussed by Reeves and Bednar (1994).

start from the meta-level.

(ISO 9126, 10). It relates the product to resources and use under certain conditions. Maintainability is the capability of product to be modified and adapt to changes in environment, requirements and functional specifications. Again it is clearly about the product in relation to its context. Finally portability is defined as the capability of software to be transferred from one environment to another (ISO 9126, 11).

The search for the essence of quality can as well be started from inside the system. Taking an internal view, any information system can be described exactly and without remnants by indicating its architectural type, programming language used, design patterns, layers and packages, by listing procedures and methods, records in the database, series of instructions, and so on. This kind of description does not, however, explain WHY these constituents are required. In some cases an element is needed to create another element. But for what is the latter needed? Following the chains of *WHY*s one comes in the end out of the system internals into some desired relationship between system and its context, even if it is just a relationship between system and individual actor. Accordingly, for to explain *WHY* a design pattern, method, etc. is required or needed, these relationships must be described and understood. After finding the raison d'être of internal constituents in system-context relationships, the constituents themselves can be viewed as contributing factors in the former.

The fulfilment of quality requirements is not only dependent of internal system characteristics. Studies on information system quality show that external things can also have an impact on the desired relationships. Narasimhaiah and Lin (2010), for example, have studied external contributors. They focus on organizational and individual human factors associated with quality attributes like reliability, ease-of-use, maintainability, usefulness and relevance. They found as external determinants of software quality things like attitude of management, responsiveness and capability of IS department and capability of users themselves. Each of the determinants was further decomposed into smaller items. Capability of users, for example, consisted of users' knowledge in the system, training received, involvement in or resistance to the system, and technical competency. When it comes to super-attributes like sustainability the importance of external contributors is evident.

Figure 4 depicts the above viewpoints. It lists along the upper part of the ellipse a number of terms used in literature for referring to those subcategories of requirements that are commonly regarded as quality requirements. Functional requirements are added to the set on basis of the discussion above. Each individual requirement (NR1, G1 and FR1) or "desire" points to a state of affairs or relationship (R1, R2 and R3) between information system and its context. At the same time these requirements point to certain concrete system features (e.g. architecture and method) and things (T1, T2 and T3) outside the system. The former, desired relationships, explain the need for the latter, concrete system features and external conditions. Accordingly, if a developer starts asking in respect of any internal system feature that is under design or implementation, why it is required, he or she finally always traces back to some desired relationship between the system and its environment. This subordinate status of system internals and externals compared to the expected systemcontext relationships explains the meaning of the expressions "in the first place" and "in the second place" in the following definition paragraph. The two-tiered nature of system context, discussed in section1, is represented in Figure 4 by the two circles around the system rectangle.

Quality Model – Master Plan and DNA of an Information System 137

Given the definition of information system quality put forward in previous section it is obvious that the design for a quality technical artifact, being created and functioning in its context of development and use, has to cover quite a number of different aspects. Describing a state of affairs or relationship takes much more than describing an entity and its attributes. Case study findings (Finne, 2011) suggest that a comprehensive model, that is needed to fully account for the quality of an information system as an end product of development process, appears to be a hybrid model with six sub-models. It can alternatively be described as an intersection of models. Figure 5 represents a meta-level view of the hybrid model.

**3. A comprehensive quality model** 

Fig. 5. A meta-level view of information system quality model

The first sub-model, 1) human actors with their perspectives and views (symbolized by the filled triangle without borders) is actually part of an activity or process (quality modeling or system development) model. Actors are typically seen as elements of activity models. Next, to gain an understanding of the target information system on necessary levels of abstraction 2) an information system model is needed. To deal correctly with 3) context one needs to model it to some extent. Next, the 4) domain and quality attribute set reflects the core requirements and areas of concern for the stakeholders, and can be viewed as a model of overall system quality. Individual 5) quality attribute models are in essence models of

Fig. 4. Quality requirements and contributors

Quality of information system as a technical artefact in its context of development and use is in the first place determined by the existence, lack, intensity or number of desired relationships between information system or system constituent and its context. It can also be characterized as a desired state of affairs. In the second place quality of information system is determined by the existence, lack, number of or intensity of elements, inside or outside the system, contributing to the realization of the desired relationships. These elements get in a way there "justification" or "raison d'être" through the desired system-context relationships. Consequently individual qualities as well as overall quality of information system must be defined and measured in terms of these relationships.

'Requirement' as such is a broader notion meaning anything required, be it a certain quality, or something needed to realize it, or something else needed in the system for some reason. The main difference between quality attributes and other attributes, or quality requirements and other requirements, is that the former refer in first place to desired relationships between information system and its context and have more importance (priority) to actors than the latter, and the latter can often be derived from the former. Consequently quality requirements constitute the core of requirements for an information system. Priority, definition and measured level of implemented quality requirements are often relative to use case, actor, or some feature of the context. Therefore actors usually agree on goals regarding to what degree quality requirements need to be met.
