**3. A comprehensive quality model**

136 Security Enhanced Applications for Information Systems

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

'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

Fig. 4. Quality requirements and contributors

to what degree quality requirements need to be met.

relationships.

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.

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

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

psychological and cognitive factors that determine what an actor wants to see or how an actor interprets what is seen. In terms of quality modeling a particular view usually covers

For each actor, the knowledge about context, the knowledge about information systems in general and about the specific system under modeling together with the perspectives given by the roles and work the actor participates, constitute a kind of *frame of reference* that determines the appearance of the system to the actor. Perspectives and views which are presented and shared in the course of quality modeling form the intersection of individual frames. Figure 6 depicts the main elements of actor's frame of reference. The system is depicted on a very high level of abstraction as a structure built from different constituents, having contents and acting in a particular way. T1, etc. stand for "things" and S1, etc. for

An information system as a technical artifact consists of electronic and non-electronic components (*constituents*), their functioning (*behavior*) and relationships (*structure*). It includes the human and machine interfaces for data input and output. It is used to store, process, produce and present information (*contents*) in order to support human activities, including entertainment. Information products created by the system or serving as input into system are regarded as elements in a wider integrated system or the human information behavior as a whole. From the perspective of product quality modeling the systems elements have no advance justification. The reason or explanation for their existence comes through their ability to contribute for fulfilling quality requirements. Starting from a mere black-box view, gradually, according to the needs of attributing some qualities to lower level components and finding contributors to the qualities from inside information system, more detailed architectural descriptions are used. Good architectural descriptions are worth of gold but unfortunately a rarity in system development projects.

From the perspective of quality modeling *context* comprises all the elements in system environment that are members in the desired relationships between the system and context. These relevant entities can be human or non-human, independent of the spatial or temporal

distance. Business model forms an important part of context model.

only some parts of the information system and context.

"systems" in the context of system and actor.

Fig. 6. Actor's frame of reference

desired system-context relationships or states of affairs. Finally, the 6) metrics part is a model by itself. It describes procedures and means of determining if the intermediate or end product of development process complies with the design in respect of quality. Following paragraphs give a detailed definition to meta-model elements. D1 and D2 stand for two sample domains. QA1, QA2, QA3 and QA4 are individual quality attributes. C1 and C2 symbolize system constituents, and E1 symbolizes an entity in the context. UC in "Business UC" stands for use case. Goal means a goal value set for a quality attribute. The overlapping of rectangles symbolizes:


People or groups of people who have some meaningful relationship with the information system under scrutiny are called *actors*. They are affected by the qualities of the information system or its products. A general naming for actors that can also be used is "stakeholders". Some actors may never use the system, but are anyway somehow interested in it or affected by it and its products. The term "*informants*", in turn, means a sub-set of actors who actually participate in quality modeling or quality measuring and give some relevant information. Actors are part of the information system context.

Human actors have certain perspectives on and views of information system and its context that are reflected in resulting quality models. Each quality model element can in fact be traced back to a particular actor or actor group. A *perspective* is characterized by the actor's background, organizational roles and activities, beliefs, values, etc., and actor's relationship to the information system on basis of them. The former are at the same time elements of the information system context. A *view* of information system and its environment, in turn, is characterized by what it excludes and what it includes, i.e. by the constituents or elements visible in the view and their relationships. The elements in a view can be activities and processes as well as other things. A view of system can be concrete (through using or creating the system) or based on system descriptions. It can be general or detailed, partial or complete and so on. A view can be affected by elements constituting the perspective or other

desired system-context relationships or states of affairs. Finally, the 6) metrics part is a model by itself. It describes procedures and means of determining if the intermediate or end product of development process complies with the design in respect of quality. Following paragraphs give a detailed definition to meta-model elements. D1 and D2 stand for two sample domains. QA1, QA2, QA3 and QA4 are individual quality attributes. C1 and C2 symbolize system constituents, and E1 symbolizes an entity in the context. UC in "Business UC" stands for use case. Goal means a goal value set for a quality attribute. The overlapping






People or groups of people who have some meaningful relationship with the information system under scrutiny are called *actors*. They are affected by the qualities of the information system or its products. A general naming for actors that can also be used is "stakeholders". Some actors may never use the system, but are anyway somehow interested in it or affected by it and its products. The term "*informants*", in turn, means a sub-set of actors who actually participate in quality modeling or quality measuring and give some relevant information.

Human actors have certain perspectives on and views of information system and its context that are reflected in resulting quality models. Each quality model element can in fact be traced back to a particular actor or actor group. A *perspective* is characterized by the actor's background, organizational roles and activities, beliefs, values, etc., and actor's relationship to the information system on basis of them. The former are at the same time elements of the information system context. A *view* of information system and its environment, in turn, is characterized by what it excludes and what it includes, i.e. by the constituents or elements visible in the view and their relationships. The elements in a view can be activities and processes as well as other things. A view of system can be concrete (through using or creating the system) or based on system descriptions. It can be general or detailed, partial or complete and so on. A view can be affected by elements constituting the perspective or other


become visible and are defined in connection with use cases and scenarios.

of rectangles symbolizes:


reviewed during modeling of individual attributes.

order of priority in connection with different use cases.

are system constituents or things in the system context.


(taking into account the whole attribute set).

Actors are part of the information system context.

psychological and cognitive factors that determine what an actor wants to see or how an actor interprets what is seen. In terms of quality modeling a particular view usually covers only some parts of the information system and context.

For each actor, the knowledge about context, the knowledge about information systems in general and about the specific system under modeling together with the perspectives given by the roles and work the actor participates, constitute a kind of *frame of reference* that determines the appearance of the system to the actor. Perspectives and views which are presented and shared in the course of quality modeling form the intersection of individual frames. Figure 6 depicts the main elements of actor's frame of reference. The system is depicted on a very high level of abstraction as a structure built from different constituents, having contents and acting in a particular way. T1, etc. stand for "things" and S1, etc. for "systems" in the context of system and actor.

Fig. 6. Actor's frame of reference

An information system as a technical artifact consists of electronic and non-electronic components (*constituents*), their functioning (*behavior*) and relationships (*structure*). It includes the human and machine interfaces for data input and output. It is used to store, process, produce and present information (*contents*) in order to support human activities, including entertainment. Information products created by the system or serving as input into system are regarded as elements in a wider integrated system or the human information behavior as a whole. From the perspective of product quality modeling the systems elements have no advance justification. The reason or explanation for their existence comes through their ability to contribute for fulfilling quality requirements. Starting from a mere black-box view, gradually, according to the needs of attributing some qualities to lower level components and finding contributors to the qualities from inside information system, more detailed architectural descriptions are used. Good architectural descriptions are worth of gold but unfortunately a rarity in system development projects.

From the perspective of quality modeling *context* comprises all the elements in system environment that are members in the desired relationships between the system and context. These relevant entities can be human or non-human, independent of the spatial or temporal distance. Business model forms an important part of context model.

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

attributes. It can also be named a 'desired state of affairs'. In this way the system is linked with those entities in actors' minds or physically. Certain facts, called *indicators*, indicate the existence and intensity of the relationship in connection with real use cases and scenarios. A quality model can in addition list negative facts that show the lack of the desired relationship. A general formal presentation of the desired relationship is called *model*. It can be given, for example, in the form of an entity relationship (ER) model. Figure 8 gives a simplified example. It is taken from a quality modeling case study conducted in Zanzibar. It is part of the security-attribute-model and shows three entities: a land registration system (LRS), one human actor and one external connected information system. One security related attribute (security mechanism) is attached to LRS and another (ICT skills) to the human actor. When the human actor or external system tries to connect to LRS the latter either denies or allows the connection and shows and hides information according to implemented security rules. This really is a simplified example. In practice one can identify a number of additional relevant attributes. And the description of relationship is more

Fig. 7. An example of domain-attribute set

advanced.

A *quality attribute* refers in first place to a desired relationship between information system and its context or to a number of connected relationships. The existence and intensity of this relationship determines the level of quality in question. In a domain-attribute set each quality attribute can be given a general *definition* and a *goal value*, and it can be *attributed* or allocated to the system as a whole or some of its constituents. Having goals is essential in defining and assessing quality. Attribution to a constituent means that the particular quality of the constituent determines in fact the same quality of the whole system. Qualities are of high importance to actors and form a prioritized set.

*Domain* is a field of thought or area of concern to the actors in connection with which a quality attribute or group of attributes is relevant. It groups together related attributes that can be viewed as individual concerns. Each domain in an attribute set or collection is given a general *definition*.

A *domain-attribute set* is a *prioritized* list of all quality attributes ascribed to the information system as a whole or to a particular constituent. The attributes in the set are given a general definition and goal value, grouped according to prioritized domains and related to each other. Attributes themselves are prioritized on the level of the whole set, inside domains or both. Priority is characteristic of quality determining attributes. Different factors, among them actors' perspectives and views, have an impact on the final selection and prioritization of attributes. Quality *domain-attribute collection*, in turn, is a general set or supply of domains and quality attributes that can be used as a source when assembling the system specific domain-attribute set. Specific attribute collections can be created for different types of systems.

Figure 7 shows as an example a domain-attribute set that was used in an EMIS (Education Management Information System) case study (Finne, 2006). Attributes sustainability and suitability are positioned in the middle of the "palette" to underline their composite nature. This kind of presentation helps to identify biases and gaps in system's quality design. In Figure 7, for example, neglected domains are 'architecture and design', 'change' and 'performance'. Predefined, general or system type specific attribute collections, in turn, can act as starting points and checklists ensuring that the experiences of similar information systems and similar environments, or information systems in general, are taken into account. At the same time it must be kept in mind that no listing can cover all possible quality characteristics relevant to all possible information systems. Similarly a fixed and non-controversial categorization of quality attributes is probably impossible.

*Business use cases*, as part of the business model, represent the processes of an organization with or without explicit reference to supporting information systems. A *system use case*, for its part, represents the use of system per se, without, in the first place, drawing attention to its connection to business processes. The term *scenario*, in turn, refers to particular circumstances or to a flow of events, other than use cases, where the role of human actors as users of an information system sometimes can be non-existent, or not focused on.

Most of the characteristics that are traditionally called 'quality attributes' refer to a desired *relationship* or set of desired relationships *between the information system*, or its constituent, *and* one or more entities in the *context*. This can be regarded as characteristic of quality

A *quality attribute* refers in first place to a desired relationship between information system and its context or to a number of connected relationships. The existence and intensity of this relationship determines the level of quality in question. In a domain-attribute set each quality attribute can be given a general *definition* and a *goal value*, and it can be *attributed* or allocated to the system as a whole or some of its constituents. Having goals is essential in defining and assessing quality. Attribution to a constituent means that the particular quality of the constituent determines in fact the same quality of the whole system. Qualities are of

*Domain* is a field of thought or area of concern to the actors in connection with which a quality attribute or group of attributes is relevant. It groups together related attributes that can be viewed as individual concerns. Each domain in an attribute set or collection is given a

A *domain-attribute set* is a *prioritized* list of all quality attributes ascribed to the information system as a whole or to a particular constituent. The attributes in the set are given a general definition and goal value, grouped according to prioritized domains and related to each other. Attributes themselves are prioritized on the level of the whole set, inside domains or both. Priority is characteristic of quality determining attributes. Different factors, among them actors' perspectives and views, have an impact on the final selection and prioritization of attributes. Quality *domain-attribute collection*, in turn, is a general set or supply of domains and quality attributes that can be used as a source when assembling the system specific domain-attribute set. Specific attribute collections can be created for different types of

Figure 7 shows as an example a domain-attribute set that was used in an EMIS (Education Management Information System) case study (Finne, 2006). Attributes sustainability and suitability are positioned in the middle of the "palette" to underline their composite nature. This kind of presentation helps to identify biases and gaps in system's quality design. In Figure 7, for example, neglected domains are 'architecture and design', 'change' and 'performance'. Predefined, general or system type specific attribute collections, in turn, can act as starting points and checklists ensuring that the experiences of similar information systems and similar environments, or information systems in general, are taken into account. At the same time it must be kept in mind that no listing can cover all possible quality characteristics relevant to all possible information systems. Similarly a fixed and

*Business use cases*, as part of the business model, represent the processes of an organization with or without explicit reference to supporting information systems. A *system use case*, for its part, represents the use of system per se, without, in the first place, drawing attention to its connection to business processes. The term *scenario*, in turn, refers to particular circumstances or to a flow of events, other than use cases, where the role of human actors as

Most of the characteristics that are traditionally called 'quality attributes' refer to a desired *relationship* or set of desired relationships *between the information system*, or its constituent, *and* one or more entities in the *context*. This can be regarded as characteristic of quality

non-controversial categorization of quality attributes is probably impossible.

users of an information system sometimes can be non-existent, or not focused on.

high importance to actors and form a prioritized set.

general *definition*.

systems.

Fig. 7. An example of domain-attribute set

attributes. It can also be named a 'desired state of affairs'. In this way the system is linked with those entities in actors' minds or physically. Certain facts, called *indicators*, indicate the existence and intensity of the relationship in connection with real use cases and scenarios. A quality model can in addition list negative facts that show the lack of the desired relationship. A general formal presentation of the desired relationship is called *model*. It can be given, for example, in the form of an entity relationship (ER) model. Figure 8 gives a simplified example. It is taken from a quality modeling case study conducted in Zanzibar. It is part of the security-attribute-model and shows three entities: a land registration system (LRS), one human actor and one external connected information system. One security related attribute (security mechanism) is attached to LRS and another (ICT skills) to the human actor. When the human actor or external system tries to connect to LRS the latter either denies or allows the connection and shows and hides information according to implemented security rules. This really is a simplified example. In practice one can identify a number of additional relevant attributes. And the description of relationship is more advanced.

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

was noted above in connection with actor's perspective and view, the objects of measurement are in each case defined, observed and measured in a certain *frame of reference*. The things that cause relativity, i.e. difference of results compared to another frame of reference, constitute together the set of axes of the frame. They include, for example, business and system use cases, business processes, observer's organization and role in it.

There exist many alternative ways of representing graphically the model of a specific quality attribute, or even the entire quality model of a particular system. In general, however, it is often impossible to fit all information into one diagram. This problem has to be solved by representing only core features graphically, by attaching textual descriptions or distributing the information on several diagrams. Figure 10 exemplifies how little information actually fits in a diagram that can be viewed without scrolling. It is again taken from the EMIS study and it summarizes some core features of 'coverage' quality. The attribute refers to the concern of covering with the system all the information that potential users need. It is ranked as number one concern. The general definition has been written by the researcher. Only one indicator is shown in the upper right corner. The model reflects the perspectives and views of researcher, 11 selected informants and the EMIS development team. Attribute belongs to the data-domain and is positively related to usefulness. Of the context elements only an unnamed business process (P1) is visible in the diagram. It represents the large number of business processes where actors use information provided by the system. Coverage has been defined with respect to process data use case. It refers to use of EMIS for processing statistical information for example in order to create different statistical presentations. 100 per cent coverage is set as goal. Measuring instrument, unit and

Fig. 9. Example of relationships between top five attributes

Relativity is characteristic of information system quality.

procedure are indicated in the lower left corner of the diagram.

Fig. 8. A simplified ER-model depicting the security system-context relationship

*Contributor* is a thing *inside or outside* the information system that affects in a positive way a desired relationship between system and its context. It can be alternatively called "factor". The description and understanding of system environment, discussed above, is important in identifying the external contributors. The internal things, in turn, are usually system constituents, behavior (functioning) or structures and consequently part of the system model. Desired relationships are the "raison d'être" of contributors and quality attributes can be said to refer in the second place to the latter. What are the contributors in reality with respect to each quality is in the end a subject of empirical study. Thereafter, based on achieved theory system developers can instantiate the contributor elements in system design.

Attribute relationships are a feature of domain-attribute set. These relationships can be identified by comparing indicators, models, contributors and measured values. Indicator sets, for example, can be separate, overlapping, or one included in another. Contributors, in turn, can be indifferent to one another, cooperating (supporting), or conflicting. In theory there can be as many kinds of attribute relationships as there are relationship types between indicators or contributors. Figure 9 shows a way to depict diagrammatically attribute relationships. It is taken from the same EMIS case study (Finne, 2006) as Figure 6 above. First, the circle at left represents five top ranked quality attributes. The angle of the slices represents the relative priority value (as a number in brackets) of attribute. In the matrix "+" sign stands for a positive contribution. As one can see from the matrix, the attributes are quite independent. Only usefulness is clearly influenced by most of the other attributes. Different signs in the intersection of rows and columns can symbolize different relationships. A similar matrix is used by Khaddaj and Horgan (2005).

A complete arrangement for measuring the existence and degree of a quality, i.e. of a desired relationship between system and its context, includes selection of *instrument, unit, scale, actors, and measurement procedure*. The *object of measurement* is in first place the existence and degree of certain desired system-context relationship represented by the indicators, and in the second place the existence and properties of internal and external contributors. As

Fig. 8. A simplified ER-model depicting the security system-context relationship

design.

*Contributor* is a thing *inside or outside* the information system that affects in a positive way a desired relationship between system and its context. It can be alternatively called "factor". The description and understanding of system environment, discussed above, is important in identifying the external contributors. The internal things, in turn, are usually system constituents, behavior (functioning) or structures and consequently part of the system model. Desired relationships are the "raison d'être" of contributors and quality attributes can be said to refer in the second place to the latter. What are the contributors in reality with respect to each quality is in the end a subject of empirical study. Thereafter, based on achieved theory system developers can instantiate the contributor elements in system

Attribute relationships are a feature of domain-attribute set. These relationships can be identified by comparing indicators, models, contributors and measured values. Indicator sets, for example, can be separate, overlapping, or one included in another. Contributors, in turn, can be indifferent to one another, cooperating (supporting), or conflicting. In theory there can be as many kinds of attribute relationships as there are relationship types between indicators or contributors. Figure 9 shows a way to depict diagrammatically attribute relationships. It is taken from the same EMIS case study (Finne, 2006) as Figure 6 above. First, the circle at left represents five top ranked quality attributes. The angle of the slices represents the relative priority value (as a number in brackets) of attribute. In the matrix "+" sign stands for a positive contribution. As one can see from the matrix, the attributes are quite independent. Only usefulness is clearly influenced by most of the other attributes. Different signs in the intersection of rows and columns can symbolize different

A complete arrangement for measuring the existence and degree of a quality, i.e. of a desired relationship between system and its context, includes selection of *instrument, unit, scale, actors, and measurement procedure*. The *object of measurement* is in first place the existence and degree of certain desired system-context relationship represented by the indicators, and in the second place the existence and properties of internal and external contributors. As

relationships. A similar matrix is used by Khaddaj and Horgan (2005).

Fig. 9. Example of relationships between top five attributes

was noted above in connection with actor's perspective and view, the objects of measurement are in each case defined, observed and measured in a certain *frame of reference*. The things that cause relativity, i.e. difference of results compared to another frame of reference, constitute together the set of axes of the frame. They include, for example, business and system use cases, business processes, observer's organization and role in it. Relativity is characteristic of information system quality.

There exist many alternative ways of representing graphically the model of a specific quality attribute, or even the entire quality model of a particular system. In general, however, it is often impossible to fit all information into one diagram. This problem has to be solved by representing only core features graphically, by attaching textual descriptions or distributing the information on several diagrams. Figure 10 exemplifies how little information actually fits in a diagram that can be viewed without scrolling. It is again taken from the EMIS study and it summarizes some core features of 'coverage' quality. The attribute refers to the concern of covering with the system all the information that potential users need. It is ranked as number one concern. The general definition has been written by the researcher. Only one indicator is shown in the upper right corner. The model reflects the perspectives and views of researcher, 11 selected informants and the EMIS development team. Attribute belongs to the data-domain and is positively related to usefulness. Of the context elements only an unnamed business process (P1) is visible in the diagram. It represents the large number of business processes where actors use information provided by the system. Coverage has been defined with respect to process data use case. It refers to use of EMIS for processing statistical information for example in order to create different statistical presentations. 100 per cent coverage is set as goal. Measuring instrument, unit and procedure are indicated in the lower left corner of the diagram.

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

shows how the creation and use of quality model elements are positioned in relation to object-

oriented software development process (as presented by Jacobson et al., 1999).

Fig. 11. Quality modeling in relation to object-oriented development process

Awareness of context as well as perspectives and views of actors who participate in system development is mandatory in any kind of development approach. IS, the technical artifact, must always be designed. Further, no system exists separate from requirements that are sometimes conflicting and need to be prioritized. Use cases and scenarios are important stuff even in agile methodologies. Finally every system must be tested, assessed and compared to requirements. In these respects quality modeling does not bring any extra burden to the picture. The point in quality driven development is that quality of an information system is understood to be in first place determined by the existence and intensity of desired system-context relationships and consequently as well defined and measured in terms of these relationships. The quality meta-model, presented in previous section, provides a template for designing the relationships and relating the resulting model to other models needed in system development process. The point is further that a system specific quality model is the arch-model in system development and never left out of sight,

Fig. 10. Graphical representation of coverage attribute model
