Skip to main content
SpringerLink
Log in

Catalog of invisibility correlations for UbiComp and IoT applications

  • Original Article
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

The advance of Ubiquitous Computing (UbiComp) and Internet of Things (IoT) brought a new set of Non-Functional Requirements (NFRs), especially related to Human-Computer Interaction (HCI). Invisibility is one of these NFRs and refers to either the merging of technology in the user environment or the decrease in the interaction workload. This new NFR may impact traditional ones (e.g., Usability), revealing positive correlations, when one NFR helps another, and negative correlations, when a procedure favors an NFR but creates difficulty for another one. Correlations between NFRs are usually stored in catalogs, which is a well-defined body of knowledge gathered from previous experience. Although Invisibility has been recently cataloged with development strategies, the literature still lacks catalogs with correlations for this NFR. Therefore, this work aims at capturing and cataloging invisibility correlations for UbiComp and IoT systems. To do that, we also propose to systematize the definition of correlations using the following well-defined research methods: Interview, Content Analysis and Questionnaire. As a result, we defined a catalog with 110 positive and negative correlations with 9 NFRs. We evaluated this correlation catalog using a controlled experiment to verify if it helps developers when they are making decisions about NFRs in UbiComp and IoT systems. Results indicated that the catalog improved the decisions made by the participants. Therefore, this well-defined body of knowledge is useful for supporting software engineers to select appropriate strategies that satisfy Invisibility and other NFRs related to user interaction.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6
Fig. 7
Fig. 8
Fig. 9
Fig. 10

Similar content being viewed by others

Notes

  1. Detailed description of this SIG can be found in our previous study [11].

  2. https://developers.google.com/identity/sign-in/android/.

  3. https://developers.facebook.com/products/account-creation.

  4. http://www.openiot.eu/.

  5. http://mqtt.org/.

  6. http://coap.technology/.

  7. GREatBus is a system in development as part of the project called Smart Bus Stop, accepted by the Institutional Program of Innovation Scholarships at Federal University of Ceará in Brazil.

  8. All materials used in the operation of this experiment can be seen at encurtador.com.br/hPVZ0.

References

  1. Andrade R, Carvalho R, de Araújo I, Oliveira K, Maia M (2017) What changes from ubiquitous computing to internet of things in interaction evaluation? In: International conference on distributed, ambient, and pervasive interactions. https://doi.org/10.1007/978-3-319-58697-7_1

  2. Andreopoulos B (2004) Satisficing the conflicting software qualities of maintainability and performance at the source code level. In: Workshop de Engenharia de Requisitos, pp 176–188. Citeseer

  3. Bardln L (2011) Análise de conteúdo. Almedina, 1st edn. ISBN: 978-8562938047

  4. Berander P, et al (2005) Software quality attributes and trade-offs. Blekinge Institute of Technology

  5. Bernardi L, Kamps J, Kiseleva J, Müller MJI (2015) The continuous cold start problem in e-commerce recommender systems. CoRR abs/1508.01177. URL http://arxiv.org/abs/1508.01177

  6. Boehm B (2015) Architecture-based quality attribute synergies and conflicts. In: Proceedings of the second international workshop on software architecture and metrics, pp 29–34. IEEE Press. https://doi.org/10.1109/SAM.2015.18

  7. Bornstein MH, Jager J, Putnick DL (2013) Sampling in developmental science: situations, shortcomings, solutions, and standards. Dev Rev 33(4):357–370. https://doi.org/10.1016/j.dr.2013.08.003

    Article  Google Scholar 

  8. Carvalho R, et al (2017) Evaluating an IoT application using software measures. In: International conference on distributed, ambient, and pervasive interactions. https://doi.org/10.1007/978-3-319-58697-7_2

  9. Carvalho RM, Andrade RM, Oliveira KM (2020) How developers believe invisibility impacts nfrs related to user interaction. In: 2020 IEEE 28th international requirements engineering conference (RE), pp 102–112. IEEE. https://doi.org/10.1109/RE48521.2020.00022

  10. Carvalho RM, Andrade RMC, Oliveira KM (2018) Towards a catalog of conflicts for HCI quality characteristics in UbiComp and IoT applications: process and first results. In: IEEE international conference on research challenges in information science. https://doi.org/10.1109/RCIS.2018.8406651

  11. Carvalho RM, Andrade RMC, Oliveira KM, Kolski C (2018) Catalog of invisibility requirements for ubicomp and IoT applications. In: International requirements engineering conference - RE, pp 88–99. IEEE. https://doi.org/10.1109/RE.2018.00019

  12. Carvalho RM, Andrade RMdC, de Oliveira KM (2018) AQUArIUM - A suite of software measures for HCI quality evaluation of ubiquitous mobile applications. J Syst Softw 136:101–136. https://doi.org/10.1016/j.jss.2017.11.022

    Article  Google Scholar 

  13. Charmaz K (2006) Constructing grounded theory: a practical guide through qualitative analysis. SAGE Publications Ltd. ISBN = 978-0761973539

  14. Cho JY, Lee EH (2014) Reducing confusion about grounded theory and qualitative content analysis: similarities and differences. Qualit Rep 19(32):1–20

    Google Scholar 

  15. Chung L, Nixon BA, Yu E, Mylopoulos J (2000) Non-functional requirements in software engineering, vol 5. Springer Science and Business Media, New York

    Book  Google Scholar 

  16. Costa CA, Yamin AC, Geyer CFR (2008) Toward a general software infrastructure for ubiquitous computing. IEEE Pervasive Comput 7(1):64–73. https://doi.org/10.1109/MPRV.2008.21

    Article  Google Scholar 

  17. Cysneiros LM (2007) Evaluating the effectiveness of using catalogues to elicit non-functional requirements. Workshop in Requirements Engineering

  18. Cysneiros LM, Werneck VM, Kushniruk A (2005) Reusable knowledge for satisficing usability requirements. https://doi.org/10.1109/RE.2005.60

  19. Egyed A, Grunbacher P (2004) Identifying requirements conflicts and cooperation: How quality attributes and automated traceability can help. IEEE Software. https://doi.org/10.1109/MS.2004.40

  20. Ghazi P, Glinz M (2018) An experimental comparison of two navigation techniques for requirements modeling tools. In: 2018 IEEE 26th international requirements engineering conference (RE), pp 240–250. IEEE. https://doi.org/10.1109/RE.2018.00032

  21. Gliem JA, Gliem RR (2003) Calculating, interpreting, and reporting cronbach’s alpha reliability coefficient for likert-type scales. Midwest research-to-practice conference in adult, continuing, and community ..

  22. Godau R et al (2004) Qualitative data analysis software: Maxqda and maxdictio. Qual Res J 4(1):66

    Google Scholar 

  23. Hsieh HF, Shannon SE (2005) Three approaches to qualitative content analysis. Qual Health Res 15(9):1277–1288

    Article  Google Scholar 

  24. Hu H, Zhang T, Tan Y, Xiang H, Fu C, Feng Y (2015) Semantic modelling and automated reasoning of non-functional requirement conflicts in the context of softgoal interdependencies 9:145–156. https://doi.org/10.1049/iet-sen.2014.0153

  25. ISO/IEC 25010 (2011) ISO/IEC 25010. Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models

  26. Jamieson S (2004) Likert scales: how to (ab) use them. Med Educ 38(12):1217–1218. https://doi.org/10.1111/j.1365-2929.2004.02012.x

    Article  Google Scholar 

  27. Karvonen H, Kujala T (2014) Designing and evaluating ubicomp characteristics of intelligent in-car systems. In: 5 International conference on applied human factors and ergonomics, July, pp 1726–1737

  28. Leite JCSdP, Cappelli C (2010) Software transparency. Bus Inf Syst Eng 2(3):127–139

    Article  Google Scholar 

  29. Maia MEF, Fonteles A, Neto B, Gadelha R, Viana W, Andrade RMC (2013) LOCCAM - loosely coupled context acquisition middleware. In: Proceedings of the 28 annual ACM symposium on applied computing, pp 534–541. https://doi.org/10.1145/2480362.2480465

  30. Mairiza D, Zowghi D (2011) Constructing a catalogue of conflicts among non-functional requirements. Commun Comput Inf Sci. https://doi.org/10.1007/978-3-642-23391-33

  31. Mairiza D, Zowghi D, Gervasi V (2013) Conflict characterization and analysis of non-functional requirements: an experimental approach. In: International conference on intelligent software methodologies, tools and techniques. IEEE. https://doi.org/10.1109/SoMeT.2013.6645645

  32. Mairiza D, Zowghi D, Nurmuliani N (2009) Managing conflicts among non-functional requirements. In: Australian workshop on requirements engineering. University of Technology, Sydney

  33. Mairiza D, Zowghi D, Nurmuliani N (2010) Towards a catalogue of conflicts among non-functional requirements. In: International conference on evaluation of novel approaches to software engineering. SciTePress

  34. Mehta R, Wang H, Chung L (2012) Dealing with NFRs for smart-phone applications: a goal-oriented approach. In: Software engineering research, management and applications. https://doi.org/10.1007/978-3-642-30460-6_8

  35. Oates BJ (2005) Researching information systems and computing. Sage

  36. Oh J, Lee U, Lee K (2019) Usability evaluation model for biometric system considering privacy concern based on mcdm model. Security and Communication Networks 2019. https://doi.org/10.1155/2019/8715264

  37. Peixoto MM, Silva C (2018) Specifying privacy requirements with goal-oriented modeling languages. In: Proceedings of the XXXII Brazilian symposium on software engineering, pp 112–121. ACM. https://doi.org/10.1145/3266237.3266270

  38. Sadana V, Liu XF (2007) Analysis of conflicts among non-functional requirements using integrated analysis of functional and non-functional requirements (Compsac), 0–3

  39. Saha D, Mukherjee A (2003) Pervasive computing: a paradigm for the 21 century. IEEE Comput Soc 36(3):25–31. https://doi.org/10.1109/MC.2003.1185214

    Article  Google Scholar 

  40. Santos IS, Andrade RM, Neto PAS (2015) Templates for textual use cases of software product lines: results from a systematic mapping study and a controlled experiment. J Softw Eng Res Dev

  41. Satyanarayanan M (2001) Pervasive computing: vision and challenges. IEEE Personal Communications. https://doi.org/10.1109/98.943998

  42. Scholtz J, Consolvo S (2004) Toward a framework for evaluating ubiquitous computing applications. IEEE Pervasive Comput 3(2):82–88. https://doi.org/10.1109/MPRV.2004.1316826

    Article  Google Scholar 

  43. Sokolova M, Lapalme G (2009) A systematic analysis of performance measures for classification tasks. Inf Process Manage 45(4):427–437

    Article  Google Scholar 

  44. Torres RC, Martins LEG (2014) NFR catalogues for RFID middleware. J Comput Sci Technol 14(2):102–108

    Google Scholar 

  45. Vasseur JP, Dunkels A (2010) Interconnecting smart objects with IP. Morgan Kaufmann. https://doi.org/10.1016/B978-0-12-375165-2.00001-6

  46. Veleda R, Cysneiros LM (2019) Towards an ontology-based approach for eliciting possible solutions to non-functional requirements. In: International conference on advanced information systems engineering, pp 145–161. Springer

  47. Weiser M (1991) The Computer for the 21th Century. Scientific America special issue on communications, computers and networks, pp 94–104. https://doi.org/10.1145/329124.329126

  48. Whitmore A, Agarwal A, Da Xu L (2015) The internet of things–a survey of topics and trends. Inf Syst Front 17(2):261–274

    Article  Google Scholar 

  49. Wiegers K, Beatty J (2013) Software requirements. Pearson Education

  50. Wijayarathna C, Arachchilage NA (2019) An empirical usability analysis of the google authentication API. In: Proceedings of the evaluation and assessment on software engineering, pp 268–274. ACM. https://doi.org/10.1145/3319008.3319350

  51. Wohlin C, Runeson P, Höst M, Ohlsson MC, Regnell B, Wesslén A (2012) Experimentation in software engineering. Springer Science and Business Media, New York

    Book  Google Scholar 

  52. Zinovatna O, Cysneiros LM (2015) Reusing knowledge on delivering privacy and transparency together. In: 2015 IEEE fifth international workshop on requirements patterns (RePa), pp 17–24. IEEE. https://doi.org/10.1109/RePa.2015.7407733

Download references

Acknowledgements

We thank CNPQ for the Productivity Scholarship of Rossana Maria de Castro Andrade DT-2 (No. 315543/2018—3).

Author information

Authors and Affiliations

  1. Computer Science Department (DC), Group of Computer Networks, Software Engineering and Systems (GREat), Federal University of Ceará, Fortaleza, Brazil

    Rainara Maia Carvalho & Rossana Maria de Castro Andrade

  2. Laboratory of Industrial and Human Automation Control Mechanical Engineering and Computer Science - LAMIH UMR CNRS 8201, Université Polytechnique Hauts-de-France, Valenciennes, France

    Káthia Marçal de Oliveira

Authors
  1. Rainara Maia Carvalho
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Rossana Maria de Castro Andrade
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Káthia Marçal de Oliveira
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Rainara Maia Carvalho.

Additional information

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Appendices

Appendices

A Interview to define the catalog: profile of the developers

Figure 11 presents the years of experience of each developer regarding each domain area of expertise. We consider their experience in the development of applications for ubiquitous computing, Internet of Things (IoT), wireless sensor networks (WSN), and embedded systems.

Fig. 11
figure 11

Years of Experience and Background of the Developers

Full size image

B Results of the analysis to define the correlations

Table 15 presents all quantitative results from developers. Table 16 shows the distribution of the codifications among the NFR or its subcharacteristic.Table 17 presents softgoals of each NFR.

Table 15 Developers’ quantitative answers
Full size table
Table 16 Quantity of codifications by NFR
Full size table
Table 17 Softgoals of each NFR or subcharacteristic
Full size table

C Tasks and objects of the experiment

1.1 C.1 Object 1: AutomaGREat

AutomaGREat proposes an intelligent environment for the Seminar Room of the GREat lab. In the seminar room, lectures, weekly meetings, defenses and other activities happen. Several objects in this room are handled by the group employees who are using the room, such as air conditioners and lights. In this scenario, a development team proposed the AutomaGreat project, in which the goal is to create an application to facilitate the use of room devices: air conditioners and lamps. Thus, users can manipulate these objects remotely through a mobile application. In addition, the system can automate tasks commonly performed in this environment.

1.1.1 C.1.1 Functional requirements

The functional requirements of this application are:

  1. 1.

    The system must allow user authentication

  2. 2.

    The system should allow the user to set their preferences regarding air conditioning and lights

  3. 3.

    The system must allow the user to configure the system operation mode: manual or automatic

  4. 4.

    Manual mode should allow air and light control directly by the user.

    1. (a)

      The system must allow the user to turn on the seminar room air conditioner

    2. (b)

      The system must allow the user to turn off the seminar room air conditioner

    3. (c)

      The system must allow the user to change the seminar room air conditioner temperature

    4. (d)

      The system must allow the user to turn on the seminar room lights

    5. (e)

      The system shall allow the user to turn off seminar room lights

    6. (f)

      The system shall allow the brightness of the seminar room to be manipulated

    7. (g)

      The system must allow the color of the seminar room lights to be changed

  5. 5.

    Automatic mode should allow air conditioners and lamps to be triggered from room presence detection and user preferences

1.1.2 C.1.2 Non-functional requirements

The non-functional requirements of this application are:

  1. 1.

    Invisibility: refers to merging technology into the user’s physical environment or decreasing the interaction workload;

  2. 2.

    Security: degree to which a product or system protects information and data so that people or other products or systems have the degree of access to data appropriate to their types and levels of authorization;

  3. 3.

    Performance: performance against the amount of resources used under established conditions;

  4. 4.

    Interaction efficiency: resources spent on the accuracy and completeness with which users reach goals; and

  5. 5.

    Reliability: degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.

1.1.3 C.1.3 Softgoal interdependency graph (SIG) for AutomaGREat system

Figure 12 presents the SIG model for AutomaGREat System, received by the participants.

Fig. 12
figure 12

AutomaGREat SIG

Full size image

The description of the operationalizing softgoals in the last level of the AutomaGREat SIG is presented as follows.

  1. 1.

    Google Sign-in API: API that allows authentication with Google data;

  2. 2.

    Facial Recognition: Technique to identify the user based on their face;

  3. 3.

    Iris Recognition: Technique to identify the user based on their iris;

  4. 4.

    LoCCAM: Middleware for managing and acquiring context information. It can run on a single device or can be distributed across devices;

  5. 5.

    OpenIoT: A natural extension for cloud computing implementations, allowing access to IoT-based features, and functions as sensor middleware;

  6. 6.

    If-then-else: Modeling and implementation of adaptation decisions;

  7. 7.

    Ontology: Generic, formal and explicit way to capture and specify domain knowledge with its intrinsic semantics through consensual terminology and formal axioms and constraints. Provide a formal way of representing sensor data, context, and situations in well-structured terminology;

  8. 8.

    SVM algorithm: Supervised learning model that analyzes data used for classification and regression analysis.

  9. 9.

    Action: Execution of the decision

  10. 10.

    Embedded hardware: Acting and sensing-specific embedded hardware on objects;

  11. 11.

    Arduino: Open source electronic platform based on hardware and software;

  12. 12.

    Raspberry: Small-size single card that plugs into a computer monitor or TV and uses a standard keyboard and mouse; and

  13. 13.

    Beaglebone: Low-power open source single board computer.

1.1.4 C.1.4 Tasks

Tasks performed by the participants in AutomaGREat:

  • Task 1: Given the set of operationalizations in the last level of the Invisibility SIG, analyze if they have positive and negative impacts with Security, Performance, Efficiency and Reliability.

  • Task 2: Choose and describe the operationalizations that maximize the positive impact and minimize the negative impact to the required NFRs.

1.2 C.2 Object 2: GREatBus

GREatBus proposes an intelligent system for passengers and bus drivers. Overall, the project aims to facilitate bus-related tasks. For the driver, it is important for example to know if the people who are at the stop will take the bus. For the passenger it is important to know estimates, bus capacity, among others.

1.2.1 C.21. Functional requirements

The functional requirements of this application are:

  1. 1.

    The system must be able to receive or request information about the number of bus requests per stop;

  2. 2.

    The system shall be able to calculate the estimated bus arrival time based on the distance from the bus to the user and the speed of the vehicle;

  3. 3.

    The system must be able to inform the capacity of the bus; and

  4. 4.

    The system must be able to indicate that at that location there is a passenger requesting the bus.

1.2.2 C.2.2 Non-functional requirements

The non-functional requirements of this application are:

  1. 1.

    Invisibility: refers to merging technology into the user’s physical environment or decreasing the interaction workload.

  2. 2.

    Privacy: the state or condition of being free to be observed or disturbed.

  3. 3.

    Accessibility: the degree to which a product or system can be used by people with the widest range of features and capabilities to achieve a specified goal in a specified context of use.

1.2.3 C.2.3. Softgoal interdependency graph for GREatBus system

Figure 13 presents the SIG model for AutomaGREat System, received by the participants.

Fig. 13
figure 13

GREatBus SIG

Full size image

The description of the operationalizing softgoals in the last level of the GREatBus SIG is presented as follows.

  1. 1.

    Facebook Log-in API: API that allows authentication with Facebook data;

  2. 2.

    Facial Recognition: Technique to identify the user based on their face;

  3. 3.

    Iris Recognition: Technique to identify the user based on their iris;

  4. 4.

    IoTivity: Open source framework that enables device to device connectivity to meet emerging IoT needs;

  5. 5.

    First order logic: Mathematical logic used to specify system states and operators/functions to apply to those states. They provide reasoning support to identify complex contexts and situations;

  6. 6.

    Neural Network: Technique that presents a mathematical model inspired by the neural structure of intelligent organisms that gain knowledge through experience;

  7. 7.

    MQTT: Machine-to-machine (M2M) / “IoT” connectivity protocol. Designed as a publish/subscribe message transport.

  8. 8.

    Embedded hardware: Acting and sensing specific embedded hardware on objects;

  9. 9.

    Arduino: Open source electronic platform based on hardware and software;

  10. 10.

    Place objects discreetly: If hardware devices cannot be fully hidden, they must be discreetly placed in the physical area. Therefore, places where the user does not need to perform actions such as wall and roof corners are ideal.

1.2.4 C.2.4 Tasks

Tasks performed by the participants in GREatBus:

  • Task 1: Given the set of operationalizations in the last level of the Invisibility SIG, analyze if they have positive and negative impact with Privacy and Accessibility.

  • Task 2: Choose and describe the operationalizations that maximize the positive impact and minimize the negative impact to the required NFRs.

D Raw data of the experiment

Tables 18 and 19 present raw data of RQ1 and RQ2.

Table 18 Raw data to answer RQ1
Full size table
Table 19 Raw data to answer RQ2
Full size table

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Carvalho, R.M., Andrade, R.M.d. & de Oliveira, K.M. Catalog of invisibility correlations for UbiComp and IoT applications. Requirements Eng 27, 317–350 (2022). https://doi.org/10.1007/s00766-021-00364-2

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-021-00364-2

Keywords

Search

Navigation