**1. Introduction**

130 Security Enhanced Applications for Information Systems

Risk Management Guide for Information Technology Systems, 28.02.2011,Available from http://csrc.nist.gov/publications/nistpubs/800--30/sp800 --30.pdf

http://www.enisa.europa.eu/act/rm/cr/risk--management--

inventory/downloads

The goal of the chapter is to give a refined definition for the quality of information system as a technical artifact and based on that statement present a complete conceptual framework for quality modeling. Further, the chapter shows how a quality model as a master plan for information systems can drive and control the entire development process.

#### **1.1 Information system and its context - Models and objects of modeling**

Every theory has its surroundings and postulates. So has a theory about quality models, and it is better to make the main lines of these ideas explicit before presenting the theory itself. A human made information system (IS) as a technical artifact exists and operates always in the context of societies, organizations, personal lives etc. It is a tool used for gathering, storing, processing, presenting and exchanging (communication) information. These activities can be termed "information behavior" (Allen et al., 2011). Accordingly the context of an information system has a two-tiered structure (Figure 1). The inner tier, information behavior, is subordinate to the outer tier, human society. Information in general is used to support human activities, and technical information tools, in turn, are used to enhance the use of information.

Fig. 1. Two-tiered context of information system

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

kind of model generation, from bottom up and from top down, models on all levels grow better and better by the time and experience. Figure 3 depicts this relationship between

levels of modeling, and at the same time between practice and theory.

Fig. 2. Traditional objects of modeling in software engineering

Fig. 3. Levels of modeling, practice and theory

This chapter is about quality requirements, quality models and their DNA like role in system development. In order to be complete and avoid misunderstandings, an account of

In this context both information and information system are supposed to have meaningful functions, and because of these purposes human actors have various wants, needs and expectations about the information itself and the supporting system's behavior. This view is implicit for example in the writings where sense-making theory is applied to information system design (e.g. Muhren et al., 2008). Sense-making provides means to understand how information in general is used by humans (see e.g. Savolainen, 2006), which in turn should be reflected in information tools design. Another theory frequently used (e.g. Silva, 2007 and Macome, 2008) to explain the interplay between information system and its context is Actor Network Theory (ATN). ATN views technology as part of a network of human actors and nonhuman artifacts. And still one interesting framework has been developed by Alter (1999, 2008). He views information systems in connection with work systems that the former serve, and in the end information systems as special cases of work systems. Human society is full of work systems "in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific products and/or services for specific internal or external customers" (Alter 2008, 451). The definition of work system comprises projects, supply chains, web sites, etc.

In everyday life and scientific literature actors' expectations for information and information systems are commonly called requirements, and a part of them more precisely quality requirements. Each IS has a life course that contains various cyclical or repeating processes, like system development, moving from one platform to another, etc. ISO/IEC 12207 (2008), for example, gives a good picture of software lifecycle processes. In the course of these processes there are several points where requirements are captured and goals set, something – usually a system or component - to fulfill the requirements modeled, implemented and put into operation, and finally the results measured and evaluated. The words "modeling" and "designing" are in this chapter used interchangeably. And a "model" means the product of modeling or designing process, an abstraction of or a blueprint for something to be realized. The difference between requirements and a model based on them is that requirements express needs and desires and are often less structured and consequently written in the form "x is needed" or "x must be y", whereas a model is structured and statements are in indicative form like "x is y".

Traditionally modeling in software engineering has centered on the system itself as a product of development, the development process or the entire system life course (Figure 2). With respect to these three alternatives this chapter focuses on information system as a technical artifact seen in its context of development and use, primarily human activities. It does not go into the area of system development process or IS life cycle models. Consequently, the quality models that are discussed can be categorized as product quality models.

Modeling can take place on different levels of abstraction. And the actual object (X) that is modeled can be any real thing, not only an entity or process, but even a state of affairs as this chapter will show. After modeling and implementing several Xs one can create a general model of Xs or of certain type of Xs that consequently constitute theories of X. Finally, instance and general level models can be used to create a meta-model, a model for X-models that can be regarded as an even higher level of theory. The other way around, higher level model can be used as template for creating lower level models. By iterating this

In this context both information and information system are supposed to have meaningful functions, and because of these purposes human actors have various wants, needs and expectations about the information itself and the supporting system's behavior. This view is implicit for example in the writings where sense-making theory is applied to information system design (e.g. Muhren et al., 2008). Sense-making provides means to understand how information in general is used by humans (see e.g. Savolainen, 2006), which in turn should be reflected in information tools design. Another theory frequently used (e.g. Silva, 2007 and Macome, 2008) to explain the interplay between information system and its context is Actor Network Theory (ATN). ATN views technology as part of a network of human actors and nonhuman artifacts. And still one interesting framework has been developed by Alter (1999, 2008). He views information systems in connection with work systems that the former serve, and in the end information systems as special cases of work systems. Human society is full of work systems "in which human participants and/or machines perform work (processes and activities) using information, technology, and other resources to produce specific products and/or services for specific internal or external customers" (Alter 2008, 451). The

In everyday life and scientific literature actors' expectations for information and information systems are commonly called requirements, and a part of them more precisely quality requirements. Each IS has a life course that contains various cyclical or repeating processes, like system development, moving from one platform to another, etc. ISO/IEC 12207 (2008), for example, gives a good picture of software lifecycle processes. In the course of these processes there are several points where requirements are captured and goals set, something – usually a system or component - to fulfill the requirements modeled, implemented and put into operation, and finally the results measured and evaluated. The words "modeling" and "designing" are in this chapter used interchangeably. And a "model" means the product of modeling or designing process, an abstraction of or a blueprint for something to be realized. The difference between requirements and a model based on them is that requirements express needs and desires and are often less structured and consequently written in the form "x is needed" or "x must be y", whereas a model is structured and

Traditionally modeling in software engineering has centered on the system itself as a product of development, the development process or the entire system life course (Figure 2). With respect to these three alternatives this chapter focuses on information system as a technical artifact seen in its context of development and use, primarily human activities. It does not go into the area of system development process or IS life cycle models. Consequently, the quality models that are discussed can be categorized as product quality

Modeling can take place on different levels of abstraction. And the actual object (X) that is modeled can be any real thing, not only an entity or process, but even a state of affairs as this chapter will show. After modeling and implementing several Xs one can create a general model of Xs or of certain type of Xs that consequently constitute theories of X. Finally, instance and general level models can be used to create a meta-model, a model for X-models that can be regarded as an even higher level of theory. The other way around, higher level model can be used as template for creating lower level models. By iterating this

definition of work system comprises projects, supply chains, web sites, etc.

statements are in indicative form like "x is y".

models.

kind of model generation, from bottom up and from top down, models on all levels grow better and better by the time and experience. Figure 3 depicts this relationship between levels of modeling, and at the same time between practice and theory.

Fig. 2. Traditional objects of modeling in software engineering

Fig. 3. Levels of modeling, practice and theory

This chapter is about quality requirements, quality models and their DNA like role in system development. In order to be complete and avoid misunderstandings, an account of

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

(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

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

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

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

to be transferred from one environment to another (ISO 9126, 11).

importance of external contributors is evident.

former.

system rectangle.

quality requirements, quality models and their DNA like role in system development has to start from the meta-level.
