A design methodology for matching smart health requirements

As now well established, the world population is aging rapidly and, according to World Health Organization (WHO), the amount of people aged 60 years and older is expected to total 2 billion in 2050. For this reason, an emerging important issue is the definition of a new generation of healthcare platforms capable of monitoring people's quality of life. In this article, we propose a new methodology that supports the entire requirement elicitation process starting from the initial phase of gathering the requirements, both clinical, technological, and end‐user, up to the choice of the most suitable solution. Our proposal provides a new new iterative model in the smart healthcare field research area. Furthermore we apply our proposal in a real scenario and we report the end‐to‐end implementation of the proposed methodology.

bottles, can facilitate the monitoring of patients' activities and enable healthcare services at home. The ultimate aim is improving the QoL of the older population in a non-obtrusive way, allowing greater independence for individuals, maintaining wellness, preventing social isolation, and delaying their placement in institutions such as nursing homes and hospitals. For those reasons, mHealth monitoring systems are valuable for seniors' everyday life, and they acquire a key role even in conditions where the older adults must stay at home and keep physical distancing (e.g., seasonal influenza, weather alerts, and virus outbreak). Moreover, mHealth along with advances in hospital infrastructure is setting the stage for establishing smart health ecosystems all over the world by relying on the availability of data from mobile, wearables, and IoT devices both inside and outside of the hospital. The overarching concept of a smart health ecosystems is to integrate heterogeneous smart consumer and medical devices, as well as smart city infrastructures, to enable the continuous collection of data from the everyday life, which will be analyzed to obtain the evidence needed in order to offer personalized interventions. In the mHealth market, there is a wide selection of applications that track and access health and wellness data. However, the ways in which these applications are developed can vary since there are several factors to take into account.
Usually, mobile platforms are connected to Healthcare service providers' systems to obtain data (e.g., medical history) that may need to be considered in making decisions for interventions. Connected devices lead to the availability of more data for analytics, which in turn requires novel methods of managing large amounts of data and extracting meaning from raw datasets. In that regard, machine learning and big data technologies represent the ideal solution for managing and analyzing continuous data streams in large volumes 5 and for ensuring that actionable insights are presented to providers without overloading their workflows. 6 However, data management, access control, and data analysis can be handled using strategies of different complexity. Frameworks that assist developers in creating mHealth applications are for this reason spreading. These libraries and APIs guarantee functionality for storing and accessing data, managing permissions on types of data, and access to sensors given by a mobile device. The consistent integration of these systems within a specific context, characterized by different stakeholder needs and heterogeneous smart health infrastructures, is not trivial. Concerns about violating data access, sharing, and custody regulations must be appropriately addressed. 7 The reliability of data transmission and the availability of high relevant contextual information, request for efficient data summarizing and filtering mechanisms applied with conditional procedures. 8 A solid and flexible orchestration strategy must be placed on top of distributed data processing applications to get scalable data storage and data processing, to configure run-time monitoring, or to design appropriate visualization and reporting. 9 The regulatory constraints emerging from clinical protocols, organizational business processes, or legislation represent another source of design specifications to be considered. 10 These aspects must be integrated with basic design principles that assure the usefulness of a technological solution is also perceived as useful by its users. 11 In this article, we propose the matching smart health requirements (MSHR) methodology to design a smart health solution consistently taking into consideration requirements from different areas. Our aim is to support multiple requirements elicitation techniques, addressing user, technological, and organizational requirements. Our representation model makes explicit the relationships between requirements and the objective levels a solution has to achieve. This way we can reinforce the consistency of our specification and automate some procedures such as the prioritization of requirements and the selection of the best available solution. To test our proposal, we apply it at a real H2020 European Project named SMART BEAR. 1 The idea is to deliver an integrated technology solution that is easy to use and to maintain and that would enhance the elderly's independence. Therefore, a comprehensive understanding of potential end-users and their environments is performed since it allows discovering unexplored opportunities and matching subjective users' and stakeholders' needs and abilities with a consequent dramatic improvement of user experience that is the main driver for technology adoption. The initial analysis involved requirement elicitation from the three main stakeholders of our scenario: clinicians, technicians, and end-users. We then studied possible solutions and represented them in a feature space mapped to the elicited requirements using both objective and subjective assessments. This way, the selection of the most appropriate solution is obtained by a procedure that makes explicit the contribution of the single components but at the same time identify a global value of each solution. The article is structured as follows: Section 2 presents the state of the art, Section 3 introduces the proposed methodology, Section 4 reports on a case study where the methodology was applied, and Section 5 goes to the conclusions.

STATE OF THE ART
It is a fact that the European population growth is slowing down, while the population aging accelerates. The progressive decline in physical and cognitive skills due to aging prevents elderly people from living independently and from performing basic instrumental activities of daily living, for example, transportation, shopping, meal preparation, house cleaning, home maintenance, and managing medications.
In recent years, several sensing systems have been developed for monitoring and assessing the abilities and the "functions" of older people being indicators of the degree of autonomy and, accordingly, of the assistance needed. In the scientific literature, several works reported on case studies of design practices applied to the smart health. 12 Nevertheless, the subject's context is not yet extensively considered in the design process although it is judged by medical experts helpful for defining the older adult's dependency degree. Many studies, instead, reviewed the technologies that can 1 https://smart-bear.eu be exploited 13 to create smart health solutions. A merely technological approach may, however, reveal unsuccessful due to distance from the actual user's requirements, including those related to caregivers and clinicians. To be used, indeed, a technology has to be useful and the usefulness, both perceived and real, is only reached when the current needs and gaps in the clinical practice and in the older adults' everyday lives are examined and fulfilled. Understanding the barriers that would be an obstacle to technology usage by the older population is powerful but not always enough. As highlighted in Reference 11, new technology is accepted and adopted only if it can provide value to the users' lives. A user-centered design (UCD) 14 approach able to place the user at the center of the design process is therefore required. In that regard, Peek and colleagues 15  Despite the large availability of solutions, it was observed that we lack modular systems capable of holistically managing the problems of smart health ecosystems. 19 The guidelines proposed by technological frameworks do not take into consideration the needs of the users as described above and the binding with vendor-specific sensors is often a significant limitation. At the same time, UCD methods 14 do not address the information flow from the point of view of data processing, with implications on data interoperability, scalability, and access control. 8 The design of a smart health ecosystem is therefore a labor-intensive and error-prone activity, as also underlined in Reference 20. Our aim is to propose a methodology that can include semi-automatic procedures keeping a strong connection to both the UCD practices that are required in this domain and the technological requirements of distributed data ecosystems.

METHODOLOGY
A user-centered perspective cannot be disregarded in smart health. It is largely recognized that UCD means better patient care 21  MSHRs.
An innovative aspect of our methodology is the representation model adopted that allows expressing the interconnection between requirements of different classes together with their measurement levels. Background requirements refer to requirements not requesting any co-design action. Their sources are social, organizational, or regulatory constraints persisting prior to the design activity. Stakeholder requirements specify the need for stakeholders such as clinicians, patients, and caregivers. Solution requirements describe the characteristics that a solution must have to meet the needs of the stakeholders and background requirements. Requirements may be Functionalwhen they describe how a system must behave, or non-Functional when they describe system attributes. A requirement is considered a Goal when its achievement or performance can be measured.
An Objective measures the achievement of a goal by setting an expected or desired level.
Another innovative aspect is the support to the automation of specific steps such as the requirement prioritization or the selection of the best available solution. The requirements elicited are detailed in subsequent phases that allow interconnecting requirements of different classes and refining their specifications with objectives level or other details. In particular, MSHR is organized into four phases.

Domain analysis.
This stage is designed to survey the state of the art that identifies an initial set of requirements the project has to comply with. This includes the identification of the medical conditions to be targeted, the related clinical trials protocols, 22 the WHO guidelines 23 or other institutional guidelines to be considered, the quality of life standards 24 that define the assessment baselines, the SotA in quantitative sensory testing, 25 and other normative conditions such as legal, ethical, and privacy regulations. 26 The result of this stage produce a set of Background requirements typically valid for multiple projects that will be integrated with the Stakeholderand Solution requirements elicited in the subsequent phases.
2. Requirement gathering. This phase includes the elicitation of Stakeholder and Solutionrequirements of both Functional or non-Functional nature.
Different elicitation techniques are appropriate to different domains of analysis but two main categories are embraced in our methodology, that is, clinical and technological requirements. Focus groups and questionnaires are often used to get insights about the needs emerging from stakeholders and about the best practices and constraints recommended by technical experts about smart health technologies and their related regulations. When possible the requirements elicited at this stage are expressed in terms of Goals with their measurement scales.

Requirement integration.
Before considering the elicited requirements as valid they have to be analyzed in order to determine consistency between different statements. All these activities drive a stage of integration aimed at generating a consistent requirement specification list originated from Stakeholder and Solution requirements but better specified. In particular, conflicts can be removed and objectives and dependencies can be specified. Differently from a goal that simply focuses on "what" must be achieved, an objective specifies a way for measuring the achievement of a goal. A dependency identifies a relationship between requirements. For instance, if the overall goal is to track the emotional changes of a patient, one objective might be to track it daily or weekly, one dependency might be to not affect user acceptance by excessive use of questionnaires.

Solution selection.
Once the requirements are identified and organized in a consistent set of specifications, it is necessary to evaluate the technological solutions that can potentially meet the requirements. This includes devices, infrastructures, and software that must be described in terms of features using the same scale levels adopted for requirement Objectives by exploiting factual information and experts' subjective knowledge. At the same time, target objective levelsmust be defined by the designers translating the requirements specifications in measurable levels as well. The aim is to understand the level of fulfillment each solution can achieve. This produces an implicit identification of the priorities that will drive the development process. As different solutions will have a different level of fulfillment for different goals, multi-criteria decision analysis (MCDA) is required to identify the best available solution. Figure 1 presents the MSHR methodology illustrating that each stage takes in input the results produced by the preceding stage. Despite the methodology we present is proposed as a sequence of stages, we invite the reader to consider that each stage can be iterated multiple times, as largely performed in the practice of design science. In the following sections, we are discussing the requirement gathering methods suitable for the clinical and technical domain to then present in detail our representation model and the MCDA it supports.

Clinical requirements: Gathering, evaluation, and prioritization
The elicitation of clinical requirements has to remain anchored the UCD principles. 27,28 The co-design methodology, that is the first of the four processes of the UCD 14 (i.e., co-design, co-implementation, co-experimentation, and co-evaluation) and it is intended to provide an explicit understanding of end-users and stakeholders with their tasks and environments, has been here applied for the clinical requirements formulation of the proposed technological solution. The co-design process, in turn, encompasses four different phases: understand, analysis, explore, and define. In the understand phase, factors including both environmental, social and daily activity related ones influencing users' and stakeholders' lifestyle and wellbeing are defined according to an accurate literature review and domain analysis and, then investigated through, wherever possible, brainstorming activities with experts across different disciplines (e.g., clinicians, engineers, designers, developers). As a result, preliminary use cases and relevant enabler parameters are identified. In the analysis phase, instead, the detected use cases and parameters are analyzed from an experiential point of view by means of appropriate methods (as interviews, focus groups, questionnaires, and workshops). Such activity represents a key phase of the design process since it leads to the formulation of user requirements (URs) that describe what the user does and/or wants to do with the new technology and therefore they are essential for understanding which are the components and the functionalities able to satisfy the elicited needs.
Scenarios describing personas (i.e., archetypal real users) while exploiting the technological solution with particular attention to the interactions between all actors involved (e.g., users, direct and indirect stakeholders) are set up and explored with potential end-users in the next explore phase. 29 F I G U R E 1 Matching smart health requirements (MSHR): select the best available technological solution given the project's requirements A new list of URs that fully supports the previous requirements, fills the potential experiential gap observed, and adjusts the technological solution to actual end-users living contexts and daily life is lastly gathered with the conclusive definephase.
For a successful co-design, the sample population to involve, the strengths and the weaknesses of every feasible method have to be considered.
Domain analysis, 30 for instance, allows eliciting requirements of an existing system thanks to the study of available documentation (e.g., business plans, market studies, existing guidelines, research studies, procedures) and it is particularly useful to provide background knowledge about a particular product, feature, or technology. Interview 31 is a systematic approach to elicit information from a stakeholder or domain expert by face to face conversation and two main kinds of interviews can be identified: structured (where the interviewer has a predefined set of questions) and unstructured (where the interviewer tries to get the information from the stakeholders in open discussions). Focus group, 32 described as "a discussion within a small group of people that is focused on a certain topic and it is coordinated by a researcher/facilitator," represents a very popular and valid method to collect qualitative exploratory information in medical research. The facilitator's role is, indeed, to stimulate the active engagement of participants in the discussion and to gather as much useful information as possible. Closed and open-ended questionnaires, 33 instead, allow gathering data from a large number of people in a short time and little cost. However, to be successful, its design should be effective and the respondents should be honest while compiling. Finally, workshop is a focused, intensive and time-consuming collection of meetings in which the stakeholders discuss, discover, define, and reach closure on requirements for the target system. Well-run workshops are considered one of the most effective ways to deliver, from a reduced number of users, high-quality requirements quickly.
Once information are available, two main analytical methodologies can be employed to examine the collected data: (i) qualitative analysis where analytical categories were used to describe and explain specific phenomena (e.g., content analysis), and (ii) quantitative analysis where data are compressed, grouped into classes and raw numbers are converted into percentages in order to provide a numerical summary of the sample of study and its measures of interest.
Once a consistent specification of the clinical requirements is defined, the translation of this specification into Goals and Objectives is needed to set the basis for further elicitation activities, mostly oriented to the technological aspect of the platform. 34

Technical requirements: Gathering, evaluation, and prioritization
Technical requirements are elicited by relying on experts' knowledge and, for this reason, may exploit techniques oriented to the conciliation of qualitative and quantitative assessments. In our methodology, we adopt the Kano model 35 (KM) as the approach to be used in order to classify requirements based on their priority level. The KM is a useful tool for understanding the needs and expectations of a stakeholder-based on how they affect his/her satisfaction with a given product (e.g., a device or a software system). KM is based upon three premises: (i) the satisfaction of a stakeholder with the features of a product depends on the level of functionality that is provided, that is, how much or how well the features are implemented. A feature is a condition or capability of the product that can be captured by a requirement; (ii) requirements can be categorized, depending on how the associated features influence the stakeholder's satisfaction; and (iii) the satisfaction of a stakeholder with the fulfillment of a requirement can be obtained from a questionnaire. In KM are identified four categories: • Must-be requirements: The stakeholder will be severely dissatisfied and not interested in the product at all if these basic requirements are not achieved. On the other hand, even if the features described by these requirements are implemented with full functionality, this will not increase the stakeholder's satisfaction as he/she gave them for granted.
• One-dimensional requirements: These requirements are also called performance or satisfier which shows that when the one-dimensional requirement is satisfied, the satisfaction degree of the stakeholder will be increased, and the insufficiency of it will cause dissatisfaction.
• Attractive requirements: If these requirements are absent, there is no feeling of dissatisfaction, because they have the greatest influence on how stakeholders will be with the achievement of a given requirement.
• Indifferent requirements: Whether these requirements present (or absent), does not affect the reaction of the stakeholder to the product.
The decision support for product design should be scored with respect to Kano's classification of requirements and designers must ensure that all the must-be requirements are satisfied. Note that Kano's categories will give valuable guidance in trade-off situations during the product development stage 36  coverage of all functional areas, which lead to improving understanding about converging or diverging aspects. Besides, we use another technique to interpret the KET matrix proposed in Reference 38 using the satisfaction and dissatisfaction coefficients. The coefficients indicate, in numerical terms, how strongly a requirement may influence satisfaction or, in case it is not fulfilled, stakeholders' dissatisfaction. The satisfaction and dissatisfaction coefficients as Better and Worse, respectively. By considering the total number of answers in each Kano category for a given requirement, the Better and Worse values can be calculated using the following formulas: Better coefficient after increase = (attractive quality + expected quality) / (attractive quality + expected quality + must-be quality + indifferent quality) The satisfaction and dissatisfaction coefficients provide better discrimination among requirements. The Better-Worse coefficient is used to measure the effect of a certain function in increasing satisfaction or reducing dislike. Better coefficient measures the satisfaction after some increase.
The value of Better is usually positive, representing that if a certain functional quality is present, the users' satisfaction will be improved. The larger the positive value is, the greater the effect of this quality in increasing the users' satisfaction, and the higher the increase rate will be. The worse coefficient is a measure of dissatisfaction after the reduction. The value of Worse is usually negative, representing that if a certain functional quality is absent, the users' satisfaction degree will lower. The larger the negative value, the greater its effect in lowering the satisfaction degree, and the faster the decrease rate will be. The Better and Worse values capture this difference. Thanks this solution is possible to get the relevance of each requirement to translate it into Goals and Objectives expected for the project.

Solution selection
After the requirements elicitation and prioritization stages, our methodology passes to the last step, the Solution Selection Process that permits to identify the technological solution that better satisfies the requirements. This step requires the definition of a Representation Model for describing technological solutions and comparing them against the requirements and their objectives, as resulted from the previous steps (2).
A Technological Solution is a collection of Components that are described in terms of their pertinence to a set of Features. Features are mapped to the project's Requirements, that is, the Background requirementsand Goals resulting from the MSHR requirement integration stage and can be compared to the requirements' Objectives to assess their fulfilment level. In this section, we present a formal definition of the elements in our representation model to make explicit the computational procedure we implement in selecting a solution. Multiple components are described by their pertinence levels for different features. Aggregating the components we obtain an overall representation of a technological solution. This way multiple solutions can be compared to the objective levels that emerged from the requirement gathering step. Thanks to an MCDA, we can analyze the different solutions assigning them relative importance based on the distance from the objective levels and among the pertinence level values observed for each feature. This way a final score can be assigned to each solution to rank them in a partial order the designer can use to select the best available solution.
We now proceed with defining the terms used in this procedure. The domain D can be in principle continuous or discrete, finite or infinite and can describe objective or subjective information. However, we typically have continuous values, in a range of validity, when measuring physical properties, such as for instance the power capacity of the batteries of a device. When a feature cannot be described in terms of objective values or it is too complex to be objectively measured, its assessment can relate to experts' opinions, using an agree-disagree scale for a series of statements. The scale S is a finite set of ordinal values that define the desired level of detail to be used in assessing a feature. A common approach is using Likert scales that range from 2 to 10 levels. Using two levels implies we simply assess the presence or absence of a feature. Using three levels we also consider the partial fulfillment of a feature. Using four or more levels

Example 2.
The feature Perceived ease of use, abbreviated PerUse, is part of the category Acceptance, its domain is expressed in terms of experts' agreement-disagreement with the sentence "this component increases the perceived ease of use" and mapped on a [0 − 5] scale using the following assignments: 0 to Not Applicable, 1 to "Strongly disagree," 2 to "Disagree," 3 to "Neither agree nor disagree," 4 to "Agree," 5 to "Strongly agree," and The capability of representing features is the first stage for evaluating technological solutions. We refer to feature assessment as the process of gathering information and knowledge, possibly from multiple and diverse sources, in order to assess how well the components of a technological solution realize each of the features of interest, or, conversely, how much a feature is pertinent to a component.
Definition 2 (Feature assessment and feature pertinence value). Let  be the universe of the objects to assess and  the universe of features that can be assessed. A Feature assessment a x,F i ∈  ×  expresses the pertinence of F i ∈  to a given object x ∈  with # S F i (a x,F i ) the value attributed to S F i as a result of the assessment. This value is referred as feature pertinence value and can also be denoted as f xi , assuming f xi ∈ S F i .

Definition 3 (Component)
. Let  be the universe of the objects to assess and let  n be the number of features in  . A Component is an object     The vector o should be unique for each project, even if it can change over time. The feature pertinence values in o and the objectives of the requirement specifications cannot be considered in one-to-one correspondence because multiple objectives may compete to a same feature. For this reason, the specification of o is essentially a manual task. We discuss this aspects in Section 3.3.1 with more details. Definition 6 (Solution selection). Given  = {w 1 , w 2 , … , w n }, a set of vectors w ∈  n , a Solution Selection is a function   →( ,≼) ∶  → ( , ≼).
Where (T, ≼) refers to the fact the vectors w i ∈  are arranged in a partial order according to the relation ≼. The relation ≼ is decided by a distance function (w, o) assessing the distance of a vector in  to the objective levels encoded in the vector o. Example 6. In a Smart Health project, three technological solutions T i , T j , and T l are proposed. We can then see them as a set of vectors  = {w i , w j , w l }. All vectors in  are compared in   →( ,≼) ( ) to produce a partially ordered set, let for instance assume  ≼ = {w l ≼ w j ≼ w i }.
Each technological solution can however be preferred to the others for different feature pertinence values. This means an overall evaluation of the partial order in  requires an MCDA. We discuss the approach followed in Section 4.3.

Mapping requirements to features
URs can be divided into two classes: "what the system must do" (as "I expect the system monitors my health status and my habits" and "I expect to receive notification and suggestions about correct behaviours") and "what qualities the system must have" (as "I expect the experience is attractive and engaging," "I expect the system is practical and easy to use"). Requirements belonging to the first category translate high-levels capabilities into actionable technical concepts providing a readable and understandable sense of how the system should operate to be used and adopted by the final end-users. Hence, they are crucial for driving the design of the architecture of the target system and the selection of its modules and components.
Moreover, tracing links between user requirements and the connected IoT devices and software features/functionalities in a Mapping Matrix allows covering all elicited needs and, at the same time, preventing redundancy in the devices and software platforms selection. URs may break into multiple system requirements: "I expect to share my periodic report with my clinician and/or with my caregiver depending on my consent," for instance, impacts on the intelligence of the system, its connectivity and, obviously, on privacy and security issues. Meanwhile, a technological aspect of the system can be affected by several URs with a different connection degree. A pulse oximeter among the device list because of the elicited "I expect the system monitors my oxygen saturation" UR could be equally justified by a more generic UR as "I expect the system helps me improving the management of my health condition." An enhanced management of a medical condition, indeed, assumes the existence of devices able to monitor physiological parameters valuable for a given pathology and to notify if something unexpected is occurring.

Example 7.
The requirements insisting on the subscription cost, feature F Sub , come directly from background requirements. The project is associated with a budget and this budget can be translated into an objective level, let assume o Sub = 2, without involving any co-design activity.

Example 8.
Multiple requirements insist on the perceived ease of use, feature F PerUse , and they must be translated into a objective level consistently.
In particular, requirements as "I expect that the system is practical," "I expect that the system is easy to use," "I expect that the system is non-invasive at home," and "I expect that the system is clinically relevant" describe goals that let the designers understanding the objective level the system has to fulfill in order to be accepted by users. Because however, in this specific case, the requirement gathering step did not provide a definition of precise objectives, the designers decide to assign to F PerUse a quite high objective level, let assume o PerUse = 4, as they know from previous projects that usability is relevant and this is confirmed by users' feedback.

Multi-criteria decision analysis
Design often involves making trade-offs among many different goals. When multiple design alternatives are available selecting the best trade-off is not trivial and designers can fail in satisfying one or more stakeholder groups. MCDA are practical methods to evaluate and choose among alternatives based on multiple criteria using systematic analysis that overcomes the limitations of unstructured decision making.
Given multiple technological solutions our procedure can compare them to the objective levels of the project. Thanks to our representation model, both terms can be seen as vectors, respectively w ∈ T and o. The MCDA we apply analyze the vectors and assign them relative importance based on the distance from the objective levels. This generates a normalized version of the vectors where each feature is weighted according to its overall relative importance. This way a final score can be assigned to each solution to rank them in a partial order the designer can use to select the best available solution.
Our MCDA uses a modified version of the preference selection index (PSI), proposed in Reference 39. This index requires minimal configuration as the designer does not have to assign a relative importance to features or to perform a sensitivity analysis. In fact, the index is calculated using a  ing any negative number equal to zero as any value equal or greater than the objective level has for us the same deviation. In formal terms, The relative importance of a feature is computed as the sum of each dpl ij : ri j = ∑ n i=1 dpl ij . 2 The overall relative importance defines the relevance of ri j comparing it with the ri of the other attributes: ori j = ri j ∑  n l=1 dpl l . 5. The relative feature pertinence level of a m ij is refereed f ri ij and calculate as the feature pertinence level multiplied by its overall relative importance. Formally, f ri ij = m ij × ori j . 6. Finally, the PSI is calculated for each solution using the following equation: PSI i = ∑ m j=1 f ri ij .
Given Table 1B, we get the following PSI values for the different alternative: PSI 1 = 0.89; PSI 2 = 0.78; PSI 3 = 0.82; PSI 4 = 0.5. The ranking of alternatives is then: We observe, in conclusion, that the PSI index is essentially calculated based on four aspects: (i) a relative representation of the pertinence levels, (ii) a deviation of these values from their related objective levels, (iii) the overall relative importance of each feature based on the deviation among the pertinence levels observed for the same feature, and (iv) a normalized value based on the relative importance obtained by other features in the comparison. 2 The PSI proposed in Reference 39 uses the inverse of the overall differences because It is assumed that high difference implies less relevance. This assumption is not compatible with our methodology where similar pertinence levels implies a similar fulfilment of the connected requirements.

METHODOLOGY ON THE FIELD: EXPERIMENTS AND DATA EVALUATION
In this section, the previously proposed methodology is tested to a real case study, more specifically to the European SMART BEAR project (https:// www.smart-bear.eu). 41 SMART BEAR Project aims to deliver an integrated technological solution that is easy to use and to maintain and that would enhance the elderly's independence. The project is organized in five national pilots, including a pilot based in Italy that we document in this work.
Specifically, the project focuses on monitoring the four major problems of an elderly person's life: (i) hearing loss (HL), (ii) cardiovascular disease (CVD), (iii) cognitive disorders (CI), and (iv) balance disorders (BD). Moreover, SMART BEAR is intended to leverage big data analytics and learning capabilities, allowing for large scale analysis of the collected data, to generate the evidence required for making decisions about personalized interventions. Starting from these main objectives, our proposal will be applied during the entire definition and modeling process of SMART BEAR project and we will show an end-to-end experiment starting from the requirements elicitation concluding with the modeling and device selection phase.
During this section, we will show only some significant excerpts of the entire elicitation and testing activities that we have put in place, for this reason, all the complete and detailed data of each phase are collected in one public repository (https://github.com/SESARLab/A-Design-Methodology-).

Clinical requirements: Data acquisition and results
The "Intrinsic capacity" model, introduced by the WHO, suggests considering elderly people's wellbeing as a whole rather than focusing on the person's pathologies. Aging is a process during which everyone's capacities tend to fade and individuals' functional abilities in interaction with the surroundings should be actually considered for a comprehensive characterization of seniors' QoL. To identify information to collect for a successful clinical requirements elicitation, preliminary informal interviews with experts (e.g., neuropsychologist, geriatrician, engineers, etc.) and domain analysis were performed taking into account WHO recommendations. Moreover, to ensure accurate, unbiased, and complete answers, the identified questions were organized into a significant order and both specialists with vertical expertise on at least one of the targeted medical conditions (e.g., cardiologist, psychologist) and geriatricians were encouraged to reply to the survey during focus group activities. An online questionnaire, with a reduced number of questions, was also prepared according to the same philosophy and procedure in order to gain a larger numbers-based knowledge about clinician's beliefs, attitudes, and expectations on the SMART BEAR home platform. The online questionnaire is time-effective and easy to fill in remotely and, therefore, it allows gathering information from a wide number of people in a short time and little cost. At the end of the activities with clinicians, the main features/functionalities of the proposed platform and preliminary URs were defined and clustered into three groups: (i) those related to the presence of devices (e.g., wearable sensors and smart devices), (ii) those related to the presence of mobile applications (e.g., software functions), and (iii) those related to the interaction with the platform (e.g., human-computer interaction). Scenarios able to cover all found insights were set up and lastly discussed in focus group activities with older people with the aim to confirm, adjust, and enrich the content of preliminary URs.

Methodological tools
The elicitation process of clinical requirements was organized as follows: • Clinician: focus group and online questionnaire.
The key aspects investigated by the surveys administered to the medical experts physically during focus groups and remotely through mailing lists were: -Use of technology in medical practice (three questions); -Concerns and expectations about an eventual usage of SMART BEAR home platform (five questions).
• Elderly: focus group through story telling.
A selection of metrics of Morville's user experience honeycomb 42 (i.e., the usefulness, the desirability, and the credibility) were investigated for every functionality presented into the five scenarios: -#1: it deals with the monitoring of physical wellness status (e.g., amount of physical inactivity, malnutrition, and weight loss/gains) with personalized plans and achievement of rewards once a goal is reached; -#2: it deals with the monitoring of vital signs (e.g., blood pressure, blood glucose levels) with personalized reminders about periodic measurements to do and notifications/alerts in case of unexpected trajectories of measures; -#3: it deals with the monitoring of emotional changes, non-compliance to medication scheme, sleep disturbances, and environmental conditions (e.g., house temperature) by the use of smart devices (e.g., sleep mat, home sensors); -#4: it deals with the monitoring of habitual substances usage (e.g., smoking, alcohol), social and family isolation with personalized suggestions, and psycho-educational content to improve the awareness about own behaviors; -#5: it deals with the management of HL (e.g., inadequate fitting of ear aids) and the remote communication with clinicians through SMART BEAR home platform.

Experimental procedure
Sixteen medical experts participated to two focus group activities led by a research team of the project (i.e., two bioengineers). More specifically, the first activity was held with 9 clinicians in a meeting room at Policlinico Ca' Granda, in Milan, while the remaining seven medical experts took part to the second appointment at the Hospital of Crema, in Crema. In both activities, researchers guided a collective discussion about the themes to clarify  Table 2).

• Clinician: Focus group and online questionnaire
The concept behind SMART BEAR has been well received by clinicians although their scarce use of technology most likely because of the well-known difficulties that older people experience with technology. Nonetheless, the majority of the interviewed physicians expressed their willingness to use a platform such as SMART BEAR during the medical practice thus confirming absence of a preconceived rejection towards technology from the clinicians' part. Actually, from an enhanced use of technology at hospitals and at patients' homes premises, physicians expect beneficial effects on: elderly (e.g., improved awareness, better self-management and higher QoL), clinical practice (e.g., early diagnosis and intervention) and health service (e.g., optimized outcomes and stronger cooperation of medical staff). A data-driven approach able to optimize the outcome and provide relevant information is very appreciated by clinicians as well as a closer communication among the members of the medical staff (e.g., nurses, physiotherapists, etc.) and a more trustful patient-clinician relationship.

• Elderly: Focus group through story telling
All functionalities presented into scenarios must be extremely tailored to the user according to the interviewed subjects over 65: programs, reminders, suggestions, notifications, and data sharing settings should be customized and adjustable at will, they pointed out. Furthermore, they agreed that continuous monitoring and informative content provided by the platform could be beneficial in order to improve their behaviors, lifestyles, management of medical condition, and overall QoL. Also, the possibility to share the data with clinicians and/or caregivers was particularly appreciated although they judged it burdensome especially for the physicians. Some concerns about the usability of the technology were then found. Advantages and difficulties of older people with the technology previously identified by clinicians were thereby confirmed. The proposed solution should be, therefore, able to overcome the seniors' difficulties by providing an interaction extremely easy and intuitive and, in that regard, a training session was considered helpful and highly recommended.
Based on data collected from clinicians and older subjects, a total number of 111 requirements (N=72 by clinicians and N=39 by elderly) were identified (see Appendix). Eight high-level business objectives (marked by "B") as "I expect that SMART BEAR reduces the number of unnecessary visits," "I expect that SMART BEAR reduces hospitalizations," and "I expect that SMART BEAR reduces health costs" have been also detected.

Technical requirements: data acquisition and results
The Kano model 35 was selected as the approach to be used for the elicitation of technical requirements. An initial list of requirements was brainstormed by the technical partners and assessed using the KQ. The questions must be understandable by the intended respondents, and, therefore, • Connectivity. It is a key point of smart health ecosystems as it defines how the data are transmitted from sensors to the hubs or to the platform and it influences m|any aspects of the system, such as power consumption, time sampling, and costs.
• User and clinical parameters. It describes the kind of the data are managed from the system, usually, this dimension includes two sub-dimensions: clinical parameters, that represent the state of the patient, for example, heartbeat, blood oxygenation, and so on, and the user parameters that shows the interaction between user and system.
• Acceptance. It models the ability of a component to effectively support the user experience and the technology of acceptance of patients and the clinicians. It also takes into account the invasiveness of the sensors and devices adopted, that is, the constraints they impose on the activities patients and clinicians usually performs.
• System customization. It describes the capabilities provided by the system to adapt itself to the preferences expressed by patients and clinicians, or to the contextual conditions a component of the system has to operate.
• Costs. This is a non-subjective category and not influenced by the interaction with the system. It takes into account the costs of implementing and managing a healthcare system. Usually, these costs are divided into two macro-areas, hardware, and software which in turn are subdivided into two types, one-off or subscription costs.
The above reported list is not intended to be exhaustive. In particular, relevant aspects such as security and privacy protection ones, considered essential in health information systems, have not been taken into account since the proposed methodology is intended to be applied to smart health ecosystems already compliant with the current regulations (i.e., GDPR).

Analysis of technical requirements
The lists of requirements that we prepared are evaluated by proposing a questionnaire to the entire group of technical experts of the SMART BEAR Once having combined the answers to the functional and dysfunctional questions in the KET evaluation, the classification of the individual requirements can be summarized using methodologies described in Section 3.2 to analyze the results of the KQ. Requirements are places in a two-dimensional space organized by the Better and Worse dimensions based on the Satisfaction and Dissatisfaction coefficients they obtained in the KQ and entering in one of the four quadrants of Figure 2.
In the first quadrant: the better coefficient is high, while the worse coefficient is low. Requirements falling into this quadrant indicate the users' satisfaction will not decline if the system does not realize them, but when these requirements are provided the users' satisfaction greatly improves.
The impact on the objective levels of the features connected to these requirements is to have high levels except if other requirements demand lower levels. In the second quadrant: both the better and the worse coefficients are low. Requirements falling into this quadrant indicate whether the system will realize them or not the users' satisfaction will not change. The users concern the least with these requirements. The impact on the objective levels of the features connected to these requirements is to not influence the levels to be set. In the third quadrant: the better coefficient is F I G U R E 2 Chart of worse-better for SMART BEAR home and SMART BEAR back-end low, while the worse coefficient is high. Requirements falling into this quadrant indicate that if the system will not realize them the users' satisfaction will not improve, but when not realized the users' satisfaction will decline significantly. Thus, the features falling into this quadrant are features that cannot be missed. The impact on the objective levels of the features connected to these requirements is to have high levels independently from the influence of other requirements. In the fourth quadrant: both the better and worse coefficient is high. Requirements falling into this quadrant indicate that when the system realizes them the users' satisfaction will increase, while if the function is not provided the users' satisfaction will decline. The impact on the objective levels of the features connected to these requirements is to have high levels but these values can be averaged with the values other requirements demand.
In the area Connectivity, we have, for example, requirements falling in the first quadrant related to the log capabilities of the systems that may significantly impact the monitoring capability of smart health ecosystems. In the first quadrant, we have requirements related to the adoption of an off-line firstapproach in the development of the mobile app of the smart health ecosystem, to ensures the system is able to provide a response to the user as well offline as it does online. In the third quadrant, we have requirements related to the adoption Bluetooth LE as it reduced power consumption while maintaining a similar communication range of other proximity protocols. In the area User and Clinical Parameters, we have requirements falling in the fourth quadrant related to the availability of software that can test of data quality the sensors collecting data in the smart home. In the area Acceptance, we have requirements falling in the fourth quadrant related to the battery capacity. In the first quadrant, we have the need for having an active helpline the uses can call to get remote but instant support on the interaction with the system. In the area System Customization, we have requirements falling in the fourth quadrant related to the relevance of setting notifications and recommendations in accordance with the user schedules and household. In the third quadrant, we have requirements related to the creation of three levels of notifications, namely, success-alert, warning-alert, and info-alert. In the third quadrant, we have requirements related to the need of providing a dashboard clinicians can use to generate statistical reports on the collected data.

Selection of the best technological solution
Given the results obtained by the elicitation process of clinical and technological requirements, we were able to compare the quality of four solutions we scratched based on different smart health platforms. In particular, we investigate three vendor-specific ecosystems such as: (i) Apple HealthKit, (ii) Google Fit, and (iii) Samsung Health and one open system named openHAB. In Table 3, we show the comparison of these platforms using the dimensions that emerged from the elicitation process described in Section 4.2.1. The cost dimension makes an exception, as it represents a Background Requirement not relating to the users' needs.
In terms of the MCDA method presented in Section 4.3, the analysis will be carried out using feature categories. Pertinence levels aggregated by category give less sparse vectors and improve the explainability of the PSI results as high numbers of features make the contribution of a single