Kristian Beckers

Stephan Faßbender

Maritta Heisel

Federica Paci

Combining Goal-oriented and Problem-oriented Requirements Engineering Methods *

Keywords: requirements engineering, SI*, Problem Frames

Several requirements engineering methods exist that differ in their abstraction level and in their view on the system-to-be. Two fundamentally different classes of requirements engineering methods are goal-and problem-based methods. Goal-based methods analyze the goals of stakeholders towards the systemto-be. Problem-based methods focus on decomposing the development problem into simple sub-problems. Goal-based methods use a higher abstraction level that consider only the parts of a system that are relevant for a goal and provide the means to analyze and solve goal conflicts. Problem-based methods use a lower abstraction level that describes the entire system-to-be. A combination of these methods enables a seamless software development, which considers stakeholders' goals and a comprehensive view on the system-to-be at the requirements level. We propose a requirements engineering method that combines the goalbased method SI* and the problem-based method Problem Frames. We propose to analyze the issues between different goals of stakeholders first using the SI* method. Our method provides the means to use the resulting SI* models as input for the problem frame method. These Problem Frame models can be refined into architectures using existing research. Thus, we provide a combined requirements engineering method that considers all stakeholder views and provides a detailed system specification. We illustrate our method using an E-Health example.

Introduction

Eliciting and analyzing requirements of a system is important, because it is hard to built the right software if you do not know what right is. Several methods exist that support the eliciting and analyzing requirements. Fabian et al. [START_REF] Fabian | A comparison of security requirements engineering methods[END_REF] present a survey of security requirements engineering (SRE) methods and one of their finding is that the integration of different SRE is worthwhile. The reason is that these all produce different artifacts and support different views and abstraction levels. Hence, a combination of these results can improve the quality of the requirements.

We propose to combine goal-based and problem-based requirements engineering methods. We use the SI* modeling language [START_REF] Massacci | Security requirements engineering: The si* modeling language and the secure tropos methodology[END_REF] as an example for a goal-based method and problem frames [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF] as an example for a problem-based requirements engineering method.

The goal-based methods consider the views towards the system-to-be via its stakeholders' goals. The software to be developed is considered only as needed to achieve the goals. For example, on the one hand, a hospitals wants to provide treatment for a patient and requires monitoring data of the patient to administer the treatment. In this case only the monitoring data is modeled. This, however, is sufficient to analyze possible goal conflicts. On the other hand, a researcher wants to use this monitoring data to conduct a medical study. This can be in violation against the privacy goals of the patient. Hence, goal-based methods provide the means to detect and resolve these conflicts. However, the gap to a design description of the overall system is significant, because the system-to-be is only modelled in some artifacts that have a relation to a goal.

The problem-based methods follow a fundamentally different approach. These methods focus on the problem that shall be solved by the system-to-be. Problem-based methods model the environment and the system-to-be, called machine, in it. They describe requirements as an effect the system-to-be has on the environment. Refinements allow one to split the problem into sub-problems. Problem-based methods provide a description of the machine and the interaction with its environment. The sub-problems can be further refined into a design description and a system architecture, e.g., via the ADIT method [START_REF] Côté | A Systematic Approach to Software Evolution[END_REF][START_REF] Hatebur | Pattern and Component-based Development of Dependable Systems[END_REF]. Hence, the abstraction level of problem-based methods is lower than the abstraction level of goal-based methods.

Problem-based methods do not consider the views of all stakeholders and do not consider goals. Thus, they cannot detect or resolve goal-based conflicts. We propose to combine SI* with problem frames in order to create a method that considers all stakeholder views and can resolve goal-based conflicts, while also creating a description of the machine to be built and a structured way to create an architecture.

The rest of the paper is organized as follows. In the next section we discuss related work. In Section 3, we introduce the problem frame method and the SI* modeling language. Section 4 presents our method for seamless software development from goals to software architectures. In Section 5, we apply our method to the E-Health example. Section 6 discusses our results and Section 7 concludes the paper.

Related work

Massacci et al. [START_REF] Massacci | An extended ontology for security requirements[END_REF] have investigated the relations between Secure Tropos, Problem Frames and general security concepts e.g. assets. They have proposed a unified ontology to reach a shared understanding of the domain of security requirements, and also take advantage of multiple techniques to model and analyze security requirements. The ontology amalgamates the security ontologies of SI* [START_REF] Massacci | Security requirements engineering: The si* modeling language and the secure tropos methodology[END_REF] and Problem Frames [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF], and accounts for rather nebulous security concepts, such as those of vulnerability and threat. The method differs from our own, because the authors do not investigate how to combine these methods but just explore the relationship between SI* and Problem Frames concepts.

Fabian et al. [START_REF] Fabian | A comparison of security requirements engineering methods[END_REF] propose a conceptual framework for security requirements engineering. The authors also define a common terminology for the framework. The purpose of the framework is to compare security requirements engineering methods. For example, goals are one concept in the framework, and the authors investigate if methods support this concept or not and if the concept is used under a different name. Our method uses the idea of this work that requirements are a refinement of goals and that the SI* method uses a higher abstraction level than Problem Frames. However, the authors do not show a method that actually combines methods.

Liu and Jin [START_REF] Liu | Integrating goals and problem frames in requirements analysis[END_REF] propose relations between SI* and Problem Frames. The authors propose to introduce a domain actor and domain constraints into SI* in order to link SI* and problem frame models. This method differs from our own, because we propose to use the methods in sequence, first SI* than Problem Frames. The authors use both methods at the same time.

Supakkul and Chung [START_REF] Supakkul | Extending problem frames to deal with stakeholder problems: An agent-and goal-oriented approach[END_REF] introduce the concept of a soft-goal from SI* into the Problem Frame method. This method provides support for modeling stakeholder goals in Problem Diagrams. This method differs from our own, because we try to use both methods and not to integrate one into the other. The advantage is that a development is analysed separately on different abstraction layers.

Classen et al. [START_REF] Classen | On the structure of problem variability: From feature diagrams to problem frames[END_REF] propose to integrate feature diagrams and the Problem Frame method. The authors propose to use these methods in sequence. The Problem Frame method is used first for requirements elicitation and analysis. Feature diagrams contain the solutions for the elicited requirements. The authors also do not change the existing methods and integrate problem frames with another existing method. This method can complement our own.

Letier and van Lamsweerde [START_REF] Letier | Deriving operational software specifications from system goals[END_REF] propose a method to construct software specification from high-level goals. The method uses a formal patterns that guide the operationalization. The method differs from our own, because it results in a specification of pieces of the software. Our work results in the specification of the entire architecture.

Background

We introduce the notations we combine in this work in this section. We explain the goal-based notation SI* in Sect. 3.1 and the problem-based notation Problem Frames in Sect. 3.2.

SI*

The SI* modeling language has been proposed to capture security and functional requirements of socio-technical systems. SI* is founded on the concepts of agent, role, goal, task, resource. An agent is an active entity with concrete manifestations and is used to model humans as well as software agents and organizations. A role is the abstract characterization of the behavior of an active entity within some context. They are graphically represented as circles. Assignments of agents to roles are described by the play relation. 3 A goal is a state of affairs whose realization is desired by some actor (objective), can be realized by some (possibly different) actor (capability), or should be authorized by some (possibly different) actor (entitlement). Entitlements, capabilities and objectives of actors are modeled through relations between an actor and a goal: own indicates that an actor has full authority concerning ac-cess and disposition over his entitlement; provide indicates that an actor has the capabilities to achieve the goal; and request indicates that an actor intends to achieve the goal. A task specifies the procedure used to achieve goals. A resource represents a physical or an informational entity without intentionality. A resource can be consumed or produced by a task. In the graphical representation, goals,tasks and resources are respectively represented as ovals, hexagons, and rectangles. Own, provide, and request are represented with edges between an actor and a goal labeled by O, P, and R, respectively. Goals and tasks of the same actor or of different actors are often related to one another in many ways. AND/OR decomposition combines AND and OR refinements of a root goal into subgoals. However, neither such goals might be under the control of the actor nor the actor may have the capabilities to achieve them. Contribution relations are used when the relation between goals is not the consequence of a deliberative planning but rather results from side-effects. The impact can be positive or negative and is graphically represented as edges labeled with + and -, respectively. Finally, tasks are linked to the goals that they intend to achieve using means-end relations. The relations between actors within the system are captured by the notions of delegation and trust. Assignment of responsibilities among actors can be made by execution dependency (when an actor depends on another actor for the achievement of a goal) or permission delegation (when an actor authorizes another actor to achieve the goal). Usually, an actor prefers to appoint actors that are expected to achieve assigned duties and not misuse granted permissions. SI* adopts the notions of trust of execution and trust of permission to model such expectations. In the graphical representation, permission delegations are represented with edges labeled by Dp and execution dependencies with edges labeled by De. Finally, trust of permission relations are represented with edges labeled by Tp and trust of execution relations with edges labeled by Te.

Problem Frames

Problem frames are a means to describe software development problems. They were proposed by Jackson [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF], who describes them as follows: "A problem frame is a kind of pattern. It defines an intuitively identifiable problem class in terms of its context and the characteristics of its domains, interfaces and requirement.". It is described by a frame diagram, which consists of domains, interfaces between them, and a requirement. We describe problem frames using class diagrams extended by stereotypes as proposed by Hatebur and Heisel [START_REF] Hatebur | A UML profile for requirements analysis of dependable software[END_REF]. All elements of a problem frame diagram act as placeholders, which must be instantiated to represent concrete problems. Doing so, one obtains a problem description that belongs to a specific class of problems. 1 shows an example of a problem frame. The class with the stereotype machine represents the thing to be developed (e.g., the software). The classes with some domain stereotypes, e.g., causalDomain or biddableDomain represent problem domains that already exist in the application environment. Jackson distinguishes the domain types causal domains that comply with some physical laws, lexical domains that are data representations, and biddable domains that are usually people. We use the formal meta model [START_REF] Hatebur | A UML profile for requirements analysis of dependable software[END_REF] shown in Fig. 2 to annotate domains with their corresponding stereotype.

Domains are connected by interfaces consisting of shared phenomena. Shared phenomena may be events, operation calls, messages, and the like. They are observable by at least two domains, but controlled by only one domain, as indicated by an exclamation mark. For example, in Fig. 1 the notation O!E4 means that the phenomena in the set E4 are controlled by the domain Operator. These interfaces are represented as associations, and the name of the associations contain the phenomena and the domains controlling the phenomena.

In Fig. 1, the ControlledDomain domain is constrained and the Operator is referred, because the ControlMachine has the role to change the ControlledDomain on behalf of the Operator's commands for achieving the required Commanded Behaviour. These relationships are modeled using dependencies that are annotated with the corresponding stereotypes.

Problem frames support developers in analyzing problems to be solved. They show what domains have to be considered, and what knowledge must be described and reasoned about when analyzing the problem in depth. Other basic problem frames besides the commanded behavior frame shown in Fig. 1 are required behaviour, simple workpieces, information display, and transformation [START_REF] Jackson | Problem Frames. Analyzing and structuring software development problems[END_REF].

Software development with problem frames proceeds as follows: first, the environment in which the machine will operate is represented by a context diagram. Like a frame diagram, a context diagram consists of domains and interfaces. However, a context diagram contains no requirements. Then, the problem is decomposed into subproblems. If ever possible, the decomposition is done in such a way that the subproblems fit to given problem frames. To fit a sub-problem to a problem frame, one must instantiate its frame diagram, i.e., provide instances for its domains, phenomena, and interfaces. The instantiated frame diagram is called a problem diagram.

Since the requirements refer to the environment in which the machine must operate, the next step consists in deriving a specification for the machine (see [START_REF] Jackson | Deriving specifications from requirements: an example[END_REF] for details). The specification describes the machine and is the starting point for its construction.

Problem frames are an appropriate means to analyze not only functional, but also dependability and other quality requirements [START_REF] Hatebur | A foundation for requirements analysis of dependable software[END_REF][START_REF] Alebrahim | A method to derive software architectures from quality requirements[END_REF].

The UML4PF framework provides tool support for this method. A more detailed description can be found in [START_REF] Côté | UML4PF -a tool for problem-oriented requirements analysis[END_REF].

A Method for Goal-and Problem-based Software Engineering

In this section we present our method for combining goal-and problem-based software engineering in Sect. 4.1. The method uses a mapping from the SI* notation to the Problem Frame notation, which is shown in Sect. 4.2. Section 4.3 presents some consistency checks for our method.

Method

We propose the following method that integrates the SI* and the Problem Frames method, depicted in Fig. 3.

1. SI* model instantiation. The aim of this step is to draw an SI* model that captures the system's stakeholders goals. This means identifying the actors and their goals of the system-to-be. The goals are analysed next and all resources or tasks that are a means to to fulfil them are included in the model, as well. It is also possible that one stakeholder requires the resource of another to fulfil his/her goal. In this case, we need to add trust relationships, so that one stakeholder is entrusted with the usage of the resource of another (see Sect. 3). 2. Goal conflict analysis. The second step of our method conducts a conflict analysis on the SI* models and resolves these conflicts. We analyse the impacts one goal has on another. This shall also stimulate a discussion between the customer and the requirements that helps understanding the system-to-be better and validates the instantiated SI*. This validation is based on the knowledge of the customer and is not to be confused with the validation executed by the requirements engineer alone, which is described in Sect. 4. We check the set of domains resulting from the mapping and resting phenomena. We include domains and phenomena if these are missing. We complete the context diagram if the entire environment of the machine has been considered and added to the context diagram. 6. Requirements refinement. We consider the requirements specified earlier from the goals in the SI* models and refine these into requirements related to the context diagram. These requirements refer to the domains and phenomena in the context diagram. While on the abstraction level of the requirements derived from goals, we might state that a some data should be kept confidential. The same statement would have to be refined. For example, the data has to be kept confidential within a certain database, represented as a causal domain. We have to refine each requirement and check carefully if further requirements need to be added. This can be the case, because the context diagram might contain elements and relations that were not present in the SI* models. 7. Create problem diagrams. We create at least one problem diagram for each requirement defined in the previous step. The problem diagrams contain all elements the requirements refer to from the context diagram. It is also possible to add fur- ther domains to the problems diagrams. We consider the set of resulting domains from the mapping of SI* elements to elements from the problem frame notation. At the completion of this step we check if all problem frame elements from the mapping have been used at least one problem diagram. If this is not the case we might have missed an problem diagram and a requirement. We have to correct this by include further requirements and problem diagrams for the missing problem frame elements. 8. Problem-based conflict analysis. This step focuses on a conflict analysis based upon the problem frame models. The aim of this analysis is to detect and resolve problems that can be identified on the abstraction level of problem frames. This includes technical analysis considering the differences between domains and phenomena. For example, if a phenomenon is directed in only one direction we have to ask ourselves if we really do not want a phenomenon in the other direction. We also have to consider if connections between domains are missing or if problem diagrams contradict each other. For example, if two problem diagrams add further domains and these are not compatible to one another. 9. Create architecture. The last step of our method is the creation of software architectures in UML from the problem frames as explained in [START_REF] Choppy | Systematic architectural design based on problem patterns[END_REF].

Mapping

We present the rules to map SI* elements to Problem Frames elements in Tab.

Consistency

We propose several consistency checks for our method:

-The backtracking from a problem frame diagram to a requirement to the goal has to be possible Fig. 4: SI* instantiation of the EHR scenario

•

Application of our Method

Application scenario To illustrate our method for combining goal-and problem-based requirements engineering methods, we use a scenario taken from the health care domain provided by the industrial partners of the EU project NESSoS4 . It concerns the management of electronic healthcare records. The scenario focuses on providing medical services to patients, reading and updating their healthcare record and providing the results of examinations and treatment to authorized externals entities.

1. Instantiate SI* Models Fig. 4 shows the SI* model for the management of electronic health records (EHRs). Figure 4 shows a fragment of the SI* model in Fig. 4 where a conflict occurs between the main goal of the Patient and Pharmacy. The conflict arises between the main goal of Patient, Privacy of EHR and the Pharmacy goal Disclose Prescription History (wrapped by red rectangles). The Patient has delegated the execution of the goal Privacy of EHR to the Hospital. The fulfillment of the goal Privacy of EHR is negatively affected by the goal Disclose EHR which is decomposed in the sub-goals Disclose Personal Data, Disclose Medical History and Disclose Medical History. The Hospital has not delegated to the Pharmacy the permission of Disclose Prescription History but just the permission of accessing Prescription History. The Pharmacy, instead, grants access on Prescription History to Credit Reporting Agency. Thus, the Pharmacy goal Disclose Prescription History is in conflict with the goal Privacy of EHR of the Patient. The information about which goals have a negative impact on each other is domain knowledge. This cannot be derived automatically and has to be an input to the model. However, the detection of these goal conflicts is not possible in the Problem Frame notation, because stakeholder goals are not part of the notation. Thus, we can only detect these goal conflicts when using SI* (or another goal-based notation). We resolve the conflict by removing the goal Provide Prescription History to the Pharmacy.

Derive Requirements from Goals

We refined the goals from the SI* models into requirements. The goals depicted in Fig. 4 are marked in bold in the following requirements:

RQ1 Provide the means for the doctor to Diagnose patients RQ4 Provide access to monitoring data for researchers, so that the researcher can Find new Treatments RQ5 Provide means to enable doctors to Asses Treatment plans of other doctors 4. Map SI* to Problem Frame Elements We provide a mapping of the SI* elements to the PF elements in Tab. 2.

Create Context Diagram

In Fig. 5 we present a context diagram of the electronic health system (EHS), the machine to be built. The EHS has connections to the lexical domains EHR, the Privacy Policies of the system, and the System Logs. The Privacy Policies state the privacy preferences of each patient, e.g., to which doctors the patient has given a consent to use her EHR. The EHS is connected to the Patient using the Browser Patient, a Mobile Device, which is further connected to Sensors that are in turn attached to the Patient. A Monitor or the Browser Care Providers connects the machine to the health care professionals, in our example Doctors. The EHS machine offers no functionality to the pharmacy directly. Thus, we do not require a domain for it in the context diagram. The functionality is actually provided to the Pharmacist.

Pharmacist

Biddable Domain Pharmacist is introduced, because these group of actors use the EHS machine.

Credit Reporting Agency

The EHS machine offers no functionality to the credit reporting agency. Thus, we do not require a domain for it in the context diagram. The prescription information is forwarded from Pharmacists with other means.

Health Insurance Company

The EHS machine offers no functionality to the health insurance company. Thus, we do not require a domain for it in the context diagram. Tasks MonitorVitalSigns A sequence of phenomena where the machine records the vital signs of the patient: P!VitalSigns and the according sequence of phenomena to the machine: S!VitalSigns, MD!CreateEHR ProcessMonitoring-Data

The processing of the data is machine internal, but for processing the data has to be read first: EHS!RequestEHR Notify about Treatment A phenomenon that informs the nurse or doctor about a treatment to be applied and the corresponding sequence of phenomena: EHS!sendEHR, M!sendEHR Record Appliance A sequence of phenomena that sends an EHR with the treatment entry from the nurse / doctor to the machine: N!sendEHR, D!sendEHR, BCP!sendEHR Check Health Data A phenomenon that enables the doctor to request an EHR: D!requestEHR, BCP!requestEHR Write Prescription A phenomenon that enables the doctor to write an prescription: D!send, BCP!sendEHR Provide Prescription A phenomenon that enables the pharmacist to write an prescription: P!provideDescription, BP!providePrescription,E!sendPrescription Collect Prescription A sequence of phenomena that enables the pharmacist to collect a prescription: The Researcher uses the Browser Researcher to access the Research Database Application, which is in turn connected to the EHS. The hospital from the SI* diagram is not mapped to in the context diagram, because it has no direct connection to the machine. The reason is that the hospital delegates all goals to other actors. Hence, a direct connection to the machine is not necessary. The Problem Frame method demands that the connections between domains and the machine are made explicit. Hence, our model got enriched by several connection and causal domains, e.g., Browser Researcher. These are not present in the SI* models.

P!

Refine Requirements

We identified 19 preliminary functional requirements for the EHS, which were refined into 34 functional requirements and corresponding problem diagrams. For reasons of space, we focus on the following refined requirements for the remainder of the paper: The release of medical information to researches described in RQ4.2 and depicted in the problem diagram in Fig. 7. Researchers can use the Browser Researcher to request medical data from the Research Database Application. This application requests the data in turn from the ReleaseMedicalDataMachine, which releases it the Research Database Application. The application sends the information to the browser, where it is shown to the Researchers.

RQ1.1
The remaining problem diagrams are drawn in a similar manner.

Problem-based conflict analysis

We proposed a pattern-based method for identifying laws [START_REF] Beckers | A patternbased method for identifying and analyzing laws[END_REF] based upon software requirements specification. Using this method for our case study gives the result that data protection law, among others, is relevant. For example, the the German data protection act (BDSG). This law demands a detailed privacy analysis of a system. In earlier works we proposed the ProPAn method [START_REF] Beckers | A problem-based approach for computer aided privacy threat identification[END_REF] for computeraided privacy threat analysis. The method is based upon the problem frame method and results in a set of requirements that have a privacy conflict. In our case study the results are that RQ4 has a conflict with other requirements, because the Researchers gain access to personal information of the Patients without an informed consent. We resolve this issue by anonymising the data transferred to the researchers. The ProPAn method only uses the problem frame approach and relies upon an analysis of the domains and their connections. Hence, the complete modelling of the machine and all the domains in the environment allows to trace personal information through the system. This complete tracing is difficult to achieved with SI*, because the system is only modelled in relevant artifacts. Hence, it might be possible to detect a privacy violation, if a related goal is modelled. To describe a tracing, however, is rather difficult to master in SI*, because the system is only partially modelled.

After changing the problem diagram of RQ4, we have to execute consistency checks on the other problem frame models and the SI* models. This also results in a Feedback loop to the goal model and we have to update the goal model accordingly. This results in the model shown in Fig. 8. In this model, we added goal the protect personal data of the new established actor Legislator (red part with the lightning). The Hospital has to comply to this law. Hence, we have to include the information that the data in the EHR have to be anonymised, before sending to the Researchers (green part with the exclamation mark). 9. Create Architecture from Problem Diagrams For space reasons, we refer to the works of Choppy et al. [START_REF] Choppy | Systematic architectural design based on problem patterns[END_REF] for creating software architectures from problem diagrams.

Discussion

The integration of a goal-based and a problem-based requirements engineering method can be achieved either by integrating the concepts of a goal-based method into a problem based (and vice versa) or by creating relations between a goal-based and a problem-Fig. 7: Problem Diagram for Requirement RQ4.2 based method. We did experiments with the integration of goals and more explicit stakeholder views into the Problem Frame approach. However, the results were difficult to process, because we discovered that the goals are on a higher abstraction level the Problem Frame method. For example, creating a goal domain and instantiating it with the goal Earn Money is feasible. However, each domain in the Problem Frame approach has to have relations to other domains, and phenomena towards other domains or the machine. We could not come up with meaningful phenomena between goals and Problem Frame domains. Moreover, the investigation of goal conflicts is very difficult, when the relations between stakeholder goals are expressed in phenomena. Hence we abandoned the approach of integrating concepts.

Nevertheless, we agree that a intensive analysis of stakeholder goals is valuable for every software development problem. Thus, we decided to work on relations between the two requirements engineering methods. This has the drawback that two time consuming methods have to be executed. However, we recognized that it is important to analysis conflicts on different levels of abstractions. Goal-based methods have the advantage of only considering the technical aspects of the software if they have a direct relation to a stakeholder goal. In addition, goal-based methods only consider the specific parts of a software that has this relation. The problem-oriented world works on a lower abstraction level and tries to describe a complete context of the machine. This has the advantage of being able to derive software architectures from this context description.

Conclusions

In this paper we have presented a method to integrate goal-and problem-based requirements engineering methods. We presented a particular method for the integration of the SI* and Problem Frames methods. This method provides the ability for software engineers to analyze and resolve goal conflicts among stakeholders on a high abstraction level and to transfer the resulting goal models to problem models that focus on the particular software design problem. In the future, we will use or method for further goal-based methods, e.g., KAOS [START_REF] Van Lamsweerde | Requirements Engineering: From System Goals to UML Models to Software Specifications[END_REF]. We will also look into the integration of security-and risk-based requirements engineering methods, e.g., CORAS [START_REF] Mass | Model-Driven Risk Analysis: The CORAS Approach[END_REF]. We will also investigate the applicability of graph model transformation techniques to semi-automate some steps of our method like the mapping from SI* to Problem Frames elements.

Fig. 1 :Fig. 2 :

 12 Fig. 1: Commanded Behaviour problem frame

3 . 5 .

 35 Create context diagram. We use the mapping of the previous step to create our fist diagram using the problem frame notation. This diagram is our context diagram (see Sect. 3), which describes the context of the development problem. While the SI* models model the actors and their goals, and resources were shown only if they can fulfil a goal. Problem frames is based on the machine to be build. Hence, we have to create the machine domain first and check if it already exist in the set of domains resulting from the mapping in the previous step. If not we have to add it to the context diagram. Next, we add the domains, which whom the machine domain has a relation and exchanges phenomena.

  And Machine!Task between Machine and Domain representing Resource has to be added. To map the delegation of execution relation we use different rules according to the type of the Dependum. If the Dependum is a Goal, the Domain representing the Dependee Actor in the delegation of execution relation is constrained by the Requirement which is a refinement of Dependum Goal. If the Dependum is a Task or a Goal, the delegation of execution dependency is mapped to two Phenomenon under the control of the Biddable Domain representing the Dependee Actor. Furthermore, the delegation of permission relation having as Dependum a Resource is mapped to two Phenomenon under the control of the Biddable Domain representing the actors Depender and the Dependee because both of them have access to the Lexical Domain representing the Resource.

  The actors, which have provided a relation to a goal, have to appear in the problem diagram. • If a resource has a means-end relation to a goal, the resource has to appear in the problem diagram. • If a task has a means-end relation to a goal, at least one phenomenon related to that task has to be in the problem diagram -If changes are made in the goal model these have to be also applied to the problem frame model Legend: Circles represent roles (e.g Patient), ovals denote goals (e.g Provide Medical Services), exagons model tasks (e.g Write Prescription), while rectangles model resources (e.g EHR).

7 .

 7 Create Problem Diagrams The problem diagram for RQ1.1 describes creating and storing of EHRs (depicted in Fig. 6). The Patient is connected to a Sensor that reports the Patient's vital signs to the EHR Create & Store Machine using a Mobile Device. The machine stores the EHR. In addition, the Patient can use the Browser Patient to create an EHR. Doctors and Nurses can use the Browser Care Providers to command the machine to create EHRs.

Fig. 5 :Fig. 6 :

 56 Fig. 5: Context Diagram

Fig. 8 :

 8 Fig. 8: Patient Monitoring -An example of a revised goal model due to an requirements conflict

  Fig.3: A method for the integration of SI* and Problem Frames in Sect.[START_REF] Beckers | A patternbased method for identifying and analyzing laws[END_REF]. It results in an evolved SI* models, which contain the information how goals relate to one another. 3. Derive requirements from goals. The third step demands to write down requirements, which are based upon the goals in the SI* models. We analyse each goal of every stakeholder and formulate a text that consider all the information in the SI* models relevant for that particular goal. For example, we should name the stakeholder the goal belongs to in the text, the resources and tasks required to fulfil it and further relations to other stakeholders, e.g., trust relations. 4. Mapping SI* to Problem Frames. This step consists of the mapping of the elements in the SI* models to elements of the problem frame notations. We use Tab. 1 to guide the mapping. The table will be explained in the following subsection. The table states what elements of problems to consider, when mapping an SI* element. This requires in several cases decision by a human expert, because the table does not present a one to one mapping, but offers choices of problem frame notation for most of the SI* elements. It is critical for the requirements engineer to understand the meaning behind every instantiated SI* element in order to execute the mapping.

	external	input	SI* notation			SI* to PF Table Mapping	Problem notation Frame		Problem notation Frame		UML notation
	method	1. Instantiate SI* models	2. Goal-based conflict analysis	3. Derive Requirements from goals	4. Map SI* to Problem Frame Elements	5. Create Context Diagram	6. Refine Requirements	7. Create Problem Diagrams	8. Problem-based conflict analysis	9. Create architecture from problem diagrams
	input/output	SI* models	SI* models	textual Requirements		Context Diagram	textual Requirements	Problem Diagrams	Problem Diagrams	UML architecture models

The first question, has a goal any impact on another. If this is the case, we have to analyse if one goal contributes to fulfil another or if it is an obstacle for fulfilling it. The resulting relation is included into the SI* model as described

Table 1 :

 1 Mapping of Concepts from SI* models to Problem Frames Actor!Task shared between Actor Biddable Domain and Machine of the problem diagram of the related Requirement. Machine!Task between Machine and the Lexical or Causal Domain representing the Resource. If Dependum is a Goal the Biddable Domain Dependee is constrainted by the Requirement which refines Goal If Dependum is a Task Dependee!Task If Dependum is a Resource Dependee!Resource Dp(Depender, Dependee, Dependum) Depender!grantResource, Dependee!accessResource

	SI* Element	PF Element
	Role or Actor	Biddable Domain or Causal Domain
	Goal	textual Requirement
	Task	basis for at least one Phenomenon
	Resource	Lexical Domain or Causal Domain
	Means end(Goal, Task)	Actor!Task shared between Machine and Actor Biddable
		Domain
	Means end(Goal, Resource)	Resource Lexical Domain constrained by Requirement
		which refines Goal
	Means end(Task, Resource)
	De(Depender, Dependee, Dependum)

  1. Note that not all concepts and relations of SI* can be mapped to Problem Frames elements. We map a role or agent either to a biddable domain or to a causal domain. Roles or Agents map to a Biddable Domain if they represent human actors. If they represent entire businesses, hardware or even software, they are mapped to Causal Domains.There is no representation of Goals in the Problem Frames notation. Requirements are means to fulfil goals[START_REF] Fabian | A comparison of security requirements engineering methods[END_REF] and are represented as text in the Problem Frame method, as well as graphical element in problem diagrams. Tasks in the SI* notation give rise to Phenomenon in the Problem Frames notation. The Phenomenon mapped to the Task will be under the control of the Biddable Domain, which has been mapped to the Actor providing the Task. A Resource in SI* is mapped to a Lexical Domain if it is just data. In the case it is hardware, software or any other mean with well defined behavior it is mapped to a Causal Domain.Different mapping rules are applied to translate the relation means end into Problem Frames elements based on the type of services (goal, task, resource) that are linked. If means end is a relation between a Goal and a Task which is provided by an Actor, Task will be mapped to a Phenomenon under the control of the Biddable Domain representing Actor. The phenomenon belongs to the interface between the machine Machine and Actor. In addition, Actor is referred by the Requirement which refines the goal Goal. If means end is a relation between a Goal and a Resource, Resource will be mapped to a Lexical Domain which is constrained by the Requirement that refines Goal. If means end is a relation between a Task and a Resource, Resource is mapped to a lexical or causal domain. Additionally, there has to be Actor!Task between Biddable Domain Actor that represents the actor providing Task and the Machine.

  The goal Check Consent positively contributes to the achievement of the goal Privacy of EHR, while the goal Disclose EHR negatively affects the fulfillement of the goal. To satisfy the goal Diagnose the Hospital depends on the Doctor. The Diagnose goal is achieved by the tasks Check EHR and Write Prescription. The task Check EHR requires the resource EHR to be accomplished and thus the Hospital delegates to the Doctor both the permission of accessing EHR and of Disclose EHR. The Pharmacy is responsible for Sell Drugs to patients. The goal Sell Drugs consists of Provide Drugs to be delivered according to the Prescription received from the Patient and Manage Prescriptions. The goal Manage Prescriptions requires to Collect Prescription and Provide Prescription History. This goals requires to Check Consent and Disclose Prescription History. The Credit Reporting Agency wants to Sell Medical Adherence Score that indicates how well patients handle drug prescriptions. To this end, Credit Reporting Agency Buy Prescription History to Calculate Score and Disclose Score to third parties like Health Insurance Companies. Health Insurance Company Purchase the Medical Adherence Score to calculate the Health Insurance Premium. Finally, the information in the EHR is used by the Researcher to Find new Treatments.

The model consists of seven actors: Patient, Hospital, Doctor, Pharmacy, Credit Reporting Agency, Health Insurance Company and Researcher. The Patient owns the resource Electronic Health Care Record (EHR) which consists of Medical History, Prescription History, and Personal Data. The Patient wants Privacy of EHR and Provide Medical Services to be guarantee and depends on the Hospital for these goals to be achieved. To achieve the goal Provide Medical Services, Hospital needs to Manage EHR and the Diagnose the Patient. The goal Manage EHR is decomposed in the subgoals Provide EHR and Collect EHR. Provide EHR is further decomposed into subgoals Check Consent and Disclose EHR.

Table 2 :

 2 Mapping of SI* elements to PF elements Patient, because it represents a group of human actors Hospital The EHS machine offers no functionality to the hospital directly. Thus, we do not require a domain for it in the context diagram. The functionality is actually provided to the Doctor. Doctor Biddable Domain Doctor, because it represents a group of human actors Researcher Biddable Domain Researcher, because represents a group of human actors Pharmacy

	SI* Element	PF Element
	Actors
	Patient	Biddable Domain

  collectPrescription, BP!collectPrescription,EHS!collectPrescription, E!sendPrescription,EHS!sendPrescription,BP!sendPrescription Resource Mobile Device Causal Domain Mobile Device, because it is a device containing hard-and software. It is also a Connection Domain Mobile Device, because it connects the sensor and the EHS.

	MonitoringData	Lexical Domain Monitoring Data, because it is data without a physical device.
	Sensor	Causal Domain Sensor, because it is a device containing hard-and software.
	Electronic Health	Lexical Domain EHR, because it is data without a physical device.
	Record (EHR)
	Prescription	Lexical Domain EHR, because it is data without a physical device.

  Store EHR, which is created by care providers. RQ1.2 Display EHR to care providers as needed RQ1.3 Store and process vital signs of patients in EHR for care providers RQ4 Provide access to monitoring data for researchers, so that the researcher can find new treatments RQ4.1 Provide a functionality to request medical data for Researchers RQ4.2 Release medical data to Researchers

<<contextDiagram>> Electronic Health System <<biddableDomain>> Patient

	<<lexicalDomain>>	MD!{CreateEHR}	<<causalDomain,connectionDomain>>	S!{VitalSigns}	<<causalDomain,connectionDomain>>
		EHR			Mobile Device	Sensor
	<<lexicalDomain>> Monitoring Data	EHS!{CreateEHR, storeEHR, <<machine>> requestEHR, providePrescription, collectPrescription}, E!{sendEHR, sendPrescription},	<<causalDomain,connectionDomain>> Browser Patient <<displayDomain>> Monitor BCP!{requestEHR}, BP!{CreateEHR} M!{requestEHR}, EHS!{sendEHR} EHS!{sendEHR}	P!{CreateEHR, requestEHR} M!{ sen dE HR }	P!{VitalSigns}
		EHS	<<causalDomain,connectionDomain>>	<<biddableDomain>>
		RDA!{requestMedicalData},		Browser Care Provider	D!{createEHR,r equestEHR}, BCP!{sendEHR }	Doctor
	<<lexicalDomain>> Prescription	<<causalDomain,connectionDomain>> Research Database Application EHS!{sendMedicalData}	<<causalDomain,connectionDomain>> R!{requestMedicalData}, BR!{requestMedicalData}, BR!{sendMedicalData} RDA!{sendMedicalData}	<<biddableDomain>> Researcher
					Browser Researcher
		BP!{providePrescription,collectPrescription},
		EHS!{sendPrescription}		P!{providePrescription,collectPrescription},
		<<causalDomain,connectionDomain>>		BP!{sendPrescription}	<<biddableDomain>>
		Browser Pharmacy			Pharmacist

For the sake of simplicity, in the remainder of the paper we use the term actor to indicate agents and roles when it is not necessary to distinguish them.

http://www.nessos-project.eu/

partially supported by the EU project Network of Excellence on Engineering Secure Future Internet Software Services and Systems (NESSoS, ICT-2009.1.4 Trustworthy ICT, Grant No. 256980).


Simon Himmel
email: himmel@comm.rwth-aachen.de

Martina Ziefle
email: ziefle@comm.rwth-aachen.de

Chantal Lidynia
email: lidynia@comm.rwth-aachen.de

Andreas Holzinger
email: andreas.holzinger@medunigraz.at

Older Users' Wish List for Technology Attributes

Keywords: User diversity, technology acceptance, age, gender, purchase and usage criteria, household -, medical technologies, ICT, user expectations

de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

During the last decades, human-computer interaction research has made significant gains in understanding technology acceptance of information and communication technology (ICT) and the requirements that need to be considered for a user-centered technology development. Since the pioneering in technology acceptance 25 years ago [START_REF] Davis | Perceived usefulness, perceived ease of use, and user acceptance of information technology[END_REF], a huge number of studies corroborated the enormous impact of ease of using a system and its perceived usefulness on the acceptance of a technology (e.g., [START_REF] Arning | Different perspectives on technology acceptance: The role of technology type and age[END_REF], [START_REF] Wilkowska | Which Factors Form Older Adults' Acceptance of Mobile Information and Communication Technologies?[END_REF]). Nevertheless, the knowledge about specific determinants of technology acceptance and the impact of situational aspects of usage contexts is still limited [START_REF] Wilkowska | User diversity as a challenge for the integration of medical technology into future home environments. Human-Centred Design of eHealth Technologies[END_REF]. This is based on the fact that nowadays technology has to cope with much more complex using situations compared to the situation of technology usage in former times [START_REF] Rogers | The Changing Face of Human-Computer Interaction in the Age of Ubiquitous Computing[END_REF]. A first factor in this context is the user diversity with an ever increasing number of seniors that are confronted with a broad range of technology and urged to understand, learn, and use it [START_REF] Mitzner | Older adults talk technology: Technology usage and attitudes[END_REF]- [START_REF] Kleinberger | Ambient intelligence in assisted living: enable elderly people to handle future interfaces[END_REF]. The second impact is the ongoing diffusion of technical devices. Technology and electronic services are deeply integrated into daily life, thereby raising novel requirements as well as concerns regarding privacy, security, and control [START_REF] Wilkowska | Privacy and data security in E-health: Requirements from the user's perspective[END_REF]. A third factor addresses the different types of technology in different using contexts. One and the same technology, once used in a medical context and once use for daily support, may require completely different using profiles which have not been considered sufficiently within technology acceptance research [START_REF] Ziefle | How Usage Context Shapes Evaluation and Adoption in Different Technologies[END_REF], [START_REF] Falaleeva | Influence of individual psychological traits on attribution toward computing technology[END_REF].

For the development of well-accepted future technologies, we need to integrate the users and find out which factors they perceive as relevant for the broad acceptance of different technologies. Technology type, context of use, and age are crucial determinants and highly relevant for the extent of acceptance and the willingness of older people to actually use technology [START_REF] Brown | Product development: Past research, present findings, and future directions[END_REF], [START_REF] Nagamachi | Kansei Engineering: A new ergonomic consumer-oriented technology for product development[END_REF].

Questions addressed

As users' demands and concerns were neglected within product development for a long time, a considerable knowledge gap exists regarding the needs and requirements of users and their expectations for a useful and functionally sufficient technology. In an exploratory approach, we contrast technologies in different contexts of use, specifically household and medical technologies. Both technology types are very frequently used by older adults, a key target group of modern technology. The questions guiding this research were the following:

(1) What are the users' demands for household and medical technologies?

(2) How do demands for household and medical technologies differ from each other?

(3) How do the demands vary for different users (gender, age, health status)?

In order to learn about the impact of user diversity, participants of both genders and of a wide age range (19-74 years) were examined.

Methodology

The present study was designed to get a deeper understanding of older adults' requirements and expectations of desired functionalities in different technology domains, contrasting household and medical technologies. One of the basic principles of empirically assessing the willingness of technology adoption is the fact that the method used has an effect on the outcome, especially in a participant group that is not used to take part in empirical studies (as older adults are) and therefore might be highly receptive to expectations of what seems appropriate in the respective setting.

In order to truly understand older adults' wishes, expectations, and requirements in the different technology domains, we opted for a mix of qualitative and quantitative methodologies. Therefore, we compiled a questionnaire that consisted of both an explorative qualitative part in which participants could freely state their opinions (Part I) and a quantitative part (Part II) in which different aspects had to be evaluated on predefined scales.

Empirical research procedure

In the beginning of the empirical process, demographic data was gathered. Gender, age, and self reported health-status were the independent research variables as they are widely known to be key factors regarding technology adoption and willingness to use technology [START_REF] Wilkowska | Which Factors Form Older Adults' Acceptance of Mobile Information and Communication Technologies?[END_REF], [START_REF] Wilkowska | User diversity as a challenge for the integration of medical technology into future home environments. Human-Centred Design of eHealth Technologies[END_REF], [START_REF] Rogers | The Changing Face of Human-Computer Interaction in the Age of Ubiquitous Computing[END_REF]. Regarding the assessment of their health condition, participants could assign themselves to either a "healthy condition" category or a "not healthy condition" category in case of suffering from chronic disease(s).

Then the qualitative part started (Part I). Participants were given the opportunity to freely state attributes they would require of household and medical technologies respectively. Nine attributes could be given at the most. This qualitative approach was realized in an open format by asking for the users' wish list: What attributes should household and medical technologies respectively possess? For both technology types, we operationalized medical and household technologies, giving typical examples from daily experience (e.g. blood pressure meter (medical technology), washing machine (household technology).

Then the quantitative part began (Part II), using the questionnaire, which requested participants to allocate 18 statements either to medical or to household technologies.

For both research parts the dependent variables were the number and nature of attributes ascribed to household vs. medical technologies.

Participants

In order to study "age" as determining factor for the design of technologies, we examined a wide age range. 36 participants, aged between 19-74 (M=36, SD=18,07), took part in this study. 13 participants were female (36%), 23 male (64%). The sample was split into four age groups (Table 1). 7 participants had at least one chronic disease (19% ill, 81% healthy). Participants were recruited through advertisements in a local newspaper and announcements in public places. Participants were not compensated but volunteered to take part, highly motivated by the fact that they were asked as experts for the design engineering of technology in socially and societally important technology fields.

Results

As the present study was mostly exploratory in nature and aimed at uncovering desired functionalities and attributes of technology in different domains, we did not use inference statistical analysis but report the data descriptively (frequency data in %, M = means, SD = standard deviations).

Part I: Desired attributes of household and medical technologies

In order to evaluate the qualitative data from the wish list for household and medical technology, the stated attributes were categorized. The categories were based on related research [START_REF] Mitzner | Older adults talk technology: Technology usage and attitudes[END_REF], [START_REF] Wilkowska | User diversity as a challenge for the integration of medical technology into future home environments. Human-Centred Design of eHealth Technologies[END_REF] and adjusted in the course of the analysis. The number of attributes mentioned by category can be seen in Table 2. As can be seen in Table 2, more answers were given for household technologies, showing that the participants' mental model of attributes of household technologies is more differentiated than that of medical technologies. Figure 1 depicts the percentage of attributes in the different categories. As can be seen in Figure 1, desired attributes for the different technology domains differ not only with respect to the mere number of mentioned functionalities. The attribute patterns differed also qualitatively and revealed how very different the wanted attributes are between the two technologies. "Reliability," for instance, was found to be the key category for medical technologies outdoing all other attributes. Conversely, "functions and usability," obviously less important in case of medical technology, plays the key role in household technologies. Interestingly though, not all attributes depend on the type of technology. "Flexibility and mobility" are similarly wanted in medical and household technologies as the second most important category.

Gender effect. In this analysis, gender effects are focused on, based on the question if female and male users require different attributes within the different technology domains. In Figure 2, the requirements for household technologies are depicted. When looking at household technologies (Figure 2), it is apparent that women attach higher importance to "functions and usability," to "flexibility and mobility" as well as to "facilitation of every day life." Men, in contrast, value "reliability," "price," and "design." Neither gender reported "documentation" requirements, thereby suggesting household technologies are easy to use and learn, without the use of specific documentation.

In Figure 3, findings of gender-related requirements regarding medical technologies are illustrated. Again, there are considerable gender differences.

The most obvious difference regards the reliability requirement that is more than twice as important for men as it is for women. For women, again "functions and usability," "flexibility and mobility" but also "unobtrusive design" and "facilitation of everyday life" are important key features in the medical technology domain.

Two other findings seem noteworthy in this context. In contrast to household technology, the price is less important in the medical technology domain (more important to men, though) and "documentation" is needed for medical technology devices (more important to women). Age effect. When looking for age differences, we see a rather inhomogeneous picture for household technologies (Figure 4). For the oldest group, "functionality and usability," "facilitation of everyday life," and "reliability" were the most important features. Across all ages, "functionality and usability," "facilitation of everyday life," and "price" seem to be the most important categories for household technologies. Are age effects also decisive for medical technologies? Figure 5 shows that the requirements are affected to a lesser extent by age. For all age groups, "reliability" of medical technology is the most important feature. "Flexibility" is mentioned as important for all groups except the oldest (over 60 years of age), which did not attach importance to this criterion at all. "Functions and usability" was not as relevant for the oldest group, in contrast to attributes like "unobtrusiveness" and "facilitation of everyday life," which were found to be crucial characteristics for medical technology in the oldest group.

Effects of health status.

A final analysis considers the health status of participants. One might expect that the health status should have no effect on the key requirements in household technologies (Figure 6), yet that in medical technologies (Figure 7) healthy persons should have less requirements compared to ill persons, and "reliability," "flexibility and mobility" but also "usability" should be the key attributes. Household technologies are considered first (Figure 6). As expected, chronically ill and healthy persons assess the same attributes as (un)important. The most important feature is the usability requirement, independent of the health status. Among the unimportant attributes are "design" and "documentation." When looking at the requirements of medical technology, considerable differences emerged between the attributes reported by healthy and ill persons (Figure 7). For chronically ill persons, "reliability," "unobtrusiveness," "usability," and "facilitation of everyday life" are most important. While most of the desired functions are easily comprehensible, the requirement for "unobtrusiveness" by ill persons seems to be especially noteworthy. It shows that the stigmatization of illness is a sensitive aspect for people and might be compensated by unobtrusive designs. For healthy persons, interesting findings were revealed as well. It is worth mentioning that healthy people attach higher importance to reliability than ill persons do. This finding is contra-intuitive at first sight. Though, possibly, reliability might be less important to ill This assumption is corroborated by the higher need for documentation in healthy persons, again referable to their higher insecurity when dealing with disease-related information.

0%
0% 20% 40% 60% 80%
Summarizing the findings so far, we can conclude that users perceive different requirements for technologies in different domains. In addition, the key requirements are also modulated by user diversity. Gender, age, and health status are sensitive factors that need to be considered quite early in the design process of a technology.

Part 2: Allocated statements to household and medical technologies

After the qualitative approach, we presented 18 different statements and asked participants to allocate the statements to either medical or household technology.

The selection of the statements was based on interviews carried out prior to this study [START_REF] Tsipi Heart | Older adults: Are they ready to adopt health-related ICT? International journal of medical informatics[END_REF], [START_REF] Kleinberger | Ambient intelligence in assisted living: enable elderly people to handle future interfaces[END_REF], [START_REF] Wilkowska | Privacy and data security in E-health: Requirements from the user's perspective[END_REF]. The statements represent alternative endings of the sentence "I would use the technology, if," depicting conditional acceptance using motives (Figure 8). It can be seen that there are completely opposing requirement profiles for both technology domains. The curves for medical technology and for household technology cross in one main aspect: the ease of learning the system, followed by a high durability, and a silent mode while using the technology. When defining the pro-using profile of medical technology, "unobtrusiveness of technical design," "the latest state of technology," "having no alternatives to using it," "trust," and "reliability" are key. The very same arguments are the least important features for household technologies. For the latter, the pro-using profile is characterized by "attractive design," "fun to use," "technology facilitates life," and providing many "different functions." No age, gender, or health effects were revealed, showing that user diversity is indistinctive in the perception of household technologies.

Discussion

In this paper we focused on users' wish list regarding attributes of different technology types: household and medical technologies. On the one hand, we identified generic attributes, which should be present in both technologies and independent of user diversity: Here, adequate functionality and high usability are key attributes, but the extent to which technology facilitates everyday life is also important. Furthermore, independent of the participants' age, gender, and health status, there are also some generic attributes that seem to have no importance at all (at least they were not mentioned on the respective wish lists). As such, documentation and instruction come to the fore, which is quite astonishing considering the mostly suboptimal design of many technical devices' manuals. Regarding medical technology, reliability and usability are crucial for all users, which was expected, confirming previous research outcomes in the medical technology context [START_REF] Ziefle | When your living space knows what you do: acceptance of medical home monitoring by different technologies[END_REF], [START_REF] Ziefle | Technology acceptability for medical assistance[END_REF]. It is an insightful finding, though, that unobtrusiveness is a critical attribute of medical technology, especially for older and chronically ill persons. One could have expected that unobtrusiveness of technology might be less important for a group that is quite dependent on technology. Apparently, this is not the case and represents the typical designers' error: ignorance towards the customers' experience. As older and ill participants noted, the stigmatization of being old and ill is very negatively biased in our society and therefore unobtrusiveness is indispensable for people using the technology. Regarding the methodology, the mix of qualitative and quantitative procedures revealed a rich field of insights and allowed us to screen user diversity and technology contexts in a very sensible way. The task of providing a "wish list" for different technology types that are very familiar to the participants pleased them. In addition, participants were highly motivated to work on technology design principles and were very willing to contribute their knowledge. They appreciated being integrated into technology development as key users, especially as this opposes the traditional designers' approach of first producing a technology and later realizing said technology designs might have severe usability barriers or are outright rejected by the (intended) target group.

A final remark is directed to the older persons as an important future user group. In contrast to the usual procedure in which younger technical designers develop technology for older users by just imagining what could be useful or necessary for senior persons. We should be aware that this procedure is naïve if not ignorant. Aging is complex and quite differential [START_REF] Ziefle | Technical Expertise and its Influence on the Acceptance of Future Medical Technologies. What is influencing what to which extent[END_REF], [17|. Not all users age in the same way and the requirements, the needs and whishes towards a well-accepted technology might be individual. In addition, designers should be aware of the fact that aging and technology generation should be distinguished. Even though the age-related decrease of sensory and motor abilities might be comparable over times, the acceptance for and the requirement towards humane technology might be different in the different generations, reflecting upbringing aspects, mental model of how technology works and different societal needs [START_REF] Ziefle | New challenges in Human Computer Interaction: Strategic Directions and Interdisciplinary Trends[END_REF]. Thus, including users into early stages of technology developments is indispensable in order to reach broad acceptance of technology [START_REF] Ziefle | Modelling mobile devices for the elderly[END_REF], [START_REF] Arning | Ask and you will receive: Training older adults to use a PDA in an active learning environment[END_REF].

5

Limitations and future research duties

Finally, there are some limitations that will have to be addressed in future work. One is the comparatively small sample size. Even though qualitative research approaches often have small sample sizes, we cannot expect a broad generalization of the findings unless we validated the outcomes with a larger sample size. This will be accomplished in future work. Also we are aware that household and medical technology are only exemplary technology fields, which might be relevant against the background of the demographic change. As a matter of fact there are other technology development, smart clothing or robot development, which should be also examined in this context.

The other is the focus on a decidedly European perspective. In future studies, we will have to work out to what extent insights won here also apply to other cultural backgrounds and societies with different value systems, different education levels, and different economic structures [START_REF] Sensales | Attitudes toward Computers, Science, and Technology A Cross-Cultural Comparison between Students in Rome and Los Angeles[END_REF], [START_REF] Alagöz | Openness to Accept Medical Technology -A Cultural View[END_REF].

Figure 1 .

 1 Figure 1. Mentioned categories for medical and household technologies

Figure 2 .

 2 Figure 2. Mentioned categories for household technologies: gender effects

Figure 3 .

 3 Figure 3. Mentioned categories for medical technologies: gender effects

Figure

  Figure 4. Mentioned categories for household technologies: age effects

Figure 5 .

 5 Figure 5. Mentioned categories for medical technologies: age effects

Figure 7 .

 7 Figure 7. Mentioned categories for medical technologies: effects of health status

  their higher domain knowledge of how to handle medical technology.

Figure 8 .

 8 Figure 8. Conditional acceptance using motives in the different technology fields

0%

  20% 40% 60% 80% 100% …my friends also use it …it is chic (design) …it is fun to use ...it facilitates my everyday life ...it has lots of different functions …it is easy to use …it has a specific brand ...it is easy to learn …it has a long durability ...it is silent …it has a seal of approval …it reduces my dependency on surroundings …it respects my privacy ...it is reliable ...I trust the technology ...I have to (dependency) …it is the latest state of technology ...it is unobtrusive med-tech household I would use the technology, if...

Table 1 .

 1 Splitting of Participants into Age Groups

Age groups N age group % age group % female % male

	Age < 20	6	17	83	17
	Age 21-35	17	47	12	88
	Age 36-60	8	22	63	27
	Age > 60	5	14	20	80

Table 2 .

 2 Number and percentage of mentioned attributes: household and medical technologies

		Household Technology	Medical Technology
	Categories	n household	% household n med tech	% med tech
	Design	7	4.1	0	0
	Other	4	2.3	3	2.3
	Price	20	11.6	7	5.5
	Documentation	0	0	10	7.8
	Facilitation of everyday life	29	16.9	11	8.6
	Unobtrusiveness	4	2.3	16	12.5
	Functions & usability	58	33.7	21	16.4
	Flexibility & mobility	29	16.9	22	17.2
	Reliability	21	12.2	38	29.7
	Total of attributes	172	100	128	100

Acknowledgements

Authors thank participants, especially the older ones for their time and patience to volunteer in this study and to allow insights into a sensitive topic. Thanks also to Vanessa Schwittay for research support.