Heidi Krömker
email: heidi.kroemker@tu-ilmenau.de

Cindy Mayas
email: cindy.mayas@tu-ilmenau.de

Stephan Hörold
email: stephan.hoerold@tu-ilmenau.de

Personas for Requirements Engineering Opportunities and Challenges

Keywords: personas, requirements engineering, software engineering 1

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

The development process of software, products and services can be structured differently, e.g. in a linear way, following a waterfall model [START_REF] Royce | Managing the Development of Large Storage Systems[END_REF], or in an iterative way, following a spiral model [START_REF] Boehm | A Spiral Model of Software Development and Enhancement[END_REF]. Nowadays, an increasing use of agile, iterative or incremental software development processes can be observed [START_REF] Sommerville | Software Engineering[END_REF], which result from different workflows and changing attitudes towards development. Within these kinds of development processes, some decisions don't have to be made at the beginning and can be adjusted along the development. These adjustments often result from technical issues and challenges, or from incorporate phases of coordination with clients. While technical or organizational adjustments are realized, it is essential to validate them with user requirements. Therefore, knowledge about users is a prerequisite to keep up with these changes. However, this valuable knowledge about users is often neglected after the requirements specification [START_REF] Schneidewind | How personas support requirements engineering[END_REF].

Providing access to this original knowledge about users along the development process can support an agile, incremental, or iterative development. In this regard, personas [START_REF] Cooper | The Inmates are Running the Asylum[END_REF], which are commonly used in user-centered design and human-computer interaction activities, are not only a suitable method for the adequate documentation of users' attributes, but also a tool for empathizing with users' aims and needs [START_REF] Cooper | About Face 3: The Essentials of Interaction Design[END_REF].

Personas can be used by the development team for requirements engineering activities throughout the entire development process and in addition to user-centered design activities.

The integration of personas, as a kind of user description, in the requirements engineering activities, improves two aspects of the development: [START_REF] Royce | Managing the Development of Large Storage Systems[END_REF] considering multifaceted user needs in the early phases of development, when functional key decisions are taken, (2) continuous integration, verification and revision of user requirements to evaluate developed prototypes and intermediate products.

In the following, the opportunities and challenges of the integration of personas in the different activities of the requirements engineering process are described, based on the practice of five research and development projects using personas. The described approach is based on the work of Schneidewind et al. [START_REF] Schneidewind | How personas support requirements engineering[END_REF] and extends this work in regard to the entire development process, using the persona method as a tool for keeping requirements vivid along the development process.

Requirements Engineering Activities

Requirements engineering provides "a structured set of activities, which are followed to derive, validate and maintain a system requirements document" [START_REF] Kotonya | Requirements Engineering -Processes and Techniques[END_REF]. These requirements engineering activities are often described as a linear process, which results in a validated final requirements document, used as a basis for system planning and implementation [START_REF] Abran | Guide to the Software Engineering Body of Knowledge (SWEBOK)[END_REF]. Within the further development process, additional managing activities have to be undertaken, in order to react on changing needs of stakeholders or changing environmental or organizational conditions [START_REF] Kotonya | Requirements Engineering -Processes and Techniques[END_REF]. These requirements management activities are closely related to the requirements engineering activities. In addition, agile development processes also demand a more dynamic dealing with requirements. Especially in the context of software development, prototyping, testing, and evaluation of the system might implicate changes of the requirements documents, which have to be replicable and revisable [START_REF] Sawyer | Capturing the Benefits of Requirements Engineering[END_REF]. The approach of Nuseibah and Easterbrook [START_REF] Nuseibah | Requirements engineering: a roadmap[END_REF] not only considers the developing activities of requirement documentation but also these evolving activities to adapt changes. In order to emphasize the incremental character of these activities, this approach is transferred to the spiral model of Kotonya and Sommerville [START_REF] Kotonya | Requirements Engineering -Processes and Techniques[END_REF], as shown in figure 1. As a consequence, the following activities [START_REF] Nuseibah | Requirements engineering: a roadmap[END_REF] have to be undertaken iteratively.

Eliciting Requirements

The elicitation activities provide methods and techniques to capture information about goals, domain knowledge, stakeholders and actors, as well as the operational environment of the system [START_REF] Abran | Guide to the Software Engineering Body of Knowledge (SWEBOK)[END_REF]. The core eliciting activities are part of the first iteration of the requirements engineering process. As a result, an informal statement of requirements is developed as a basis for further activities. Changes of requirements imply a reinterpretation or recollection of the information material in further iterations.

2.2

Modelling and Analyzing Requirements

Modelling activities result in abstract descriptions respectively diagrams, based on specific modelling languages, and present the core activities of the requirements engineering process [START_REF] Nuseibah | Requirements engineering: a roadmap[END_REF]. In addition, the analyzing activities include the detection and resolving of conflicts between requirements and the determination of the bounds of the system [START_REF] Abran | Guide to the Software Engineering Body of Knowledge (SWEBOK)[END_REF]. Both, modelling and analyzing, are essential activities in all iterations and result in a common understanding of the requirements.

Communicating Requirements

The aim of the communication activities is the description of the requirements in an explicit and comprehensible language or notation [START_REF] Nuseibah | Requirements engineering: a roadmap[END_REF]. Next to the specification of the requirements, the kind of the documentation in a logic or natural, formal or informal language is also essential for the further usage of the resulting draft of the requirements document. Along with the documentation of the concrete system requirements, the description of the context of use, including users, tasks, and usage environment [START_REF]Ergonomics of human-system interaction -part 210: human-centred design for interactive systems[END_REF], should be communicated.

Agreeing Requirements

The agreeing activities are often called validation, with the aim to check the requirements document for consistency and completeness [START_REF] Kotonya | Requirements Engineering -Processes and Techniques[END_REF], for instance via requirements reviews. Moreover, the agreement with all stakeholders and the consideration of their goals and conflicts [START_REF] Nuseibah | Requirements engineering: a roadmap[END_REF] is an essential basis for the beginning of the following iterations.

Evolving Requirements

The evolving activities include methods and tools for the management of changes. A very important precondition for this requirements management is the traceability to check the impact of changes to further requirements [START_REF] Hofmann | Requirements engineering as a success factor in software projects[END_REF]. These activities have to accompany all the other activities of eliciting, analyzing, communicating, and agreeing continuously, in order to recognize potential risks of changes during the whole process.

Challenges of User Requirements

According to IEEE, requirements are "a documented representation of a condition or capability" that either "must be met or possessed by a system or system component" or is "needed by a user to solve a problem or achieve an objective" [START_REF]IEEE Standards Board: IEEE Standard Glossary of Software Engineering Terminology, IEEE Standard[END_REF]. In contrast to system requirements, which are derived from organizational, domain and platform restrictions [START_REF] Bruegge | Object-oriented software engineering: using UML, patterns, and Java[END_REF], user requirements are based on the user needs [START_REF]Systems and software engineering -Systems and software product Quality, Requirements and Evaluation (SQuaRE) -Common Industry Format (CIF) for usability: General framework for usability-related information[END_REF]. In development processes, user requirements are often neglected or reduced to design aspects of the user interface [START_REF] Jackson | Software Requirements & Specifications[END_REF][START_REF] Heiskari | Bridging the Gap Between Usability and Requirements Engineering[END_REF]. However, user requirements include information about users, tasks, and the environment [START_REF]Ergonomics of human-system interaction -part 210: human-centred design for interactive systems[END_REF], which concern not only usability aspects but also key decisions of system design and functionality. As a consequence, user requirements can provide a basis for the system development and the evaluation process. This approach requires a holistic integration of user needs into the requirements engineering process. But the characteristics of user needs involve some challenges for the requirements engineering process. The challenges have been identified within five research and development projects. The projects differ in their duration, team size, goals, and their area of application, as shown in table 1. The expectations of users often depend on their previous experiences with systems [START_REF] Hackos | User and Task Analysis for Interface Design[END_REF]. As a consequence, users are not able to imagine innovative system solutions or interactions, which differ from their current workflows. In order to provide flexible, open, and unbiased user requirements, it is important to identify the core goals and tasks of the users in detail, independently from current or future solutions. Otherwise, there is the risk of anticipating planned solutions, without considering the real user needs.

Analyzing challenge: User needs are rather imprecise and vague and partly even contradictory and illogical.

User needs often concern a complex task or goal of a user [START_REF] Hackos | User and Task Analysis for Interface Design[END_REF], which might be reached by different means and ways. Especially, systems, which are developed for several user groups, have to meet different user needs. But these needs respectively wishes might be inconsistent or illogical, not only in regard to different user groups, but also in regard to a single user. It is the responsibility of the usability and requirements engineers to solve these conflicts according to the best solution for the user, in order to reach the core goals and solve the tasks.

Communication challenge: User needs leave scope for interpretation along the development process.

The development and design process of a product integrates different stakeholders and developers with different opinions. Cooper et al. point out, that the user can be used to justify different personal opinions within a discussion, without having the user needs in mind, but the own idea of the product [START_REF] Cooper | About Face 3: The Essentials of Interaction Design[END_REF]. Therefore, a common understanding of the user based on real user data is needed, which can be understood by all involved stakeholders.

These mentioned challenges lead to the result, that there is a high potential to improve the user descriptions for requirements engineering activities. Current user descriptions are modeled in a very structured way, which is not sufficiently vivid and flexible. For instance, user roles focus on the tasks, but neglect the users' motivation and actions as well as the context of use [START_REF]Ergonomics of human-system interaction -part 210: human-centred design for interactive systems[END_REF]. These approaches give a short overview, but do not enable the developer to feel empathy with the user, in order to also consider user needs into new upcoming development decisions. When key decisions are only taken from the developers' point of view or even the developers interpret their own needs as user needs, the project risks failing to meet the real user needs.

Describing Users with Personas

Software, requirements and usability engineering have a set of different methods to describe users in regard to the needed detail level and purpose of the description. Personas provide a method to communicate typical behavior, motivation and goals of users in order to personify a group of users [START_REF] Cooper | The Inmates are Running the Asylum[END_REF]. Personas are archetypes, which are derived from the dispositions and behavior of real people, but describe fictitious and clearly distinguishable characters. Compared to other methods for user descriptions, the strengths of personas [START_REF] Cooper | About Face 3: The Essentials of Interaction Design[END_REF] are:

 User-oriented determination of product characteristics based on goals and tasks,  Universal communication tool for different stakeholders within the development process, especially to discuss challenges and solutions, based on a common understanding of the users,  Ad hoc evaluation tool, to reflect decisions and changes from a users' point of view.

Fig. 2. Example of a persona

In general, the activities of the process for creating personas vary slightly between different authors [START_REF] Cooper | About Face 3: The Essentials of Interaction Design[END_REF], [START_REF] Pruitt | The Persona Lifecycle: Keeping People in Mind throughout Product Design[END_REF]. But all creating processes focus on the described strengths of personas and are based on qualitative and quantitative data, derived from analysis and statistics. Therefore, the approaches follow the same basic steps [START_REF] Mayas | Meeting the Challenges of Individual Passenger Information with Personas[END_REF] starting with an identification of variables and values, followed by an identification of patterns, and the description of the persona, e.g. as shown in figure 2, and its validation. The following overview presents the core activities of each step of the persona creation:

1. Identifying variables and values includes the operationalization of the activities, attitudes, aptitudes, motivations and skills [START_REF] Cooper | About Face 3: The Essentials of Interaction Design[END_REF] of the potential users, in respect to the product. The values represent specific manifestations of a variable, which differ from user to user and are revealed by qualitative and quantitative user research methods, for instance in interviews and observations, statistical reviews. 2. Identifying patterns maps the processed user data to a value of each variable. As a next step, the most frequent combinations of values are analyzed and classified into typical behavioral disposition. These patterns build the basis for the creation of the "skeleton" of the persona.

3.

Describing personas enriches the patterns with demographic variables. Next to a name, age, and hobbies, some attributes of the character, a personal story, and a picture are added to the persona, in order to encourage more empathy with the user. 4. Validating personas includes the verification of the final typical dispositions of the personas as well as the agreement process with the stakeholders of the system and their political, organizational and legal restrictions.

The integration of personas into the requirements engineering process concerns two fields of work. Firstly, the creation process of the persona itself has to be integrated into the requirements engineering process. This integration of working activities is mainly related to the first iteration of the requirements engineering process, as shown in section 5. Secondly, the usage of the personas, as a result of the persona creation process, provides advantages for several requirements engineering activities in further iteration, which are described in section 6.

Integrating the Persona Creation Process

Current approaches to integrate user descriptions into the requirements engineering process are largely limited to the eliciting and analysis activities [START_REF] Whitehead | Collaboration in software engineering: a roadmap[END_REF][START_REF] Ferré | Integration of usability techniques into the software development process[END_REF]. Some approaches also suggest the integration of several user-centered design activities, such as user studies and usability testing, into the requirements engineering process [START_REF] Paech | Usability engineering integrated with requirements engineering[END_REF][START_REF] Sousa | RUPi -a unified process that integrates Human-Computer Interaction and software engineering[END_REF]. The usage of personas as user descriptions were suggested by Castro, Acuña and Juristo [START_REF] Castro | Enriching Requirements Analysis with the Personas Technique[END_REF], who developed an advanced persona technique and integrated the identified detailed creation activities within the whole requirements process. In this way, the developed persona is an additional result at the end of the requirements engineering process.

In contrast, we recommend to create the persona in the first iteration of the requirements engineering process, in order to provide the results of the persona creation as an added value to the majority of the requirements engineering activities in further iterations.

The development of personas is a creation process, which consists of different activities, as described in section 3. These activities of persona creation are comparable to the requirements engineering activities, and transferable to the requirements engineering process, as shown in figure 3. Within the first elicitation phase, information about the context of use is collected, which build an important basis for both, the development of personas and further requirements. By these means, the variables and values defining the characteristics of the personas are identified, next to the first informal statement of requirements. As a next step, the elicited information is structured and analyzed for the identification of behavioral patterns of personas. The typical language to communicate personas is the textual form in combination with a picture (cf. fig. 2), which should be added to the draft of the requirements document. Finally, these descriptions are validated and can be agreed with the stakeholders in combination with other requirements documents.

Fig. 3. Integration of personas into the requirements engineering process

Opportunities of the Integration of Personas into the Requirements Engineering Activities

The integration of the created personas provides benefits for the different requirements engineering activities. Each benefit is supported by an example from a research and standardization project on passenger information in public transport, which provides a context of use with different actors, tasks and systems in a mobile environment. Therefore, the examples focus on a complex field of applications, which is similar to other fields of applications where the mentioned challenges typically arise.

Eliciting Requirements

Benefit: Personas support the identification of actors and scenarios. Often, the development process focuses not only on one type of user in a specified scenario, but also on several actors within the context of use. Personas support the identification of these actors, based on their characteristics, and describe them from a holistic point of view. Therefore, scenarios can be derived more easily and different aspects of the usage and accompanying contexts can be addressed.

Example. Within the mentioned field of application of passenger information, actors include passengers and personnel of transport companies, which e.g. can be divided into operators, dispatchers and service staff. The term "passengers" represents a heterogonous group of users, e.g. tourists and commuters, which can be described with personas [START_REF] Mayas | Meeting the Challenges of Individual Passenger Information with Personas[END_REF]. Scenarios can cover typical situations, e.g. the daily route to work, or special situations, e.g. disturbances, including the different perspectives of the personas [START_REF] Mayas | Internet Protokoll basierte Kommunikationsdienste im öffentlichen Verkehr: Das Begleitheft für den Entwicklungsprozess -Personas[END_REF].

Benefit: Personas support the specification and prioritization of use cases. Use cases [START_REF] Cockburn | Writing Effective Use Cases[END_REF] can be derived from personas and scenarios to cover the different aspects in a more abstract way. Within the same process, personas can be used to prioritize use cases. The description of a persona supports an individual analysis of use cases and thereby overcomes the abstract actor oriented approach, where a prioritization can be hardly connected to the different users. Compared to the definition of use cases by Cockburn [START_REF] Cockburn | Writing Effective Use Cases[END_REF], which includes the context of use, stakeholders and their interests, as well as preconditions and end conditions, personas and scenarios already provide these information and extend them by adding motivations, goals and other personal characteristics.

Example. The decision, whether a function to support sightseeing information or a function to support alternative routing in disturbances situations, should be favored within a passenger information system, can hardly be derived from use cases alone. It requires information about the context of use, especially the users and connected scenarios. This information can lead to the result, that alternative routing information will be used by different personas, while sightseeing is used solely by the tourist persona. Therefore, the alternative function will most likely receive a higher priority.

Modelling and Analyzing Requirements

Benefit: Personas support the prioritization of requirements. Requirements are usually not all equal in their priority. Priorities can be given in regard to clients' wishes, technical feasibility or user needs. The comprehensive knowledge, combined within the persona descriptions, facilitates the comparison of the requirements of different users for the development team. In addition, personas serve as a neutral and agreed basis for discussion.

Example. Within passenger information systems, different time related information can be found. Therefore, the list of requirements will include a number of requirements focusing on this time related information. A decision, as to whether the remaining minutes to departure or the time of departure should be used, or if real-time information is needed, can be made based on the needs of the personas.

Benefit: Personas support the deeper understanding of requirements. In order to manage development challenges and requirements changes, the development team should have a deeper understanding of the requirements. In contrast to separated requirements lists, personas can provide additional information to get a holistic view of the requirements. Therefore, an adequate traceability of requirements and personas is an important prerequisite.

Example. The development of the passenger information system included a set of requirements, which focuses on information and different presentation functions.

Personas support developers implementing these functions by providing a context for the requirement. In a passenger information system not only the mere information, but also the combination with other information provides useful support for the passenger.

Communicating Requirements

Benefit: Personas support the comprehensible communication of requirements to stakeholders. As described in the previous benefits, the memorable and comprehensible descriptions of personas in natural language and pictures can play an important role for the eliciting and analyzing activities. The same advantages support the identification with users, their needs and goals for the different stakeholders. An integration of the personas into the requirements document therefore improves the understanding of the whole requirements document.

Example. The developed personas for users of a passenger information were presented in a booklet [START_REF] Mayas | Internet Protokoll basierte Kommunikationsdienste im öffentlichen Verkehr: Das Begleitheft für den Entwicklungsprozess -Personas[END_REF]. The persona booklet was easy to handle and permanently available to all developers and stakeholders. In addition, further types of information, such as presentations, positioned figurative representations, or integrations into the daily routines also support the communication and the memorization of personas for the developers.

Agreeing Requirements

Benefit: Personas support the validation of requirements. The usage of personas during validation activities ensures the consideration of the user perspective during requirements reviews or testing. Thereby, personas can not only indicate an incompleteness of requirements, but also help to solve conflicts between the stakeholders.

Example. In order to validate the requirements for a passenger information system, typical user requests to the system were derived from each persona. Subsequently, the requirements were checked to ensure a response to these requests, according to the specific user needs and expectations. In later iterations, these user requests could also be used for system and component tests, in order to ensure the correct responses to the requests.

Evolving Requirements

Benefit: Personas support the tracing of requirements. Along the development process, requirements are changed due to different reasons, e.g. technical issues or results of usability evaluations. Personas can not only support the decision and evaluation process of these changes by integrating the users' perspective, but also keep track of related requirements and influences resulting from these changes. In addition, persons can be used to measure the compliance to requirements from another perspective. In regard to the final product, the persona perspective provides more reliable results, as the perspective is already based on the final users.

Example. Even when a function is rated with high priority, situations along the development process can arise, where the requirements related to this function are questioned, due to different reasons. For instance, the departure timer within a mobile passenger application was questioned within the development process. The assessment of neglecting this function using the personas revealed that this function can be considered as an added value for several personas, but the departure timer does not represent a key function to solve a task. As a result, the requirements of the departure timer were removed.

Conclusion

Today, requirements engineering lacks a well-established process to combine personas as a type of user descriptions and requirements engineering activities. However, personas are already used to overcome different challenges along the development and requirements engineering process [START_REF] Miller | Personas: Moving Beyond Role-Based Requirements-Engineering[END_REF][START_REF] Sim | Empowering Requirements Engineering Activities with Personas[END_REF][START_REF] Aoyama | Persona-and-scenario based requirements engineering for software embedded in digital consumer products[END_REF][START_REF] Lopez-Lorca | One size doesn't fit all: diversifying "the user" using personas and emotional scenarios[END_REF]. Therefore, personas can be considered as a powerful method to provide vivid descriptions and requirements along the development and requirements engineering process. In addition, the persona method bridges the gap between requirements engineering, user-centered software development and human-computer-interaction.

Based on the experiences of development and research projects of different scale and content, the described approach shows solutions to integrate the persona creation process and the persona artefacts in the requirements engineering activities. The benefits of the usage of personas and their exemplary application are described for wellestablished methods of requirements engineering. However, the validation of these findings still requires a systematical analysis of the requirements engineering activities in further development projects.

Personas provide a user-oriented overall context, which includes tasks, values, and motivations, for single requirements. The integration of personas into development projects ensures the consideration of the user needs in all requirements engineering activities and supports the solution of conflicts between requirements, as described by Miller and Williams [START_REF] Miller | Personas: Moving Beyond Role-Based Requirements-Engineering[END_REF]. By these means, personas support the requirements engineering process, serve as a stable reference for agile and iterative development processes and increase the usability of the final products.

Fig. 1 .

 1 Fig. 1. Spiral model of the requirements engineering activities (based on the approaches of Kotonya and Sommerville [7] and Nuseibah and Easterbrook [10])

Table 1 .

 1 Overview of research and development projects

	Project	Duration	Team size	Goal	Area of application
	Project A	3.5 years	20 members Communication standard	Public transport
	Project C	2.5 years	7 members	Mobile planning application Logistics
	Project B	2 years	5 members	Predictive diagnosis system Automotive industry
	Project D	2 years	3 members	B2B system	E-commerce
	Project E	0.5 years	2 members	Public display user interface Public transport

User needs are independent from the planned solution.

Acknowledgements.

The application example is part of the IP-KOM-ÖV project, which was funded by the German Federal Ministry of Economy and Technology (BMWi) grant number 19P10003L.


Yan Hu
email: yan.hu@bth.se

Guohua Bai
email: guohua.bai@bth.se

Jenny Lundberg
email: jenny.lundberg@lnu.se

Sara Eriksén
email: sara.eriksen@bth.se

A Virtual Community Design for Home-Based Chronic Disease Healthcare

Keywords: virtual community, self-management, home-based chronic disease healthcare, requirements, activity theory

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Chronic diseases are increasingly becoming a main factor influencing human health and wellbeing all over the world. According to the World Health Organization (WHO) [START_REF] Eriksén | Chronic diseases and health promotion[END_REF], chronic diseases represent 60% of all deaths in the world, and are thus the leading cause of mortality. Chronic diseases last for a long time, and can hardly be cured [START_REF]What is Chronic Disease? | Center for Managing Chronic Disease -Putting People at the Center of Solutions[END_REF], therefore how to provide preventive and monitoring healthcare becomes a worldwide goal. Since patients suffering from chronic diseases have to be monitored from time to time, it leads to high cost, and becomes time consuming and inconvenient for the patients. This time-to-time monitoring limits the patients' daily activities and is especially inconvenient for aged people. Since mostly chronic diseases do not need urgent medical diagnosis and treatment [START_REF] Lin | A pervasive health monitoring service system based on ubiquitous network technology[END_REF], we suggest moving the front desk of chronic diseases healthcare from hospital-based to home-based care. This shift may save a lot of patient time and medical resources, and provide a convenient environment for continued living at home despite an increasing need of monitoring of health.

Thanks to the development of information and communication technology (ICT), the above suggested home-based healthcare is now becoming highly recommended [START_REF] Lin | A pervasive health monitoring service system based on ubiquitous network technology[END_REF]. Many physiological signals can be measured by individuals in their living environments during daily activities [START_REF] Chen | Web-based remote human pulse monitoring system with intelligent data analysis for home health care[END_REF]. This paper will propose one important service function for such a home-based solution, namely virtual community based webservices. With this virtual community, people with chronic diseases can quickly and directly communicate with each other (supporting peer-to-peer learning), and also with healthcare providers and family members concerning their ongoing situation. With various needed services based on this virtual community, patients can have an independent living at home with improved life quality. This paper will start by discussing the understanding of 'community' based on social-psychological activity theory and interpreted in the concrete context of homebased healthcare for chronic diseases. In the second part, a requirement elicitation is carried out based on a survey among potential users (55+ with chronic diseases). In the third part we analyze the collected 27 answers we got concerning the most needed requirements for a virtual community. Based on the defined requirements, in the fourth part we present a prototype we have developed to demonstrate how to design a web-based virtual community to integrate those identified needs for the targeted users, especially elderly users. Finally, we discuss some weaknesses and limitations with the proposed solution, and conclude with conclusions.

What is a virtual community?

A community is broadly defined as "a group or network of persons who are connected (objectively) to each other by relatively durable social relations that extend beyond immediate genealogical ties, and who mutually define that relationship (subjectively) as important to their social identity and social practice." [START_REF] Zimmer-Tamakoshi | Sustainable Communities, Sustainable Development: Other Paths for Papua New Guinea[END_REF]. Since the introduction of the now widely used Internet, the concept of community today has less geographical limitation, as people can now gather virtually in an online community and share common interests regardless of physical location. This kind of community, with far less constraints due to genealogical distance and far more oriented to shared interests and objectives, is what we call a virtual community. A virtual community is a social network that people interact with through specific social media, of which there are many good examples, such as Facebook and Twitter. This virtual community allows people to communicate with each other about their common interests without considering geographical distance.

Based on the model of Activity Theory (Fig. 1), a community is generally defined as a group of people who are engaged in conducting activities to approach a shared goal or outcome. In relation to service oriented activity where the object is the recipients of the conducted service activity (not as a materialized object), the members of this community can be divided into three groups: 1) people who are actively conducting the service activities, here called a subject; 2) people who are acted on by the subject, here called an object; and 3) people who are not directly acting or being acted on, but who are associated with the ongoing activity.

The model in Fig. 1 visualizes the components that compose an activity and interactions in an activity. According to the model, an activity is always conducted by one or several goal-oriented actors, labeled as a subject in the model. The subject is always directed towards or acting on an object in order to produce an outcome. The community in this model is the collective of the above three groups of people involved in conducting the activity. Rules are various regulations for how to conduct activities and serve as mediating function within the community if any disagreement appears in conducting the activity. Tools are artifacts (physical, conceptual, or signs) used by the subject in the process of acting in order to produce the outcome. Division of labor specifies the responsibility within the community, i.e., which parts of the object's needs should be implemented by which members of the community.

Fig. 1. Engeström's Activity Model [6]

To apply the above concept of community in the activity context of home-based healthcare, we will interpret the model in concrete terms related to the context. The outcome or goal of the activity is to improve the healthcare recipient's health. The subject is the healthcare providers such as doctors, nurses, family members. The object is the healthcare recipients, in this case they are people who are suffering from chronic diseases. Tools are all kinds of artifacts, which are used to support the activity, physical and non-physical, such as EHRs, Internet, healthcare monitor devices, as well as treatment-related knowledge and methods. The rules regulate the actions of the actors, and consist of for example healthcare laws, privacy and security policies and so on. Division of labor determines the responsibilities of different healthcare providers and healthcare recipients themselves. In this activity model, besides subject (actors) and object (recipients), the community includes also other healthcare actors, such as family members of the care recipients, other healthcare recipients who share the same interest, and research institutes that are associated with the results of the activity.

In home-based healthcare, self-management is highly encouraged, and in this selfmanagement the healthcare recipients become the subject (actor) and the object (being self-acted) simultaneously. The healthcare recipients can also start acting in relation to the healthcare providers, for example if the patient alerts his/her nurse about newly recorded abnormal blood pressure for online consultancy. In this case the role of subject in traditional hospital care is now becoming an object in home-based healthcare. We call this property subject-object mutuality [START_REF] Bai | A general architecture for developing a sustainable elderly care e-health system[END_REF]. The design of the virtual community must consider different roles of actors with their expected functions and tools. In the next section, we will focus first on the healthcare recipients' perspective in the activity context of home-based healthcare.

3

Requirements collection of community

Requirements from healthcare recipients

A good virtual community should attract people with the same interests into a meeting place, but more importantly, the virtual community should in this case provide healthcare tools and services. Patient-centered self-management is the main trend for home-based chronic disease healthcare, and the virtual community in this case should first focus on the needs of the targeted patients. There are already some commercial or research-based solutions for supporting self-management. For instance, HealthVault [START_REF] Healthvault | [END_REF], launched by Microsoft, is a web-based PHR system for storing and managing health information. A lot of specific third-party applications, such as blood pressure management tools and medical image viewers, as well as hundreds of devices such as blood glucose meters and blood pressure monitors, can cooperate with this platform to record health data.

In order to meet most users' needs when designing the online virtual community, we begin with requirements specification. There are two types of requirements in website design and software engineering, functional requirements and non-functional requirements [START_REF] Rogers | Interaction Design: Beyond Human -Computer Interaction[END_REF]. As we mentioned above, in home-based healthcare, patients are at the center of the healthcare, as well as the main users. So we selected online questionnaires to be answered by the potential healthcare recipients as the key data-gathering technique.

Questionnaires include a series of questions designed to elicit specific information from the users. Well-designed questionnaires are a good way to get answers to specific questions from a group of people, especially for people whom it is not feasible to visit individually and interview [START_REF] Rogers | Interaction Design: Beyond Human -Computer Interaction[END_REF]. In this case, the questions are mostly designed for functional requirements as seen from the healthcare recipients' perspective. Due to the time and resources limitation, for our questionnaires, the questions are published on surveymonkey.com as the electronic form rather than a paper form. The respondents are selected from within an age group consisting of people above 55 years of age and living with one or more chronic diseases. We send out the questionnaires through social network websites, for example, social groups of some specific chronic diseases ex. Diabetes from patientslikeme and facebook. The questionnaire contains 10 questions, and includes both simple Yes or No questions, questions allowing the respondent to choose from a set of pre-supplied answers, and open comment questions. In the end, 25 valid responses out of 27 are gathered. Most of the respondents are from US [START_REF] Healthvault | [END_REF] and Sweden [START_REF]1177 Vårdguiden -sjukdomar, undersökningar, hitta vård[END_REF]. We consider that the geographical difference may effect some results, so the questions are designed to reduce this influence as possible. From the collected answers, we find that the influence is very low.

Problems in current healthcare

The first open question is about the problems people face concerning their current healthcare. Almost all the respondents mentioned that the long time they spend waiting for doctors' appointments make them uncomfortable. "The resource is limited. It means I need to spend more time waiting for the healthcare service. And since I am waiting for the doctor, I really also need suggestions to keep my body stable, not get worse." "Really long queue every time when I visit some hospitals". In some countries like Sweden, the shortage of healthcare providers leads to long waiting lines for visiting primary care as well as hospitals. Sometimes the patients have to wait so long that they lose the best opportunity for diagnoses and treatments in relation to curing or sustainably managing their diseases. Another big problem the respondents highlighted is lack of information sharing among different healthcare providers. When they come to the new healthcare organizations, their historical healthcare records are difficult to find. "When I went to another hospital which I never visited before, the doctor didn't know my health history, if I am hypersensitive to some drugs, he didn't know, so this may cause some healthcare problems. If I need to have a new scratch test taken to determine what I am hypersensitive to, it wastes time and resources." "There is no shared information among the hospitals. It cannot help the care providers to communicate to each other." This causes overlap check-ups for the healthcare recipients, which is a waste of time and resources. Besides the above two quotes, some respondents also point out that the location of the healthcare center is far away from their home, and that it is inconvenient for them to go to healthcare centers frequently.

Views of online healthcare community

When asked about the time spent on Internet per day, 60% of the respondents spend more than 6 hours on-line, see Fig. 2, which means Internet has already become an essential part of their daily lives. Because of the high rate of Internet usage, the online healthcare community is acceptable. All the respondents say they would like to have an online healthcare community, where they could chat with all stakeholders related to their healthcare through one platform. The answers concerning which people they want to chat with through the online community show the following: doctors (96%), other healthcare providers (84%), other people with same symptoms (72%), family members (68%) and some healthcare research institutions (64%).

Fig. 2. Hours spent on Internet per day

Online community functions design

In Questions 5 to 8, we ask about some specific functions of the online healthcare community. The results are shown in Fig. 3. From the figure, we can see that all functions we plan to develop are supported by most of the respondents. Question 10 is an open question about other functions they would like to have. Online simple diagnose was one of the most desirable functions. Free seminars and lectures about healthcare is another suggestion by most of the respondents. "Simple medical suggestions and brief medical diagnosis", "Diagnosis, chatting, forum, online seminar" "diagnosis online" and "Healthcare lecture" were mentioned most. In addition, fast contact and response, risk prediction, decision support systems and information about nearby healthcare centers were also suggested. In Question 9, the respondents were asked which features are important for them as the users of online community. Availability (100%), usability (88%), security (88%) and privacy (84%) all got very high support.

Requirements from healthcare providers

One of the aims of building up this online care community is to encourage the care recipients to be the main driving forces of their home-based healthcare. Still, the virtual community will only develop in a sustainable way if the tools provided support and meet the needs of all the aimed-for user groups. The requirements of healthcare providers are gathered mainly based on interviews and informal discussions with doctors, nurses and homecare providers.

In the current Swedish healthcare system, most nurses are working daily with 5 to 10 different IT systems, and only a few of these systems share data with each other. Sometimes they just record the same simple data repetitively in different systems due to this lack of compatibility between systems, which is perceived as a waste of time and in some way decreases the work enthusiasm. There is a national electronic service called National Patient Overview (Nationell Patientöversikt -NPÖ), which enables healthcare providers to share patient healthcare records with other healthcare providers through computer networks. The purposes of NPÖ are to facilitate cooperation among different healthcare providers in Sweden, as well as giving healthcare recipients access to their own healthcare information [START_REF]Patientjournalen -1177 Vårdguiden -sjukdomar, undersökningar, hitta vård[END_REF]. NPÖ assists cooperation among different healthcare providers at the national level. However, it is predominantly a solution for hospital-based healthcare, as the direct beneficiary of this service is the healthcare providers. Even for the healthcare providers, only doctors have full access to the records. When shifting to home-based chronic disease care, NPÖ can provide few access rights for healthcare recipients. Also, as home-based healthcare involves other parties like family members and other patients with the same symptoms, how to share data with these parties is another challenge. In addition, NPÖ is only used for sharing healthcare information in Sweden; when people go abroad, it is quite difficult for them to access their healthcare data. In Europe, there are some projects aim to provide cross-border eHealth services by exchange patients' summaries between healthcare institutions such as epSOS [START_REF]epSOS: About epSOS[END_REF], however, most of them are still in the test phases.

The basic way of communicating with care recipients now is still face-to-face. The emergence of the national digital healthcare portal 1177 [START_REF]1177 Vårdguiden -sjukdomar, undersökningar, hitta vård[END_REF] helps most healthcare recipients to communicate with their providers without face-to-face visiting, but there are still several issues it cannot cover. For example, it cannot provide medical suggestions because of different care duties, and communication is lagging in some cases due to technical reasons and wrong contact responsible line. Through the minavårdkontakter contact provided by 1177, care recipients can send some message to their providers, but the average response time is around 5 days. And from the care providers' view, a telephone call is better than sending an online message or email, because it is difficult to understand the text written by the care recipients.

For the management of chronic diseases such as diabetes, the normal way now is that the healthcare recipients go to the hospital, and are checked and given advice by nurses first. The nurses will teach the patients how to self-record every day's blood sugar values. Then when the patients go back home, they record the data as instructed and send their values via SMS to the nurse. There is an IT management system in hospitals for the nurses, but it does not share any information to neither other care providers nor care recipients.

Main functional requirements

In this section, we list the simple functional requirements of the online virtual community as documented through our questionnaires. Table 1 is the requirements list of the online community design. The traditional way of documenting requirements consists of contract style requirement lists [START_REF] Berenbach | Software & Systems Requirements Engineering: In Practice[END_REF]. This provides a high level requirements description for a large system. However such requirements descriptions usually cover hundreds of pages and are not reader-friendly. For our community design, we use the user stories style to describe the functional requirements in order to support easy and comprehensive understanding and quick changes. A user story is used with agile software development methodologies. It contains one or more sentences in everyday language to describe what an end user wants to do or needs as part of the functions [START_REF]Guide to Agile Practices[END_REF].

Non-functional requirement issues

A non-functional requirement is a requirement used to measure the operation of a system, rather than specific behaviors [START_REF] Glinz | On Non-Functional Requirements[END_REF]. In software systems, non-functional requirements are also considered as quality attributes. For our community design, usability, security and privacy, as well as availability are main issues of non-functional requirements [START_REF] Chung | On Non-Functional Requirements in Software Engineering[END_REF].

Usability: Usability is defined as "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use." [START_REF]1992 -Ergonomic requirements for office work with visual display terminals (VDTs) --Part 1: General introduction[END_REF]. According to [START_REF] Nielsen | CHAPTER 1 -What Is Usability? User Exp[END_REF] usability can be measured by five variables which are defined as learnability, efficiency, memorability, errors, and users' satisfaction. The main users of this online community are elderly people with chronic diseases, thus the designed services in the virtual community should be extremely simple to use and easy to learn. As design guidelines, we follow the "Ten usability heuristics [START_REF] Nielsen | Ten usability heuristics[END_REF]", especially principles about knowing the users' needs, special visibility for elderly, consistency with elderly's daily language, and helping them recognize previous experience (reducing recall problem for elderly).

Privacy: The patient health information includes personal information, details of medical history, symptoms, treatments, associated diseases or even the family health history. It is important to ensure that only the patients can authorize exactly who can view the shared health information and for what purposes [START_REF] Braunstein | Health informatics in the cloud[END_REF]. All the information generated by a patient is not at the same sensitive level. Data segmentation may provide a method to protect specific sections of health information while giving choices to patients, and abiding requirements of legislation. Technical considerations and definition of sensitive information have to be addressed when segmenting data [START_REF] Goldstein | Data segmentation in electronic health information exchange: Policy considerations and analysis[END_REF].

Security: Security is assurance that only authorized persons or entities can gain access to patients' data. Employees' illegitimate access and theft is one of the most frequent reasons of data leakage [START_REF] Braunstein | Health informatics in the cloud[END_REF], as well as innocent disclosure because of system problems. Another issue is unauthorized access and malicious attacks from outside. So the encryption, identification and access control of patient health data are not optional for the online community development [START_REF] Braunstein | Health informatics in the cloud[END_REF].

Availability: As an online healthcare community, being available 24/7 is very important, because some functions, such as monitoring, tracking, alarming are critical for users' lives. Availability means also that the authorized users should be able to access the community from anywhere. More and more people, even elderly with chronic diseases are traveling worldwide, and the healthcare community must be mobile in the sense that it must allow them access from anywhere in the world, just like when they are in their own home.

Prototype design

With the requirements specified above, we will demonstrate a simple prototype in the following. We adopt a horizontal prototyping strategy, which means that the prototype should cover most parts of the required users' functions, without implementation of details [START_REF] Girija | Space-efficient scheduling of nested parallelism[END_REF]. Since it is a user-centered online community prototype, we try to keep it simple to use and easy to learn. The home page of the community is shown in Fig. 4, which is a very simple site for sign-up and sign-in with some guidance. In our prototype, the roles of users are divided into three types: healthcare recipient, healthcare provider and others like family members and researchers. The user type is selected by the users when they register in the system. After successfully registering, the information related to the role in the community will be displayed based on the user types. The role of the users decides the information and activities they can have access to in the online community.

When the user has finished registration and logged in to his or her account using a user name and password, the system will automatically direct the user to his or her sites according to the specified user role. As shown in Fig. 5, Anna Nilsson is a healthcare recipient, and the profile site has her basic information and the information relevant to her, such as her healthcare community, tools and rules that apply to her in her role. The contacts list in the middle has detailed information about all her care providers and other people relevant to her healthcare. In the right-bottom part, she can note her main symptoms so that people who have the same conditions can easily find her and they can share care experiences with each other. Fig. 6 is the profile page of a healthcare provider, Maria Karlsson; similar to the recipient's page, it contains her basic information and contacts list. In the right-bottom part, the tasks she has to do today are listed as a reminder. The page "my community" is designed based on the needs of the respondents who answered the questionnaires see Fig. 7. All the contact persons are listed in the right, including healthcare providers, family members and others. They can chat with each other when they are online, so the healthcare recipients can get feedback immediately from the healthcare providers without physically having to visit any healthcare organizations. The community also provides a space for users to post discussions, videos, links to websites etc. to share with their contacts. Another important function is that the community will always show information about the nearest healthcare centers based on the gathered user geographical data. The scheduled care activities will be shown rolling in red to remind the recipients.

Fig. 7. Healthcare community page

The most important function of the home-based healthcare community is to provide a self-management platform for the healthcare recipients. In our design, it is in the recipients' "My tools" page, shown in Fig. 8, the recipients update their basic physiological parameters, emotions and diet daily for record and trace. The authenticated healthcare providers can access the data and give some suggestions to recipients. The recipient can print out this data covering a long period as well to show the doctors and other care providers when they have an appointment. Online appointments are also proposed to reduce the waiting time for meeting doctors. In addition, personalized tools are introduced to the users so that they can use them based on their own needs. The healthcare providers' tools page includes functions for updating care history, appointment reminders, decision support systems for diagnoses and treatments and so on. The above prototype presents a general view of the design for a virtual community for home-based healthcare of chronic diseases. The design aimed to integrate healthcare recipients, healthcare providers and other relevant stakeholders into one community. This virtual community makes it possible to share the same platform for all the stakeholders who are engaged in the healthcare activity. With this shared community platform, the interoperability problems of current healthcare systems can be moderated. There exist various ways of applying ICT in eHealth, for example cloud computing. Cloud computing is beginning to demonstrate its great potentials in our daily healthcare due to its powerful services in managing big data, accessibility, flexibility, scalability and cost-effectiveness for services. Cloud technology mitigates the need to invest in IT infrastructure, by providing access to hardware, computing resources, applications, and services on a 'per use' model. And thus it dramatically brings down the cost and eases the adoption of technology. Besides, there are lots of existing privacy control mechanisms and security techniques in cloud computing which could help sensitive healthcare data protection. This will lead to radical new circumstances for offering eHealth services and constructing our new generation of healthcare information systems. The proposed virtual community in this paper will in the next step be implemented based on the cloud platform to ensure its accessibility, availability, and mobility, with careful design of security and privacy.

There are some limitations of this paper. Firstly, the healthcare recipient group that responded to our questionnaire was not large, due to the limited scope of our investigation and our restrictive rules (over 55 and have at least one chronic disease), so the care recipients' needs would require further investigation in the next step, based on a much larger sample. Secondly, as we are aiming to design a patient-centered healthcare community, the requirements of care providers would also require further investigation. In this case, they were gathered through interviews and informal discussions with only a few respondents, due to the time limitation for the study, so further work is needed to gain a better understanding of the needs of the care providers as well. However, the aim of this study was to develop a first prototype of a system for supporting the development of a virtual community for home-based chronic disease healthcare. This prototype can in future be used in a participatory design process to help future users envision and enact how new technological solutions can support and enhance healthy independent living and disease self-management.

Conclusion and future work

This paper proposed an online virtual community for home-based chronic disease healthcare. The design idea is inspired by social networking and based on the term "community" in activity theory. The requirements of the community were mainly gathered from the questionnaires with targeted healthcare recipients and interviewers with healthcare providers. We use "user stories" as they are used in agile software development to describe the requirements, and finally a prototype is designed based on the identified user requirements.

In the future, we will demonstrate this prototype to the potential users for evaluation. Further, more extensive interviews and surveys will be conducted with both healthcare recipients and healthcare providers to get more in-depth requirements from their respective perspectives. After this, we will develop the tools for supporting an online community based on cloud technology and test the proposed solution with future users for continued improvement and redesign. Ideally, such tools should be continuously further designed in use, together with the users, as part of quality lifecycle product and service management as well as part of the development of quality healthcare provision and self-management.

Fig. 3 .

 3 Fig. 3. Functions of the online healthcare community

Fig. 4 .

 4 Fig. 4. Home page of the community

Fig. 5 .Fig. 6 .

 56 Fig. 5. Healthcare recipients' profile

Fig. 8 .

 8 Fig. 8. Healthcare recipients' tool page

Table 1 .

 1 Requirements List

	User types	Descriptions
	All users	As a user, I want to register an account on the online healthcare
		community and choose my user type based on different roles.
		As a user, when I log in to my account, the information page
		will be displayed automatically according to my user type.
		As a user, I want to have an online chat with my contact persons
		such as care providers, care recipients, family members and so
		on.
		As a user, I want to have alarms to remind me of my care activi-
		ties.
		As a user, I want to have the all contract persons' address book
		with detailed contact information.
		As a user, I want to share some useful healthcare information
		with my contact persons.
	Care recipients	As a care recipient, I want to contact my care providers directly
		through the online community for simple diagnose and care
		suggestions.
		As a care recipient, I want to have some videos for providing
		healthcare education.
		As a care recipient, I want to record my daily health data myself
		in the community and share it with people whom I want to share
		with.
		As a care recipient, I want to have some tools to trace and check
		my care data, as well as to print it out when necessary.
		As a care recipient, I want to share my care experiences with
		people who have the same symptoms as I do.

As a care provider, I want to have a list of every day's work.