ac-curacy when used for new users. We are aware that these results are limited to our dataset and might not be generalizable. A further study might focus on the generalizability of this approach by looking into specific groups of people such as colleagues in the same office or grouping job positions such as consultants.
Further, we can use the approach to user enhance privacy. For example, if we develop the approach as a background app on Android devices, we can control what data other apps can access, send to a corporate server, or share with third-party apps, even if its a company-owned device.
The third field of application addresses data security. Security policy enforce-ment frameworks such as the MUSES project [174], who aim at preventing and avoiding information security risks introduced by the behavior of users, can ben-efit from our approach. Such policy enforcing systems often process the usage and context data on servers in the cloud. Our approach allows on-device classi-fication without the need to share sensitive data. Further, we can limit the data collection of policy enforcement systems to professional usage sessions.
If Android would include our approach in the operating system, we can improve and automate functionality like Android for Work [90]. In Android for Work and other Device or Space Management Solutions, users have to explicitly select whether they want to perform private or work-related tasks by, e.g., opening specific apps or by specifying it beforehand. Our approach can automate this step. Further, we could leverage the data from Android for Work, and similar systems to continuously train and improve our machine learning model.
The next field of application is the development of time management systems that automatically log private and professional activities helping to create pro-ductivity, billing, time tracking, and overtimes reports. Such a system could understand the distribution of work and create a more accurate overview of the total worked hours. Employers can use that field of application, too, to get a better overview of the workload of their employees.
Finally, our approach can help to personalize advertisements. Apps can use our approach to show advertisements that are related to the current usage pur-pose. During professional-related tasks, we can show advertisements related to the work, while we can show ads for personal interest can as soon as the device detects private usage.
7.5.3 Alternative Implementations from Related Work
Our study focused on privacy and security scenarios by analyzing context data to understand if a device is used privately or for work. However, the analysis may look completely different depending on the domain that needs to analyze context
data. Here, we present two alternative ideas for analyzing user context data.
Our first example is an analytics tool that provides information about the performance of the software (computing environment context). Mobile app mon-itoring is a field in research that targets the performance of apps in terms of, e.g., CPU, memory, and battery usage [192, 200] or response times for apps relying on online services [242]. This kind of analysis can find weak spots in the soft-ware that either slow down its performance or unusually drains the energy of the device. Identifying these weak spots can be useful in requirements engineering to understand how well certain aspects of an app perform, and in case it has a bad performance, maybe re-worked in a future iteration. For example, we may find that sending chat messages takes five seconds on average, although, the non-functional requirements envision a performance of less than 1 second. Continuous monitoring performance indicators could help for improving an existing software early; in the best case, before users write negative reviews [216].
In the second exemplary scenario, we are a company providing a service for taxi drivers that helps them finding customers, navigates them to the customer, and to the customer’s target location (physical context). In this example, we want to analyze the location of the user (the taxi driver) to support insights for the driver and the company the driver belongs to [56]. Both parties want to optimize their routes to have short travel times without a customer to maximize the earnings [37]. Besides, the driver and the customer may have personalized preferences [137, 168]. The driver might want to stop working soon, while the customer might either want to be at the target location as quick as possible or needs more than four seats. By analyzing the location of the driver and the customer either with GPS or with Wi-Fi-based data, we can receive their exact position and optimize their routes [142]. In requirements engineering, we can use this detailed feedback on the people’s locations to test and simulate different algorithms and options for finding the best routes. Further, we can check their performance results against our non-functional requirements metrics.
7.5.4 Limitations and Threats to Validity
We discuss the internal and external validity of our results as well as the limita-tions of the approach.
Internal threats to validity. Concerning the internal validity, one potential threat is related to the comparison of the classifiers. As the number of the used classifiers is limited to four, we might have missed one that could have better results than theDecision Tree. We might improve the approach by extending the performed benchmark with further classifiers, by further tweaking the parame-ters of the chosen classifiers, and by considering other techniques like association rules.
The reported results rely on the crowdsourcing study, we could think of pos-sible participants’ bias, as the participants might have selected the wrong label or forgot to update the label during the usage. To avoid bias by unintentional wrong labels, we have shown the currently selected usage in the notification bar of Android, so that the participants were aware of what is currently selected.
Furthermore, we created a manual for the app that created awareness of how to use the application, the possibility to change the label at any time, as well as the information, that the currently selected label is visible in the notification bar.
External threats to validity. The number of participants might have in-fluenced the reported results. We tried to mitigate the side effects by choosing participants with different demographics to avoid the possible bias of focusing on a specific group of persons. However, since we had only a few participants, there is a threat to the generalizability of the approach.
Although the Decision Tree classifier performed best in our study, we cannot guarantee that this will be the case for different participants. Therefore, our results are rather indicative. For instance, the Decision Table often has similar results to the Decision Tree and might generate better results for other partici-pants outside this study.
Our approach works on Android devices. The feasibility of our approach might differ on other devices, like computers and laptops, and platforms, such as iOS.
Although we focused on Android, we think that we cover many mobile devices because of the high market share of Android, which is about ~87%.
Finally, after creating a classification model, the accuracy might change or decrease over time. Since users might install and uninstall applications, change their jobs or interactions with the device in general. The classification accuracy might decrease if the model does not adapt to such changes.