Applying ISO - IEC 25010 On Mobile Personal Health Records
Applying ISO - IEC 25010 On Mobile Personal Health Records
Applying ISO - IEC 25010 On Mobile Personal Health Records
discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/274699048
CITATIONS READS
4 258
5 authors, including:
Some of the authors of this publication are also working on these related projects:
All content following this page was uploaded by Sofia Ouhbi on 09 October 2015.
The user has requested enhancement of the downloaded file. All in-text references underlined in blue are added to the original document
and are linked to publications on ResearchGate, letting you access and read them immediately.
Applying ISO/IEC 25010 on Mobile Personal Health Records
Sofia Ouhbi1 , Ali Idri1 , Jose Luis Fernandez-Aleman2 , Ambrosio Toval2 and Halima Benjelloun3
1 Software Project Management research team, ENSIAS, Mohammed V University, Rabat, Morocco
2 Department of Informatics and Systems, Faculty of Computer Science, University of Murcia, Murcia, Spain
3 Autonomic Nervous System research team, Faculty of Medicine, Mohammed V University, Rabat, Morocco
Keywords: Personal health records, Mobile applications, ISO/IEC 25010, Software quality
Abstract: Software product quality requirements reflect the stockholders needs in terms of quality. They play a central
role in the success of the system and the software product quality. This paper lists mobile personal health
record (mPHR) requirements extracted from literature and identifies the requirements which should be in-
cluded in the mPHR quality evaluation. Moreover, the ISO/IEC 25010 software product quality model is
used to present a checklist with which to calculate the influence of the mPHR requirements on software prod-
uct quality. Furthermore, the degrees of influence of mPHR requirements on software product quality are
calculated and analyzed. A set of recommendations for mPHRs developers and stakeholders is provided.
This section presents the general requirements for an An mPHR should contain a profile section which con-
mPHR that should be taken into consideration dur- tains the users personal information (PI). The users
ing the requirements elicitation phase. The follow- profile can be of great importance if s/he wishes to
ing requirements were extracted from several stud- share information with another party. The user pro-
ies on mPHRs and also from the evaluation of exist- file requirements should therefore cover the following
ing mPHRs in app repositories. The study by (Khar- data: PI1: full name, PI2: age, PI3: marital status,
razi et al., 2012) attempted to identify the data ele- PI4: insurance type, PI5: phone number, PI6: email
ments and application features implemented in cur- and PI7: address.
rent mPHRs in order to define the common com-
ponents of a typical mPHR. The paper by (Simon 2.3 Users physical body quantitative
and Seldon, 2012) has also presented some mPHR data
functionalities while discussing an exchange data
method for mPHRs. Some requirements were ex- The role of the mPHR is to help the user keep track of
tracted from a study concerning diabetics mPHR his/her physical body quantitative data (QD). The fol-
(Chang et al., 2010) and requirements for web-based lowing data should figure in any mPHR to help users
PHRs were also taken into consideration (Fernandez- with different kinds of health problems track their
Aleman et al., 2013). The general requirements for measurements: QD1: height, QD2: weight, QD3:
an mPHR were selected and gathered in six blocks: temperature, QD4: heart frequency, QD5: glucose
apps accessibility, users personal information, users and QD6: blood pressure.
physical body quantitative data, users health infor-
mation, users actions, and apps features. 2.4 Users health information
2.1 Apps accessibility The users medical record should contain some or all
of the following health information (HI): HI1: ill-
Apps accessibility (AA) refers to the availability of ness history. HI2: family illness history. HI3: blood
the mPHR for users either before or after installa- group. HI4: medication list. HI5: allergies. HI6:
tion in the users smartphone. AA1: OS type. This fertility. HI7: surgical procedures. HI8: social his-
requirement for the operating system (OS) type con- tory such as: alcoholism, drug addiction and tabag-
cerns the availability of the mPHR in app repositories. ism. HI9: immunizations. HI10: psychological dis-
Is it limited to a specific store? The well-known OS orders. HI11: emotional disorders.
types are: Android, iOS, Blackberry and Windows
Phone. AA2: OS version. This requirement is im- 2.5 Users actions
portant as regards the accessibility of the mPHR. An
agreement should be reached as to whether the app Different users actions (UA) should be specified in
will be accessible to a certain OS version or it should the requirements document. UA define the set of ac-
be available for all smartphones using the same OS. tions that the user can take while using the mPHR. It
AA3: cost. Is the mPHR free or does it cost money? should be specified whether the user can or cannot:
This requirement should be taken into consideration UA1: add information, UA2: remove information,
by stakeholders as free apps are more popular (Pet- UA3: modify information, UA4: be authenticated.
sas et al., 2013) but paid apps might have a more ad- An authentication method can be a login/ password
vanced set of functionalities (dHeureuse et al., 2012). or a two-factor authentication or biometric authentica-
AA4: target audience. This requirement should spec- tion, UA5: import data UA6: export data UA7: share
ify whether the mPHR targets a certain audience type, information and UA8: backup data.
2.6 Apps features ties are composed of function and quality properties.
Functional properties determine what the software
An apps features (AF) are the functionality of the is able to do, while quality properties determine how
app. Requirements for AF may contain: AF1: health well the software performs (ISO/IEC-25010, 2011).
advice. This could help the user to improve his/her
way of life. AF2: social media. AF3: images. AF4:
alarm system. Alarms can be set for medication in- 4 MPHR REQUIREMENTS
take time or appointments with doctors. AF5: notifi-
cation messages. Messages can be push notifications INFLUENCE ANALYSIS
or short message service SMS which are sent by an-
other party in order to notify the user. AF6: inter- This section presents the analysis process used to cal-
nationalization. Is the mPHR available in more than culate the influence of the mPHRs requirements de-
one language? International access is reflected by the fined in this study on software product quality, along
number of languages supported by the mPHR. AF7: with an illustration example. The analysis process is
usability guidance. This contains information that can based on that of (Idri et al., 2013) but was adapted to
help the user handle the app. This information should our needs in order to answer the following questions:
be clear and concise. AF8: emergency contact. In the Q1 Which mPHR requirements should be considered
case of an emergency, the user should have an easy ac- when evaluating mPHR quality?
cess to the phone numbers to be contacted. AF9: con- Q2 What influence do mPHR requirements have on
nection with EHR. EHR stands for Electronic Health software product quality?
Record. AF10: connection with labs. AF11: con-
nection with hospitals. AF12: connection with health In order to answer Q1, the mPHR requirements are
devices. AF13: connection with other PHRs. analyzed and SQR are identified by using the defi-
nition from ISO/IEC 25030. In order to answer Q2,
three steps are carried out in the analysis process:
Step 1 Analysis of the product quality charac-
3 ISO/IEC 25010 STANDARD teristics and sub-characteristics. The product qual-
ity model ISO/IEC 25010 was analyzed in order
The ISO/IEC 25010 quality model defines: (i) qual- to understand the meaning of each external sub-
ity in use, which is a measure of the overall quality characteristic. In order to obtain a better idea of the
of the system in its operational environment for spe- meaning of the mPHR SQR, the ISO/IEC 25023 stan-
cific users, for carrying out specific tasks, (ii) soft- dard should be used. However, the standard for the
ware product quality, which is composed of eight measurement of system and software product quality
characteristics that are further subdivided into sub- ISO/IEC 25023 is under development and the met-
characteristics that can be measured internally or ex- rics from the ISO/IEC 9126-2 external metric tech-
ternally: (1) external SQ addresses properties related nical report were therefore studied. All the compli-
to the execution of the software on computer hard- ance quality sub-characteristics were discarded owing
ware and the application of an OS, (2) internal SQ to the fact that conventions and compliance with reg-
addresses properties of the software product that are ulations are not relevant to this study.
typically available during the development. Internal Step 2 Checklist of mPHR requirements using
SQ has an impact on external SQ which again has an ISO/IEC 25010 software product quality model. The
impact on SQ in use (ISO/IEC-25010, 2011). Note potential influence of an mPHR requirement on an ex-
that the ISO/IEC 25010 standard has replaced the ternal sub-characteristic is checked. A software prod-
ISO/IEC 9126 standard in 2011. The ISO/IEC 25010 uct quality sub-characteristic is considered to be influ-
quality model differs somewhat from the ISO/IEC enced by a requirement if the variables used in the cal-
9126 quality model: security becomes a characteristic culation of the external metric are influenced by this
in ISO/IEC 25010 rather than a sub-characteristic for requirement. The unavailability of ISO/IEC 25023
functionality as it was in ISO/IEC 9126, compatibil- led us to use the external metrics defined in ISO/IEC
ity is added as a new characteristic in ISO/IEC 25010 9126-2. In the case of the new sub-characteristics of
and quality in use has five characteristics instead of ISO/IEC 25010, whose previous model did not pro-
the four characteristics of ISO/IEC 9126. vide external metrics, we analyzed the definitions pro-
The SQ measures defined in ISO/IEC 2502n are vided by ISO/IEC 25010 in order to estimate the in-
useful for formalizing stakeholder SQR. Software fluence of mPHR requirements on them.
product requirements are divided into inherent and as- Step 3 Calculation of degree of influence of mPHR
signed property requirements. The inherent proper- requirements on software product quality. Three de-
Requirements+Block Functional+Suitability Reliability Performance+Efficiency Operability Security Compatibility Maintainability Transferability
AA 0.50 0.00 0.00 0.06 0.20 0.06 0.03 0.44
PI 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
QD 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
HI 0.50 1.00 1.00 0.67 0.20 0.00 0.17 0.00
UA 1.00 1.00 1.00 0.67 0.30 0.17 0.02 0.04
AF 0.85 1.00 1.00 0.69 0.34 0.18 0.10 0.00
Performance Efficiency
Functional Suitability
Maintainability
Transferability
Compatibility
Operability
Reliability
Security
Appropriateness recognisability
Technical accessibility
Modification stability
mPHR Requirements
Resource-utilization
Non-repudiation
Appropriateness
Interoperability
Confidentiality
Fault tolerance
Accountability
Time-behavior
Recoverability
Replaceability
Attractiveness
Changeability
Analyzability
Co-existence
Installability
Authenticity
Adaptability
Learnability
Helpfulness
Availability
Reusability
Ease of use
Modularity
Portability
Testability
Accuracy
Integrity
AA1 x - - - - - - - - - - - - - - - - - - - - - - - - - - x x x
AA2 x - - - - - - - - - - - - - - - - - - x - - x - - - - x x x
AA3 x - - - - - - x - - - - - - - - - - - - - - - - - - - - - -
AA4 x - - - - - - x - - - - - x x - - - - - - - - - - - - - - -
AA5 x - - - - - - - - - - - - x x - - - - - - - - - - - - - - x
AA6 x - - - - - - - - - - - - x x - - - - - - - - - - - - - - x
PI1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
PI7 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
QD6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI1 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI2 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI4 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI5 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI6 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI7 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI8 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI9 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI10 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
HI11 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
UA1 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA2 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA3 x x x x x x x x - x - x x - - x - - - - - - - - - - - - - -
UA4 x x x x x x x x - x - x x x x x x x - - - - - - - - - - - -
UA5 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA6 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA7 x x x x x x x x - x - x x - - x - - - - x - - - - - - - - -
UA8 x x x x x x x x - x - x x - - x - - x - - - x - - - - x - -
AF1 x - x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF2 x x x x x x x x - x - x x x - - - - - - x x - - - - - - - -
AF3 x - x x x x x x - x - x x x - - - - - - - x - - - - - - - -
AF4 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF5 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF6 x x x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF7 x - x x x x x x x x x x x - - - - - - - - x - - - - - - - -
AF8 x - x x x x x x - x - x x - - - - - - - - x - - - - - - - -
AF9 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF10 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF11 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
AF12 x x x x x x x x - x - x x x x x x - - x x - - - - - - - - -
AF13 x x x x x x x x - x - x x x x x x - - - x - - - - - - - - -
5.00
0.67
0.80
0.80
0.80
0.80
0.80
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.20 0.17 0.20 0.17
1.00
3.00
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
0.67
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
2.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
1.00
0.17
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.00
AA1
AA2
AA3
AA4
AA5
AA6
PI1
PI2
PI3
PI4
PI5
PI6
PI7
QD1
QD2
QD3
QD4
QD5
QD6
HI1
HI2
HI3
HI4
HI5
HI6
HI7
HI8
HI9
HI10
HI11
UA1
UA2
UA3
UA4
UA5
UA6
UA7
UA8
AF1
AF2
AF3
AF4
AF5
AF6
AF7
AF8
AF9
AF10
AF11
AF12
AF13
Functional Suitability Reliability Performance Efficiency Operability Security Compatibility Maintainability Transferability
6.00
AF
5.00 AF
UA AF AF AF AF AF AF AF AF
4.00 UA AF
HI UA UA UA UA UA UA UA UA UA
AF
3.00 HI
HI UA
QD HI HI HI HI HI HI HI HI HI
2.00 QD
QD
PI QD QD QD QD QD QD QD QD QD
AF
AF
1.00 PI
PI
AF
AA UA PI PI PI PI PI PI PI PI UA UA AF PI
AF UA AA
AA AA AA AF UA UA AA AA
0.00 AF AF UA UA UA AA AA
ss
ce
ty
y
y
ity
y
y
ce
ss
ty
ty
ity
y
us
lit
lit
lit
lit
lit
io
es
ac
lit
lit
lit
lit
lit
lit
lit
lit
lit
ne
tio
io
ili
en
ne
ili
ili
i
gr
an
ic
ar
bi
bi
bi
bi
bi
v
en
bi
bi
bi
tia
bi
bi
bi
bi
i
at
ab
ur
of
te
ha
sib
ab
ab
ist
za
te
ul
nt
ra
za
lla
ea
ea
ul
er
ila
isa
na
ra
sta
sta
rta
di
tiv
ia
cc
us
en
In
se
pf
ex
ili
nt
pt
be
he
ve
ol
od
es
ng
ac
ly
sta
pu
pe
pr
va
ar
A
ac
gn
Po
Re
Te
el
Ea
fid
ut
da
ou
tt
n
o-
na
e-
co
cc
ut
pl
ha
ro
ro
Le
-re
A
In
tio
H
ttr
-
co
m
C
ul
A
A
la
on
cc
Re
ce
Re
A
pp
te
C
A
on
Ti
Fa
ca
re
A
ur
ca
In
C
A
ifi
N
ss
so
ni
od
ne
ch
Re
M
te
Te
ia
pr
ro
pp
A
the blocks have a low influence on Security. They holders and developers.
have a moderate influence on Operability except AA
which has a very low influence on this characteristic. 6.1 Principal findings
Figure 2 presents the degree of influence of the
mPHR requirements on the external characteristics.
All requirements have an influence on Functional The requirements listed in this study were extracted
suitability. Operability is influenced by 92% of from literature and from a compilation of existing
mPHR requirements, while 88% of the requirements mPHRs. Requirements such as Medication (HI4) and
affect Reliability and Performance efficiency. Secu- Allergies (HI5) exist in all the mPHRs evaluated by
rity and Maintainability are respectively influenced (Kharrazi et al., 2012) and the absence of these re-
by 69% and 63% of the mPHR requirements, while quirements may severely affect mPHR market pen-
Compatibility and Transferability are affected by only etration (Kharrazi et al., 2012). The mPHR require-
18% and 8% respectively. Figure 3 shows the de- ments identified were analyzed in order to select those
gree of influence of the blocks of mPHR require- that should be included in the evaluation of software
ments on the external sub-characteristic. This figure product quality. Software product quality is evaluated
provides a detailed view on the impact of mPHR re- by using SQR (ISO/IEC-25040, 2011). Apart from
quirements on each external characteristic by identi- requirements concerning cost and OS version in block
fying which of its components is concerned. The sub- AA, the other requirements can be translated to SQR
characteristic Appropriateness of Functional suitabil- by assigning a quality attribute that can have a target
ity is influenced by all the mPHR requirements. The measure to each requirement. The influence analysis
sub-characteristics of Reliability and Performance ef- results show that the requirements UA4, UA8, AF2,
ficiency are equally influenced by all the blocks ex- and AF9AF13 have a great influence on software
cept AA. Learnability and Helpfulness, which are product quality:
sub-characteristics of Operability, are influenced by Authentication (UA4) has a great influence on
only one mPHR requirement in block AF. The Se- mPHR software product quality. Information secu-
curity sub-characteristic that is most influenced by rity in mobile devices is a serious limitation and threat
mPHR requirements is Confidentiality. Compatibil- to the users personal data (Wasserman, 2010). Pro-
ity is mainly influenced through the sub-characteristic tecting users health information is one of the aspects
Interoperability. None of the mPHR requirements that may distinguish one mPHR from another. Var-
has influenced the following Maintainability sub- ious biometric authentication methods are being de-
characteristics: Analyzability, Changeability, Modifi- veloped for smartphones (Klonovs et al., 2013; Meng
cation stability, and Testability. Installability, which is et al., 2013), which may enhance the protection of
a sub-characteristic of Transferability, is moderately mPHR users personal medical records. The mPHR
influenced by block AA. user who is willing to back up his/her data (UA8)
is confronted with mobile limitations. Compared
with computers, smartphones have a limited memory,
which will limit their ability to store images and large
6 DISCUSSION data files (Wasserman, 2010). One solution to this is
the use of a cloud service, which can act as a stor-
This section summarizes the principal findings of this age mechanism and an intermediary for data transfer.
study and presents their implications for mPHR stake- However, an Internet connection is required, and the
user may once again confront some serious mobile interoperability with other parties. A cloud service
environment limitations such as frequent disconnec- can overcome problems of security in smartphones
tion and variable bandwidth (Peng, 2013). Moreover, and (Zonouz et al., 2013) has proposed a cloud-based
the study by (Ion et al., 2011) has shown that smart- comprehensive and lightweight security solution for
phone users do not trust the cloud as a data-storage smartphones.
environment and prefer to use home-based storage so-
lutions, such as storing data on their laptops. 6.2 Implications and advice for mPHR
Social media (AF2) usage highly influences stakeholders and developers
mPHR software product quality. Using social net-
works implies privacy and security issues, particu- This study provides a general view of mPHR require-
larly as regards sharing information related to health ments. It is up to stakeholders, developers and eval-
data. Despite the lack of privacy in social media, the uators to translate them to SQR. The mPHR SQR
mPHR users of social networks can obtain support can be used by those responsible for specifying and
and information from the social network community evaluating software product quality. Software prod-
which could help them to confront their health con- uct quality evaluation can be performed during or af-
dition (Fernandez-Aleman et al., 2013). Block AF ter the development process or acquisition process by
includes requirements for mPHR apps features that the developer organization, the acquirer organization
have a great influence on mPHR software product or an independent evaluator (ISO/IEC-25040, 2011).
quality, particularly requirements concerning mPHR The mPHR requirements for external software qual-
connections with other parties, such as EHR, labora- ity characteristics should be stated quantitatively in
tories and medical devices. According to (Al-Habsi the quality requirements specification using external
and Seldon, 2013), the lack of a standardized form of measures and then used as criteria when the mPHR
data exchange is one of the most common problems in is evaluated (ISO/IEC-25010, 2011). A checklist of
medical data exchange. (Al-Habsi and Seldon, 2013) mPHR requirements and their influence on software
have used free tools and open source software to de- product quality may be of great use to mPHR devel-
velop a communication module between mPHRs and opers. Stakeholders could formulate their mPHR re-
web-based PHRs. Their module uses a common mes- quirements by taking into consideration the sugges-
sage standard Continuity of Care Record (CCR), and tions made in this study.
message vocabulary standards.
The results also show that the external character- 6.3 Limitations
istics which are highly influenced by mPHR require-
ments are Reliability and Performance efficiency. A This study may have some limitations such as: (i)
previous study (Idri et al., 2013) has shown that Other mPHR requirements, which do not figure in
Reliability is influenced by frequent disconnection, our list, may have been relevant to this study. How-
variable bandwidth, and limited energy autonomy, ever, the mPHR requirements presented in this study
while Performance efficiency is influenced by lower were extracted from a large and relevant collection of
bandwidth and limited storage capacity. In the re- mPHR literature. (ii) The use of the definition of soft-
quirements elicitation phase, the mPHR requirements ware product quality characteristics rather than their
should be specified by taking into consideration these metrics. This limitation is owing to the fact that the
mobile environment limitations. Functional suit- ISO/IEC 25023 standard is unavailable since it is still
ability through Appropriateness, Operability through under development. The ISO/IEC 9126-2 technical
Ease of use, Attractiveness and Technical accessibil- report has therefore been used to alleviate this threat.
ity, and Security through Confidentiality are also in- These limitations may have slightly affected the re-
fluenced by the mPHR requirements. The Operability sults of our study. Nevertheless, we believe that our
characteristic in ISO/IEC 25010 refers to the Usabil- findings may be used in future works on mPHRs.
ity characteristic in ISO/IEC 9126 and was renamed
to avoid conflict with the definition of usability in
(ISO/IEC-25062, 2006). Operability may confront
the limited user interface of smartphones (Idri et al., 7 CONCLUSION and FUTURE
2013). The study by (Zapata et al., 2014) has ana- WORK
lyzed 24 mPHRs (Android and iOS only) and has con-
cluded that these mPHRs are not suitably structured This paper has extracted and analyzed 51 mPHR
in compliance with Android and iOS usability guide- requirements from literature. A list of mPHR require-
lines. Security is influenced by authentication and ments that should be included in the mPHR quality
evaluation is suggested. The ISO/IEC 25010 software Ion, I., Sachdeva, N., Kumaraguru, P., and Capkun, S.
product quality model has been applied to the mPHR (2011). Home is safer than the cloud!: privacy con-
requirements identified in this study. A checklist con- cerns for consumer cloud storage. In 7th Symposium
taining 30 external sub-characteristics has been pre- on Usable Privacy and Security, page 13. ACM.
sented to calculate the influence of mPHR require- ISO/IEC-25010 (2011). Systems and software engineer-
ing Systems and software Quality Requirements and
ments on software product quality. The degrees of Evaluation (SQuaRE) System and software quality
influence of mPHR requirements on a software prod- models.
uct are calculated and analyzed. The results of this ISO/IEC-25030 (2007). Software engineering Soft-
study have shown that some characteristics, through ware product Quality Requirements and Evaluation
certain sub-characteristics, are more influenced by the (SQuaRE) Quality requirements.
mPHR requirements than others, particularly, Func- ISO/IEC-25040 (2011). Systems and software engineer-
tional suitability, Reliability, Performance efficiency, ing Systems and software Quality Requirements and
Operability and Security characteristics. As future Evaluation (SQuaRE) Evaluation process.
work, we intend to use the results from this study ISO/IEC-25062 (2006). Software engineering Soft-
as a basis to carry out an empirical evaluation of an ware product Quality Requirements and Evaluation
mPHR. We intend also to express the disparity and (SQuaRE) Common Industry Format (CIF) for us-
ability test reports.
variability in the degree of influence of the various
ISO/IEC-9126-1 (2001). Software engineering Product
mPHR requirements. quality Part 1: Quality models.
Kharrazi, H., Chisholm, R., VanNasdale, D., and Thomp-
son, B. (2012). Mobile personal health records: An
ACKNOWLEDGEMENTS evaluation of features and functionality. International
Journal of Medical Informatics, 81(9):579593.
This research is part of the mPHR project in Morocco Klonovs, J., Petersen, C. K., Olesen, H., and Hammershoj,
A. (2013). ID proof on the go: Development of a
financed by the Ministry of High education and Sci-
mobile EEG-based biometric authentication system.
entific research in Morocco 2014-2016. IEEE Vehicular Technology Magazine, 8(1):8189.
Meng, Y., Wong, D. S., Schlegel, R., et al. (2013). Touch
gestures based biometric authentication scheme for
REFERENCES touchscreen mobile phones. In Information Security
and Cryptology, pages 331350. Springer.
Al-Habsi, A. A. A. and Seldon, H. L. (2013). A commu- Ouhbi, S., Idri, A., Fernandez-Aleman, J. L., and Toval, A.
nication module for mobile personal health record. In (2013). Software quality requirements: A systematic
IEEE 7th International Power Engineering and Opti- mapping study. In 20th Asia-Pacific Software Engi-
mization Conference, PEOCO, pages 727731. neering Conference, APSEC, pages 231238.
Chang, I.-C., Hsiao, S.-J., Hsu, H.-M., and Chen, T.-H. Peng, C. (2013). Cellular Network for Mobile Devices
(2010). Building mPHR to assist diabetics in self- and Applications: Infrastructure Limitations and So-
healthcare management. In 7th International Con- lutions. PhD thesis, University of California.
ference on Service Systems and Service Management, Petsas, T., Papadogiannakis, A., Polychronakis, M.,
ICSSSM, pages 15. Markatos, E. P., and Karagiannis, T. (2013). Rise of
dHeureuse, N., Huici, F., Arumaithurai, M., Ahmed, M., the planet of the apps: a systematic study of the mobile
Papagiannaki, K., and Niccolini, S. (2012). Whats app ecosystem. In Internet Measurement Conference,
app?: a wide-scale measurement study of smart phone IMC, pages 277290. ACM.
markets. ACM SIGMOBILE Mobile Computing and Simon, S. K. and Seldon, H. L. (2012). Personal health
Communications Review, 16(2):1627. records: Mobile biosensors and smartphones for de-
Dohan, M. S., Abouzahra, M., and Tan, J. (2014). Mobile veloping countries. Global Telehealth, 2012:125131.
personal health records: Research agenda for applica- Wasserman, A. I. (2010). Software engineering issues for
tions in global health. In 47th Hawaii International mobile application development. In FSE/SDP Work-
Conference on System Sciences, HICSS, pages 2576 shop on Future of Software Engineering Research,
2585. FoSER, pages 397400. ACM.
Fernandez-Aleman, J. L., Seva-Llor, C. L., Toval, A., Zapata, B. C., Ninirola, A. H., Idri, A., Fernandez-Aleman,
Ouhbi, S., and Fernandez-Luque, L. (2013). Free J. L., and Toval, A. (2014). Mobile PHRs compliance
web-based personal health records: An analysis of with Android and iOS usability guidelines. Journal of
functionality. Journal of Medical Systems, 37(6):1 Medical Systems, 38(8):116.
16. Zonouz, S., Houmansadr, A., Berthier, R., Borisov, N., and
Idri, A., Moumane, K., and Abran, A. (2013). On the use of Sanders, W. (2013). Secloud: A cloud-based compre-
software quality standard ISO/IEC 9126 in mobile en- hensive and lightweight security solution for smart-
vironments. In 20th Asia-Pacific Software Engineer- phones. Computers & Security, 37:215227.
ing Conference, volume 1 of APSEC, pages 18.