Entropy-Based Assessment of Nonfunctional Requirements in Axiomatic Design

The main information systems design techniques focus, almost exclusively, on the functional requirements of the system to be implemented. In its standard formulation, axiomatic design has such characteristics. However, in complex operational environments, this can lead to the identification of functionally valid solutions, but do not perfectly adhere to the system’s nonfunctional requirements. In specific operational contexts, particularly in information systems design, neglecting nonfunctional requirements has been identified as a major threat to projects, which can prevent their proper utilization throughout the design process. In this paper, we focus on nonfunctional requirements in axiomatic design, whose impact assessments can only be performed according to a heuristic basis, i.e., by expert judgment. However, the value assignment by experts can lead to a decisional indeterminacy or cognitive bias. To overcome these limitations, we propose the adoption of a methodological approach based on a reinterpretation of the information axiom of axiomatic design in terms of a multi-criteria decision problem. This approach allows the formal inclusion of nonfunctional requirements in the design process, which can be accomplished by setting them as evaluation attributes to achieve the robust design solution. In this paper, we propose an algorithm to evaluate alternative design solutions based on the information theory of entropy, which then comply with the nonfunctional requirements. We illustrate our approach by a case study, which implements the process of managing patients in home care and compare it with the mathematical-based analytic hierarchy process method proposed in the literature. According to our method, the robust solution is computed in just a single step saving significant computational cost with respect to the iterative-based analytic hierarchy process method. In this perspective, the proposed approach can support information systems designers in decision making as it allows to select the most suitable solution for the context in which it must operate.


I. INTRODUCTION
Axiomatic Design is a design methodology introduced in the 1970s in the field of industrial engineering [44], [45], and was later adopted in the field of information systems design. It is essentially based on the analysis and implementation of the functional requirements, which represent the tasks that the system must perform. Meanwhile, nonfunctional requirements represent how the system must operate. They are included in the design process, often, in a non-formal way [24], [43]. However, the wide range of The associate editor coordinating the review of this manuscript and approving it for publication was Dominik Strzalka .
technological solutions, has given rise to the need to integrate both functional and nonfunctional requirements in the design process [8], [50], in particular, in complex operating environments [14]. In this direction, for instance, Mabrok et al. in [24] propose the inclusion of nonfunctional requirements in the design process based on a formal reformulation of axiomatic design in terms of a matrix system (extended design matrix with nonfunctional requirements). They leverage an analytical hierarchy process (AHP) approach to determine the robust solution that best satisfies the nonfunctional requirements of the system. This paper, instead, aims to present an alternative approach to determine the robust solution. The resolution of the matrix system is VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ solved using a two-step process. The first step is to determine the admissible functional solutions. They consist of a finite set of solutions that satisfy the independence axiom. The second phase entails providing an ordering to this set of solutions, based on a formal evaluation of the nonfunctional requirements of the system. To this end, we propose a sorting approach based on the information theory of entropy, which allows us to evaluate the satisfiability of the identified solutions to the nonfunctional requirements. To accomplish this task, we need to redefine and reclassify functional and nonfunctional requirements from the user requirements of the system, which constitute the building blocks of the design. At this point, we refer to the standard version of axiomatic design as a design tool based on the top-down decomposition of only functional requirements. Successively, the same approach is used to include the nonfunctional requirements of the design. In this context, two critical points can be considered. The first point encompasses the possibility of encountering situations of decisional indeterminacy. The second critical point is derived from the fact that evaluation elements are based exclusively on subjective judgments. These critical situations are solved on the basis of comparison matrices [24], [48]. These matrices are structured in such a way that, the set of admissible solutions for axiomatic design, can be the subject of multiple attribute evaluation (Multiple Attribute Decision-making Methods [48]). To perform such an evaluation, it is necessary to associate a weight with each attribute or nonfunctional requirement. For this reason, there are two strategies in the software systems. The first one is to estimate the weight of a nonfunctional requirement using those reported in similar projects. In case of unavailability of similar projects, sources like International Software Benchmarking Standards Group (ISBSG), 1 which provides information for fixing coefficients, can be used [3], [23]. The second strategy is to derive the weight of nonfunctional requirements through a heuristic approach, i.e., the expert judgements.
In this paper, we adopt the second strategy and compute the weight of nonfunctional requirements using the entropy approach [42]. According to this approach, the weights of the nonfunctional requirements are associated with deviations of distributions of subjective judgement in different design solutions. The greater the evaluation differences between the solutions being compared, the greater the associated level of information entropy. A uniform distribution of judgments will correspond to a lesser importance of the corresponding evaluation criterion [48]. In this case, the judgments determine the selection of the robust design solution. In the extant literature, Tversky and Kahneman in [46], have shown that the assignment of these judgments is a complex task. Even experienced professionals experts can be misled by the assignment of incorrect ratings. To avoid such problems, in this paper, we use a comparison matrix structure modeled according to the analytic hierarchy process (AHP) approach introduced by Saaty [38]. It allows us to minimize the problems associated 1 www.isbsg.org with the so-called cognitive biases. This approach is demonstrated by a case study, which consists in implementing the process of managing patients in home care. It is used to better clarify the main idea and to demonstrate the feasibility of the proposed methodology in various sections of this paper. Furthermore, our information theoretic-based approach to assess the nonfunctional requirements is compared with the one proposed by Mabrok et al. in [24], which is based on the eigenvalue and eigenvectors calculations. As per the findings, according to our method the robust solution is computed in just a single step, thus saving significant computational cost with respect to the iterative-based analytic hierarchy process method. This work contributes to the growing interest in introducing the nonfunctional requirements in axiomatic design and helps to capture the properties and constraints according to which a system must operate.
To summarize, the main contribution of this paper is to provide an efficient methodological approach to select the most suitable design solution for a specific operational context. This is an extremely important problem in several realworld applications. In this era of digital transition, a system is evaluated not only with respect to the variety of functionality made available, but also in terms of, for example, social sustainability [12]. This means designing information systems that ensure privacy protection and promote social inclusion (i.e., usability of systems by people with special needs), etc. In any specific context, these aspects can only be integrated into a design process as nonfunctional requirements, whose evaluations can only be made on the basis of subjective judgments. As an example, in this paper, we consider as a case study the design of a telemedicine system to support patients in home care. In this context, the nonfunctional requirements (such as security, usability, privacy, etc.) to be provided are particularly critical. Our approach allows the inclusion of such aspects already in the early stages of design, in order to avoid costly subsequent adaptation [43]. Other possible real applications of this method, in general, concern the use of axiomatic design in operational contexts for which the nonfunctional requirements of the system to be designed are particularly relevant and pervasive. For example, this methodology can be used to design rational selection procedures in contracts and tenders for the acquisition of goods and services. In this case, the nonfunctional requirements become the technical evaluation parameters of the submitted bids, such as different access modalities to systems from elderly, disabled persons, visually impaired individuals, etc. A mechanism of this type enables accurate verification of the service levels allowing rapid intervention in the event of deviations, thus minimizing the occurrence of disputes.
The paper is structured as follows: in the next section the related work is given. In Section III, the user requirements in software systems are described and a case study is introduced. In Section IV, the axiomatic design methodology is described. In Section V, the robust solution selection is defined in terms of multiple attribute decisionmaking method. In Section VI, the entropy-based assessment approach to compute the robust solution is introduced, and in Section VII, it is compared with the iterative-based analytic hierarchy process method. Finally, in Section VIII and in Section IX, respectively, the discussion and conclusion are presented.

II. RELATED WORK
Axiomatic design originated from N. P. Suh's intuition of providing a matrix representation to design processes [44]. In this way, it was possible to identify properties, which are present in successful designs. These properties made it possible to define independence and information axioms (recalled in Section IV) and a series of related corollaries, which form the theoretical basis of axiomatic design [44]. These elements provide the tools to evaluate the available design solutions, based on algebraic considerations. An axiomatic design also allows the matrix representation of a system to be translated into modular diagrams (Module-Junction Structure diagram or Design flow diagram) [15], [45]. They are particularly useful for providing designers with an ensemble representation of complex systems, when they are composed of heterogeneous parts that interact with each other, such as mechanical components, electronic circuits and software modules. This methodology is particularly effective in extremely complex contexts, wherein it is necessary to resort to effective tools for coordination, monitoring and verification of the developments of individual components [15], [20]. Later, this methodology has been adopted also in the field of information systems design, owing to a strong compatibility with objectoriented programming techniques [14], [45]. In particular, many concepts specifically adopted in this type of programming area have a direct correspondence in terms of axiomatic design [14]. This has allowed axiomatic design to be used as a modeling tool for software systems with UML (Unified Modelling Languages). Indeed, axiomatic design representations can be translated in terms of UML diagrams [34]. In this perspective, axiomatic design and UML can be combined to define an optimized model of the system to be implemented [14], [45]. For this reason, Do and Suh, proposed a programming paradigm called Axiomatic Design of objectoriented Software Systems (ADo-oSS) [14] that combines the decomposition of axiomatic design functional requirements, with object-oriented programming.
In recent years, significant attention has been given to nonfunctional requirements because of their importance in systems and software engineering [9], [11], [16], [26]. In fact, the role of nonfunctional requirements has been extensively studied in software engineering literature [3], [6], [7], [11], [25], [43], [48]. In the context of information systems, axiomatic design has been adopted, for instance, for concept evaluation in conceptual design. In [13] concepts are evaluated in terms of information axiom to include requirements, criteria and constraints other than functional requirements. In [43], the formal roles of nonfunctional requirements' elicitation, definition, and verification in the early stages of an engineering design project are explored through a case study. The purpose of exploration is to capture conceptual design information to identify the nonfunctional requirements impact on other requirements while conducing design changes. Thus, the nonfunctional requirements are included in the modelling scheme. In [25], the authors present a meta-model, which complements the functional requirement dimension with the nonfunctional requirements as another dimension to be used in effort estimation approaches. The meta-model is deployed to extend the use of the COmmon Software Measurement International Consortium (COSMIC) [2] functional size measurement method to measure the size of the nonfunctional requirements. Unlike to the above mentioned works that propose, respectively, a methodology to evaluate concepts by applying the axiomatic design principles, to include nonfunctional requirements in the modelling scheme, and a metamodel to deal with the problem of quantitatively assessing the nonfunctional requirements, our method focuses on the problem of the selection of the design solution that best adheres to the nonfunctional requirements in the system.
In [24], Mabrok et al. propose the inclusion of nonfunctional requirements in the design process based on a formal reformulation of axiomatic design in terms of an extended design matrix with nonfunctional requirements. They leverage an analytical hierarchy process (AHP) approach to determine comparison matrices (essentially the value judgments assigned by experts on the basis of a fixed scale of values), and use an iterative method to calculate eigenvalue and eigenvectors to derive the robust solution that best satisfies the nonfunctional requirements of the system. Recently, in [5] the same computational method used by authors in [24] is adopted to calculate the robust solution, i.e., eigenvalue and eigenvectors of the system. However, they make use of fuzzy analytic hierarchy process to define comparison matrices. The main difference between these two works consists only in the values assigned to comparison matrices. In our work, we also use the analytic hierarchy process to assign values to comparison matrices, however, we assess the nonfunctional requirements by the notion of entropy to compute the robust solution that best satisfies the nonfunctional requirements of the system.
Note that, to the best of our knowledge, few proposals in the literature address the problem of evaluating nonfunctional requirements (e.g., security, privacy, interoperability) as their exploration has posed new challenges to be investigated in the field of information system design. Our approach is proposed in this direction and is compared with the existing ones.

III. USER REQUIREMENTS IN SOFTWARE SYSTEMS
Any design methodology needs well-defined user requirements (URs) [35] because they guide the implementation of any system. In this paper, we refer to the requirements provided by two international metrics associations, such as the International Function Point Users Group (IFPUG) [1], [19] and COSMIC [2]. They are classified as follows: • Functional Requirements (FRs)-They represent what the system must perform [35]. In general, software design methodologies are based on a detailed analysis of the functional requirements of the systems to be implemented.
• Nonfunctional requirements (NFRs)-They are important requirements in the design process because they define the performance for the design and determine the technical specifications of the product. They are features that are not directly reported in the representation of the system design obtained through functional decomposition [24], however, they must be taken into account by designers.
• Project requirements and constraints (PRCs)-they do not have a direct influence on project development [17]. Essentially, they concern coordination activities, training, and the level of experience of the resources employed in the project. Technical specifications establish evaluation measures for them as well, although international metrics associations have not yet introduced a specific ad hoc metric [18]. The above mentioned requirements have been introduced to distinguish the components of a system based on its functional and nonfunctional aspects [7], [18]. Such classification has been adopted as the ISO/IEC 19761 standard in 2003 [7].
For the sake of illustration, a case study is presented below that will be referred to as our running example in this paper.

A. CASE STUDY
Suppose an organization operating in the healthcare sector is planning to implement a telemedicine system. In order to define well the functions, scopes and constraints of the system, a series of interviews are conducted with healthcare professionals and patients. These interviews are reworked in terms of case stories [32], [33]. A case story is a representation in semi-structured language of how the system works. This methodological approach allows for the identification of system use cases. They describe the functional behavior of the system in UML language, as a scenario of the use cases. At the same time, however, the case stories make it possible to define the performances that the system must guarantee nonfunctional requirements. Finally, the choice of the party that will implement the system leads us to the definition of the PRCs that do not contribute to the sizing of the software system [10] and they are not discussed in this paper. Now, let's proceed with the description of the example case story.
Frank is a 70-year old patient suffering from chronic disease. He is a widower and not self-sufficient. Frank is followed by medical and nursing staff through a series of telemedicine technologies for the provision of various services, including television broadcasting carried out periodically to check the patient's health and psychological state. Different health and social care professionals are involved in his care pathway considering his psychophysical state such as cardiologist, diabetologist, dietician, social worker, psychologist. From a technical perspective, in addition to television, Frank can access a set of telemonitoring services of vital parameters (e.g. blood pressure, blood glucose, weight) both at home in a self-care mode and in other care facilities such as the pharmacy. Moreover, given the interdisciplinary nature of the case and the need for an organization that integrates the different aspects of Frank's care process, the components of the team regularly meet in a teleconsultation regime to seek advice and share impressions on the clinical case.
Although there is not yet a specific law concerning telemedicine in Italy, the most important national unitary reference for the implementation of telemedicine services and the use of such systems within the National Health Service is the Guidelines issued by the Ministry of Health [27]. The guidelines recognizes the following organizational models ( Figure 1) based on the actors involved and how telemedicine services are implemented. In particular, three actors are involved in the process: Patient (P), Medical Doctor (M) and Service Center (SC) which is responsible, if involved, for analysing, managing and organizing the data collected during the various telemedicine sessions. As highlighted in Figure 1, the Patient and the Doctor may interact with or without the support of a Service Center. Data may be produced either by the Patient in a selfcare mode or by a Medical Doctor who visits the patient in his home. Therefore, the service can be modelled as a structure between who produces the data (user) and who provides the telemedicine service (provider). In particular, there are two types of interactions: Patient-Physician in case of a televisit and Physician-Physician with or without the presence of the patient in case of a teleconsultation. In both cases, as reported above, the exchange of data among the user and the provider can be mediated by the presence of a service centre. The general scenario previously defined is modelled using the UML use case diagram, as illustrated in Figure 2. It includes two main use cases: 1) Perform the visit that can be generalized in: • Perform the home visit carried out by the Primary Care Physician in the patient's home; • Perform the remote visit carried out by the Specialist through a telemedicine service. This use case includes the Primary Care Physician in case he/she participates at the visit. 2) Monitoring vital parameters that includes three functionalities: • Collect vital parameters: carried out by the patient using a medical device; • Exchange vital parameters: where two professionals share data collected during the relevant visit. This process may or may not include the presence of the service centre; • Analyse vital parameters performed by a healthcare professional (either a primary care or specialist physician) during the provision of a visit. Below the functional and nonfunctional requirements are given.

1) FUNCTIONAL REQUIREMENTS
They represent what the system is required to perform. At this level of abstraction, the above two main use cases constitute the functional requirements of the system, i.e., Perform the visit and Monitoring vital parameters.

2) NONFUNCTIONAL REQUIREMENTS
The nonfunctional requirements make it possible to define the service levels that the system must guarantee. Among the different nonfunctional requirements that have to be met, we selected and focused the attention on the following in this study: 1) Security: the system must be built and configured in compliance with the general principles of protecting information security taking into account the so called CIA triad, i.e., Confidentiality, Integrity, Availability [4]: 1) Confidentiality, i.e. only authorised users must be able to access the necessary information; 2) Integrity, i.e. the information must be protected against alteration or damage to ensure their reliability and correctness; 3) Availability, i.e. information must be made available when needed and within a relevant context. 2) Usability: this requirement deals with how easy it is for an operator to make use of the system in particular in terms of: 1) the complexity of the interfaces relative to how operators can operate with them; 2) the ease of learning, and 3) the efficiencies with which operators can exploit the services provided by the system [6]. tem's ability to share information and services with other systems and organizations. In this study, in particular, the attention is directed to other databases and repositories such as the registries of Patients, Health Facilities, Health Staff. Moreover, semantic interoperability techniques must be adopted to facilitate the exchange of data from and to the different patient's records (i.e. national/regional/local Electronic Health Records, Hospital Information Systems) [31].

IV. AXIOMATIC DESIGN METHODOLOGY
The axiomatic design theory was developed by Suh [44], [45]. According to this theory, system design is characterized by a cross-mapping between essentially four domains described below and shown in Figure 3: • Customer domain: in which the customer is looking for several attributes in a system, process or product called Customer attributes (CAs) or User requirements (URs).
• Functional domain: In the functional domain, the CAs are mapped into functional requirements (FRs) and associated constraints (Cs). They are requirements that characterize the functional needs of the system, process or product in the functional domain.
• Physical domain: In this domain, the functional requirements are mapped into design parameters (DPs), which VOLUME 9, 2021 are the key physical variables, or other equivalents in the case of software design, characterising the design that determines the functional requirements.
• Process domain: It contains processes that can be characterized by process variables (PVs), which have a one-to-one relation with the Design Parameters (DPs). Note that the axiomatic design theory is based on two main axioms, which are: • The independence axiom: It consists of maintaining the independence of functional requirements, where functional requirements are defined as the minimum number of independent requirements that characterize the design goals.
• The information axiom: It provides a quantitative means of measuring the merits of a given design, which can be used to select the robust solution among those that satisfy the independence axiom. It is measured by I = log( A sr A cr ), where A sr is the System range that indicates what the system enables delivering, and A cr denotes the Common range or the common area between the design range and the system range (see Figure 4 borrowed from [44]). Essentially the information axiom allows the selection of the least complex project solution. According to this axiom the solution defined as robust is the one with the least information content, which is formalized as follows: where P = A cr A sr is the probability that the selected design solution satisfies the functional requirements.
The cross-domain mapping process shown in Figure 3 allows to decompose the functional requirements into elementary actions (e.g., in our case study they are: monitoring vital parameters, perform remote visits, etc.), associating each decomposed element with a specific solution, called a Design Parameter (DP) [45].
If DPs satisfy the independence axiom, the process ends. Otherwise, DPs are more refined and the test of whether DPs satisfy the independence axiom is performed again (zigzaging). Once the DPs are specified and if there is more than one design that satisfies the independence axiom, the information axiom is applied in order to select the robust one. This decomposition process can be replicated in another domain (Process Domain). In this case, each Design Parameter is associated with Process Variable (PV) that allows its implementation. It can be a software module or a specific routine [14], [45].
In this context, the strength of the axiomatic design is that the relationships between domains can be represented by matrices. Matrix algebra allows us to evaluate, strictly on a mathematical basis, the level of logical consistency (independence axiom) and the degree of the identified solution's complexity (information axiom) [45]. In particular, the mapping between Functional Domain and Physical Domain is represented in terms of three types of design matrices. The first type of matrices represents the case where the number of functional requirements and DPs is the same and the design matrices are diagonal (see Table 1) [44]. In this case, the axiom of independence holds. In fact, the elements of the matrices represent independence relationships, and the design matrices are referred to as uncoupled. The second type of design matrices, which satisfies the independence axiom, is triangular ones (see Table 2) by uniquely defining the behavior of a system. In axiomatic design, the corresponding design is called decoupled. The third type of design matrices, which does not satisfy the independence axiom, is called coupled (see Table 3). They define interdomain mappings in which mutual dependencies between the elements of the domains prevail. In this case, the functional requirements are mutually dependent and the corresponding design matrices are non-admissible.
As anticipated in the Introduction section, in the standard axiomatic design formulation, nonfunctional requirements are excluded in the mapping between domains. They are essentially considered as constraints (Cs) [45]. Alternatively, it is possible to reformulate the nonfunctional requirements in the design process as additional functional requirements. However, this choice can complicate the design, because if they are numerous they can excessively increase the level of complexity of the system. Therefore, this solution is limited to a few nonfunctional requirements, whose importance can be considered strategic for the project. From these considerations, we can conclude that the application of axiomatic design in its traditional form leads to the identification of design solutions that are valid from a functional point of view, but may be non-admissible when it comes to the totality of nonfunctional requirements envisaged by the project.

A. APPLICATION OF AXIOMATIC DESIGN TO CASE STUDY
Based on the case study introduced in Section III, we can provide an example of the application of axiomatic design. It is a top-down methodology [14], [45]. Therefore, from the two use cases already introduced in Section III, we can obtain via functional decomposition the lower level use cases. For example, the high-level functional requirement: ''Perform the visit'' can be decomposed into two lower-level functional requirements, i.e., ''Perform the home visit'' and ''Perform the remote visit''. They correspond to the second-level functional requirements of the system to be implemented, as they are shown in Figure 2.
This decomposition procedure also involves the identification of the corresponding design parameters (DPs). In the specific case of information systems, DPs can be defined as interactions (collaborations) between individual use cases. They represent the activation modes between use cases, thus facilitating the description of the main behavior of the system [34]. For instance, as shown in Table 4, DP 1 is defined as the interaction that is generated by FP 1 to provide patient vital parameters data. It is denominated ''Collaboration collect vital parameters'' and constitutes the modality of activation of FP 2 (i.e., Exchange vital parameters). Similarly, the other DPs can be defined in the system. Table 4 summarizes the nonfunctional requirements of the case study and the corresponding DPs.
As seen in this table, the reported functional requirements can give rise to several design aggregations, each of which corresponds to a specific design solution. To visualize these interactions, axiomatic design resorts to a matrix representation of the entire design artefact [45]. In fact, each solution can be represented through a square matrix, called design matrix, wherein the functional requirements and the mutual interactions (collaborations) [34] are reported along the rows and columns, respectively. However, as anticipated, only a part of the possible solutions is admissible from an axiomatic point of view. The independence axiom allows us to identify the solutions which are consistent from a logical point of view. They correspond to the design solutions which can be translated into diagonal (uncoupled) or triangular (decoupled) matrices [45]. For now, however, we neglect the application of the information axiom. We restrict ourselves to defining the set of admissible design solutions, denoted by S. Thus, based on this consideration, four admissible axiomatic design solutions are identified, as shown in Table 5. In particular, the first design solution (S 1 ) corresponds to a system which monitors the patient's vital parameters, but it is limited to alerting an urgent home visit or booking a specialist visit to be performed remotely. The second design solution (S 2 ) differs from the previous one (highlighted by red color), only in the fact that the home doctor can also activate the request for a specialist visit. In this case, the fundamental behaviour of the system can be summarized by the corresponding design matrix. The third design solution (S 3 ), which is the more complete one from a functional point of view, implies the presence of an evolved service center. This center not only allows 24-hour monitoring of the patient but also activates home visits (proximal visits) or remote specialist visits (highlighted by red color). It also provides the health workers, who are treating the patient, with all the health information related to him/her in real time. Therefore, it is possible to consult the entire health file and the historical trends of the monitored vital parameters. Moreover, the same system allows the doctor, who intervened at home, to book a specialist visit remotely. The fourth design solution (S 4 ) is a variant of the third one, in that the system does not allow the physician, who perform remote visits, to access the complete data in the patient's health record in real time. He can consult the information in the monitoring systems and converse with the patient and his caregivers.
The four design solutions shown in Table 5 consider only the functional aspects required by the system developer. However, it should also be noted that in this specific case study there is a situation of sequential coupling of functional requirements. It consists of the fact that the activation of the FR i+1 always depends on the previous FR i . This is a structural type feature of some systems, which cannot be removed because the behaviour of the system occurs as a predefined sequence of actions [45]. This means that, in our case study, we can never have uncoupled type matrices. However, according to the independence axiom, all four design matrices are decoupled and thus are admissible solutions.
From a functional point of view, the solution S 1 is the least complex with respect to the others, because it is the  one that most respects the information axiom introduced in [14], [45]. However, this evaluation is made without considering the nonfunctional requirements. Therefore, while the solution S 1 is the most robust from a functional point of view, it is not the most adequate when it comes to the nonfunctional requirements. For this reason, we must introduce a different approach to evaluation, so as to include the nonfunctional requirements in the design process.

B. NONFUNCTIONAL REQUIREMENTS INTEGRATION AS A REFORMULATION OF THE INFORMATION AXIOM
The inclusion of nonfunctional design requirements can occur as a reformulation of the information axiom. This axiom allows the selection of the design solution with the lowest level of information complexity among those available (see Eq. 1) [44] This is possible by measuring the level of information associated with each solution [14]. For this purpose, it is necessary to extend axiomatic design to consider the nonfunctional characteristics (i.e., nonfunctional requirements) of the design. As a first step, we need to identify the set S of functional solutions that satisfy the independence axiom. To this end, the classification of user requirements, described in Section III allows us to introduce a matrix, i.e., nonfunctional requirements relation matrix (see Table 6) as also shown in Figure 5, [36]. It provides an evaluation of functional solutions (S i , i = 1, . . . , n), with respect to each category of nonfunctional requirements. It reports along the rows the admissible axiomatic design solutions with respect to the information axiom. Along the columns, instead, the nonfunctional requirements foreseen by the technical specifications are reported. The elements a ij of the matrix represent the evaluation of the impact of the j-th NFR with respect to the design solution. Accordingly, the probability that the admissible solutions satisfy the functional requirements (see Eq. 1) has been replaced with their level of adherence to the nonfunctional requirements prescribed by the design. However, this still does not allow us to establish an order to the set of admissible solutions because the evaluation criteria could be conflicting [24]. Let us consider cases where the elements a ij of the relation matrix in Table 6 can take only the following three values (−1, 0, 1) as shown in Table 7.
In this table, the values are assigned according to the following interpretation: • a ij = −1, if the design solution S i violates the nonfunctional requirement jth, foreseen in the technical specification document; • a ij = 0, if the design solution S i is independent (or distinct) from the nonfunctional requirement jth; • a ij = 1 if the design solution S i complies with the nonfunctional requirement jth, foreseen by the technical specifications document. In this case, it is not possible to establish an ordering on the set S = {S 1 , S 2 , S 3 } of available axiomatic design solutions. The three solutions denote a conflicting evaluation of the nonfunctional requirements. Notably, we will obtain the same score for the three solutions if we adopt the simple sum of the ratings as the sorting criterion (see Eq. 2).
Therefore, the matrix in Table 7 presents a situation of decision indeterminacy [24], [48]. The solution to overcome such cases is discussed in the next section.

V. ROBUST SOLUTION SELECTION
The case of indeterminacy, mentioned in the previous section, can be overcome if the information axiom is reformulated in terms of multi-attribute evaluation based on Multiple Attribute Decision-making Methods [48]. This is possible by considering nonfunctional requirements as weighted attributes of the evaluation of admissible solutions. With these arrangements, the problem of including nonfunctional requirements in the axiomatic design process can be formalised with a new type of matrices, referred to as comparison matrices. They have the characteristic of reporting for each attribute, along with the specific weight or weighting coefficient, W j , as illustrated in Table 8. Therefore, the assignment of a specific weight to each attribute prevents the occurrence of decision indeterminacy.
Here, we proceed to contextualize the application of the extension of the information axiom. As anticipated in the Introduction section, the weighting coefficients W j can be computed in two ways in the field of software engineering. On the one hand, they can be estimated by making use of similar projects whose data is available. For this purpose, there are databases such as ISBSG [3], [23], which collect statistics of software projects for benchmarking purposes. On the other hand, if the project has characteristics that  are not very similar to others, either from a technological or functional point of view, a heuristic approach can be used. This later approach is based on the assignment of ratings by experts, which simplifies the process of determining weightings, allowing for greater adherence of the assessment to the specific operational context. Therefore, it is deemed appropriate to adopt a heuristic approach to evaluate the a ij elements by experts. It allows us to construct comparison matrices based on the expert judgments. For this purpose, for instance, a value scale in accordance with Table 9 can be used [38], [46].
In the 1970s, Tversky and Kahneman [21], [46] had demonstrated with a series of tests that even the attribution of value judgments by experts is not impervious of cognitive biases. These deductions challenged the very idea of rational decision maker. From this point on, decision theory scholars began to consider the possibility of including psychological aspects of human behaviour in decision making. They moved from a knowledge paradigm based on a concept of substantive rationality (rational decision maker), to the idea of procedural rationality [28]. This has meant recognizing the presence of irrational elements in the decision-making process, trying to mitigate them, through the definition of appropriate decisionmaking procedures. Based on these assumptions, Saaty introduced the analytic hierarchy process method (AHP) to the field of decision theory [38]. This approach suggests to construct comparison tables between alternative solutions according to the scale values shown in Table 9 (see Table 10).
In this case, the assignment of value judgments is made based on comparisons between predefined pairs of solutions (S i , S j ). This made it possible to provide a measurement, albeit in terms relative to pairwise comparisons, even to intangible entities that, as in our case, may be design solutions, whose evaluation may be strongly influenced by the psychological behavior of the decision maker [28]. Importantly, it has been shown that the human mind provides reliable judgments when comparing two solutions at a time [40]. On the contrary, the evaluation process leads to distortions, when one tries to assign a judgment without comparisons. Therefore, every element a ij of the matrix of Table 10 is the evaluation of the comparison of the solution S i with the solution S j for specific nonfunctional requirement. In practice, in order to set the values to be assigned to a ij , one must ask the question of how much more relevant is S i than S j . In this case, the value scale in Table 9 provides us with the evaluation metric.
It is noteworthy that the elements of the diagonal of the matrix in Table 10 are equal to 1, because the comparison is between identical solutions, i.e., they have equal importance. Instead, the element a ji is equal to the reciprocal of a ij , i.e., a ji = 1/a ij [46], which avoids the occurrence of mental traps. For example, if the element a ij in Table 10 has been evaluated 3, the automatic assignment 1/3 to the element a ji prevents us to assign an arbitrary judgment, which can be in a logical contradiction with the value assigned to a ij . At this point, we can apply the approach of entropy to the elements of the comparison matrix to calculate the weight of each solution S i , as expounded in the next section.

VI. ENTROPY-BASED ASSESSMENT
In this section, we present an extension to the axiomatic design theory framework to include the nonfunctional requirements into the design process. The proposed approach is based on the principles of maximum entropy, which is recalled below.
The (Shannon) entropy H of a discrete probability distribution p(x) is the non-negative function [42]: where X represents the set of instances. H reaches its maximum value at the uniform distribution over X , i.e., log|X |.
In statistics and information theory, a maximum entropy probability distribution refers to a probability distribution whose entropy is at least as great as that of all other members of a specified class of distributions. Let A be a n × m decision matrix shown below: Each element of the normalized matrix of A, for short A ij , is represented as follows: where denominator denotes the Euclidean norm or square norm, i = 1, . . . , n, and j = 1, . . . , m.
In this manner, A ij is a weight representing the impact of each nonfunctional requirement NFR. At this point, the problem becomes one of determining the weighting coefficients to be associated with the attributes. To this end, we apply the information theoretic concept of entropy to the distributions of values (A ij ).
The amount of information contained in Eq. 5 and associated with each a ij in Eq. 4 can be measured by the entropy given in Eq. 3 as follows A ij logA ij (6) where H(A i ) is the marginal 2 of each row i in matrix A (see Table 11). The greater H(A ij ), the more discordant values the distribution of evaluation elements of the j-th nonfunctional requirement. This implies that the related nonfunctional requirement has a higher weight than the others. Conversely, distributions of evaluation items with low variability will be associated with very low evaluation coefficients, close to 0.
To summarize, the higher H(A i ) the more important the solution S i for the decision-making problem under consideration [48]. Accordingly, the robust solution is given below.
The above procedure is formulated by the following algorithm called COMPUTATION ALGORITHM. This algorithm includes the ROW-WISE CALCULATION and OUTPUT RESULT parts, respectively (see Table 12). Essentially, the ROW-WISE CALCULATION part calculates the entropy of each element of the normalized comparison matrix (lines (1)- (7)) and provides the marginal for each row (line (8)). Whereas the OUTPUT RESULT finds the highest value or priority as the solution, and then the algorithm terminates (lines (12)-(16)).

A. APPLICATION OF ASSESSMENT METHOD TO CASE STUDY
In Table 13, the comparison matrices of nonfunctional requirements are shown. To illustrate our approach, let us consider the comparison matrix of the first non functional requirement, i.e., Security. As a first step, the comparison matrix is normalized according to Eq. 5 and shown as follows:   According to COMPUTATION ALGORITHM, in the case of our running example, the results of ROW-WISE CALCULATION are shown in Table 14 from the second up to the fifth column. In this table, the final results for solutions are illustrated in the last column. As can be observed, the third solution (in bold) achieves the highest priority among the other ones and therefore, it is the robust design solution.

VII. COMPARISON
In this section, our proposed approach to assess the nonfunctional requirements is compared with the one proposed by Mabrok et al. in [24]. In the latter, the authors uses the analytic hierarchy process (AHP) method developed by Saaty and Vargas [39], which is based on mathematics and psychology for analyzing decisions. The AHP method, mathematically speaking, can be considered as an eigenvalue problem. Put differently, given a comparison matrix of a nonfunctional requirement, by computing its maximum eigenvalue (λ), a corresponding eigenvector V shown below represents the priority vector or solution of the nonfunctional requirement: For the purpose of comparison, we apply the AHP to each comparison matrix of our case study shown in Table 13 and calculate the corresponding λ and V as shown in Table 15. In this table, as we observe, the third solution (see the last column) is the robust design solution as well, which is the same result obtained by our approach. In line with expectations, the AHP method adopted in [24] essentially is a mathematical method that exploits the techniques of eigenvalues and eigenvectors. These techniques are the linear algebra concepts and are used to compress data and to study difference equations and continuous dynamical systems. The techniques for finding eigenvalues and eigenvectors of a matrix essentially fall under the area of iterative methods [30]. These methods repeatedly refine approximations to the eigenvectors or eigenvalues and terminate whenever the approximations reach a suitable degree of accuracy. Whilst, in our work we leverage the information theoretic notion of entropy introduced by Shannon [42]. It is a mathematical theory of communication that gave the framework for optimally designing modern digital communication systems. Although the underlying approaches of both methods are different, however, we derive the same robust solution.
As a final remark, we emphasize that our approach is a more simple method with respect to AHP as it requires fewer computations and identifies the same robust solution. In fact, calculating the eigenvalue and Eigen vectors is an iterative process in AHP that is equivalent to finding the roots of a polynomial. Eigenvector calculation of a matrix is, in general, a fundamental problem of computing in various scenarios such as Web page ranking [29], image recognition [47], and solving differential equations in chemistry and physics fields. In the computing field, the dominant eigenvector corresponding to the largest eigenvalue of a N × N matrix can be calculated with a time complexity of O(kN 2 ), where N is the matrix size and k represents the number of iterations [22]. Meanwhile in our study, the entropy-based assessment is carried out with a time complexity O(N 2 ), thus saving k iterations of computations with respect to the AHP method. We ran both algorithms, implemented in C++, on an Intel with 8 GB of RAM, 2.00 GHz ×4 Intel Core i7 processor. The execution time of our approach is 0.02 seconds, while with the iterative-based AHP method it is 0.181 seconds. Consequently, by applying our approach we save 0.161 seconds compared to the iterative-based AHP method.
Overall, unlike the AHP approach which identifies the robust solution by applying an iterative-based approach, our method solves the same problem in one go, thus achieving a significant gain in computational cost.

VIII. DISCUSSION
In this paper, we proposed an approach based on the information entropy to include and assess nonfunctional requirements in axiomatic design. This approach is well suited to situations of uncertainty, where the impact of nonfunctional requirements on functionally admissible solutions can only be obtained by expert judgments. Essentially, they represent relative measures of the comparison of pairs of solutions, based on a predefined scale of values. In this way, as elucidated in Section V, for each nonfunctional requirement the corresponding comparison matrix minimizes the occurrence of cognitive biases. The proposed approach allows us to order the set of solutions based on the application of the concept of entropy to the comparison matrices obtained for each nonfunctional requirement. According to this mechanism the robust design solution is selected, comprising the design matrix with the highest level of adherence to the nonfunctional requirements, which is what the project envisions.
In this case, the inclusion of the nonfunctional requirements in the axiomatic design entails reformulating the information axiom, which corresponds to redefining the information content I (see Eq. 1) of an admissible solution based on the level of satisfaction of the same nonfunctional requirements. It is equivalent to replacing the probability (P) of satisfying the functional requirements of the system, as predicted by the axiomatic design in its standard version, with the extent to which the solutions adhere to the nonfunctional requirements. To better illustrate the main idea, the proposed approach is applied to a case study in which involves implementing the process of managing patients in home care. The results of this case study allow us to make some considerations.
In the standard axiomatic design formulation, as reiterated in Section IV, nonfunctional requirements are excluded in the mapping between domains. Nevertheless, axiomatic theory provides us with two ways to circumvent this limitation. The first one is to consider nonfunctional requirements as design constraints (Cs). In this case, the nonfunctional requirements play a role similar to that of control factors in Taguchi methods [37]. This is equivalent to saying that the designer can choose, during the design phase (off-line), the DPs that best satisfy the targets related to the nonfunctional requirements provided by the technical specifications. This approach, for example, is much more suitable for the design of mechanical systems, for which each nonfunctional requirement can be associated with a specific system component. Unfortunately, this strategy would be difficult to pursue in the field of information systems because the expected nonfunctional requirements could be numerous and could impact all functional requirements in the system.
In contrast, the other way provided by standard axiomatic design theory is to consider nonfunctional requirements as additional functional requirements. Unfortunately, even this strategy turns out to be vexatious. It runs the risk of complicating the system design, especially in projects with a substantial number of nonfunctional requirements. For this reason, we proposed to formally integrate the nonfunctional requirements within the design process, based on a reformulation of the information axiom. This was made possible by assuming nonfunctional requirements as sorting criteria for the set S of admissible functional solutions, in a logic of multi-attribute comparison. This allows to decouple the phase of identification of the admissible functional solutions, as regards the phase of selection of the solution more adherent to the nonfunctional requirements. This decoupling makes it possible to define the set S of the admissible solutions based on a limited number of functional requirements, and facilitates the solution identification process, reducing its complexity. However, at the same time it defines a mechanism for selecting the robust solution on a rigorous mathematical basis. Accordingly, the contribution of the designer's creativity is limited only to the identification of admissible solutions phase, while the use of information entropy makes it possible to rigorously order the admissible solutions concerning their degree of adherence to the nonfunctional requirements.
However, we must also note that this approach has a weaknesses in that it relies on the assignment of value judgments by experts. Thus, the final outcome is contingent on the reliability of the judgments made. For this reason, as presented in Section V, we made use of comparison matrices derived from the AHP methodology. It avoids the occurrence of situations of decision indeterminacy and mitigates the phenomenon of cognitive bias. On these conceptual bases, the adoption of the information entropy as a tool of comparison has proved to be an efficient choice from a computational point of view as well. In Section VII, we compared our proposed method with a similar methodology which utilises the AHP methodology [24] for using comparison matrices. However, the identification of the robust solution in [24] is based on an iterative approach, which differs from ours in that according to the theoretic information-based entropy, is computed only in a single step.
Theoretically, when designing an information system, some solutions can violate the independence axiom. This possibility becomes more evident at more detailed decompositional levels, where even functional independence can be neglected in favor of more interaction between different modules. However, the higher the level of mutual dependence between modules in the system, the greater the complexity of the system. This underscores the need to provide significant control mechanisms. Furthermore, comparative studies with Taguchi methods have shown that, for design solutions which respect the axiom of independence, the designer can identify specific DPs that reduce the incidence of the noise factor and adjust the control factors of the system appropriately [37], [49]. In fact, if a system comprises independent modules (uncoupled solution), the choice of the design parameters that should minimize the variability of the control factors can be done independently for each module of the system. Instead, in the case of a coupled system, the reciprocal interactions among the various modules complicate the operations of evaluation and selection of the DPs. Decoupled systems, on the other hand, somewhat represent a middle ground. They represent design configurations for which the execution of the previous module is preliminary to the activation of the next one [45]. In this case, the system can be schematized as a network of modules placed in series. This type of relationship still makes it possible to describe, in a linear form, the statistical behavior of the control factor in the system. Therefore, in this paper, we restricted the application of the proposed method to the set S of admissible solutions, i.e., to the only those solutions which respect the independence axiom.
As a final remark, we underline the fact that the proposed method can present situations of decision indeterminacy if the number of nonfunctional requirements tends to increase. This result is in agreement with the traditional formulation of axiomatic design, which predicts an increase in system complexity as the number of nonfunctional requirements increases, because there may be an alignment of the judgments attributed by experts on distributions of values that are very close. Consequently, it leads to the flattening of the weighting coefficients calculated in Table 14 to very close values, which effectively prevents the selection of the robust solution. This problem has already been resolved by Saaty and Vargas [39], who envisioned the grouping of nonfunctional requirements into homogeneous groups which share specific characteristics. According to this strategy, the nonfunctional requirements can be organized into a hierarchical network of groups, which allows designers to provide an overall view of the nonfunctional requirements. Therefore, the intrinsic characteristics of each group can be better highlighted, which can be considered in the value judgment assignments in the comparison matrices. A structured evaluation process enables the implementation of a ''rational procedure'', which, in turn, mitigates the non-rational effects of experts, as explicated in Section V. Furthermore, it avoids dispersion in the assignment of value judgments. The study of such cases is beyond the scope of this paper and will be further investigated in future works.

IX. CONCLUSION
In this paper, we presented an approach based on the information theoretic notion of entropy for assessing the nonfunctional requirements in axiomatic design, whose benefits can be summarized point-by-point as follows: • The process of identifying the nonfunctional requirements of a system to be designed is not a simple activity [43]. According to the mentioned work, in fact, there is a certain ambiguity in the distinction between the two categories of requirements. As anticipated in the Section VIII, this ambiguity is particularly relevant in the case of axiomatic design, and we need to distinguish clearly, and by specific design phase, which requirements are nonfunctional. For this reason, as discussed in Section III, the proposed approach adopted the classification rules prescribed by international organizations dealing with software metrics such as IFPUG [1] and COSMIC [2]. In this way, it is possible to make use of standard procedures to reclassify the functional and nonfunctional requirements of a system from the user requirements [17]- [19].
• The proposed approach is suitable for particularly complex situations, where the designer does not have perfect knowledge of the operating environment and cannot refer to similar experiences. In these cases, it is necessary to consider the nonfunctional aspects of the system from the earliest stages of the design, so as to avoid costly rework after the project is completed [43]. The proposed method combines the potential of axiomatic design to operate in particularly complex environments with multicriteria analysis that instead allows comparisons to be made on entities that cannot be measured on an objective basis. In this way, the independence axiom allows to identify a set of design solutions that conform to the functional requirements of the system, while the information axiom, as it has been reformulated, allows to select the robust solution, i.e., the one most adherent to the expected nonfunctional requirements.
• This study focused specifically on situations of decision indeterminacy and cognitive bias, which can occur when evaluations are made on the basis of attributions of subjective judgments. In particular, we adopted the technique of comparison matrices introduced by Saaty in AHP [38]. These techniques are evolving and involve different branches of human knowledge, ranging from cognitive psychology to game theory, from decision theory to software engineering [28], [41].
• Finally, the proposed approach allows us to order the set of solutions based on the application of the notion of entropy through comparison matrices obtained for each nonfunctional requirement. This approach computes the robust solution in a single step, thus saving a significant amount of computational operations. As future works, we plan to investigate two challenges. One is to address the problem of decision indeterminacy if the number of nonfunctional requirements tends to increase significantly. As anticipated in the Section VIII, nonfunctional requirements can be grouped into homogeneous groups which share specific characteristics. Intuitively, it stands to reason that they can be organized into a hierarchical network of groups in order to mitigate the non-rational effects of expert judgement, but this has to be proven theoretically and experimentally. The other is to improve the process of making judgments so as to continue to reduce the phenomenon of cognitive bias. The solution lies in defining a rational procedure for making value judgments. In the future, we plan to extend this assignment to different users of the information system based on a participatory process. It means to involve the key stakeholders (from designers to end-users) of operational contexts (e.g., digital health, banking, finance) in the process of value assignment to each subset or individual nonfunctional requirement. This is a daunting challenge because it involves establishing specific communication rules for each stakeholder group. But, at the same time, a well-structured participatory design process would give greater accuracy to the selection of the robust solution.