As mobile devices have become an indispensable part of people's lives, the growth of mobile app market is inevitably rapid. Accordingly, the mobile app users have increasing demands on the quality of the apps. Their tolerance towards bugs and poor usability of the apps is growing low. In addition, as the mobile devices and apps have enabled users to use them in various contexts, the mobility of the apps, referred to as their capability to provide ubiquitous services with quality, is also required. In this study, we propose the scenario-driven approach of mobility requirements analysis with context and ways of interaction. It supports the continuous requirements analysis in the maintenance of mobile apps where their mobility is constantly maintained despite the changes in the features.
The mobility of mobile apps, as their most significant feature, is defined as the ability
to access services ubiquitously, on the move, though wireless networks and various
mobile devices [
The different digital distribution platforms for mobile apps enable and promote the
easy communication among users and developers. Therefore, it is a common strategy
for the companies to update their apps in short cycles continuously [
Context is defined as “any information that characterizes a situation related to the
interaction between humans, applications, and the surrounding environment” [
Hence, to analyze the mobility attribute of an app, we shall obtain information on
the context in which the app is often used. Scenario is an efficient tool to facilitate
context information acquisition and its mapping with the system functions from the
users’ viewpoint [
The remainder of the paper is organized as follows. Section 2 overviews understanding of mobility as the quality of mobile apps, and the situational contexts of using an app. Section 3 presents the use of scenarios to elicit contexts information for mobility requirements analysis. Section 4 explains the use of conflicts in ways of interaction representing mobility loss and the process model of analyzing a change request towards mobility maintenance. Section 5 demonstrates how our approach is applied for requirements analysis in a real-life mobile app case. Section 6 concludes the paper with the limitation and future work covered. 2
Mobility is the ability to access services ubiquitously, on the move, though wireless
networks and various mobile devices [
The context of information systems and mobile devices have been studied widely.
Most of the given definitions of context claim that context encompasses the aspects
including, location, the physical environment, people nearby the user, the time of the
day, the computing environment, user’s emotional states, the focus of attention, and
so on [
The temporality, spatiality, sociality are the three critical perspectives to illustrate
the situational context [
Based on our categorization of the situational context of the mobile app, for each
user, we consider he/she must be situated in one combination of temporary, spatial
and social context. Thus, by cross-combining the different perspective values of the
situational contexts, we have then 12 unique situational contexts including IVC,
AVC, IVE, AVE, ITC, ATC, ITE, ATE, IWC, AWC, IWE, AWE [
Furthermore, the situational contexts are not equally important to take into account for each app. Based on the vision and scope of each app, it is originally planned and developed to fit specific situational contexts. For example, the game Vainglory1 (a real-time player-vs-player multiplayer online battle arena) is certainly designed for the AVE context, as one gameplay session of it will take quite long time with users’ full concentration. It is unsafe to play the game when walking or running and is also inappropriate to play in a social event too. However, the game 20482 (a casual game without time limit) for not only AVE context but also other contexts, such as ITE, and AWE, as the user can make a quick move even when the time is limited. We define such more important context(s) as the primary context(s) of the app. The suitable context for individual features can be inherited from the primary contexts, however, it can also differ from feature to feature. Because the different features serve the different courses of interaction, which occur more preferably, in a different context. Taking Pokémon Go3as an example, the feature of “searching for a Pokémon nearby” requires a player to walk around the streets and encourages users to play in an AWE context, while “catching a Pokémon” requires the player to stop walking for a short while and mostly fits an AVE context. Therefore, the prioritization of situational contexts is also necessary for each individual feature. 3
Scenarios are stories or examples of events as grounded narrative taken from
realworld experience, in which the design rationale or a problem situation is anchored for
requirements analysis and design decisions [
2 https://gabrielecirulli.github.io/2048/ 3 https://www.pokemongo.com/
An event sequence is a description of what people do and how people use a
software system in a particular instance. It is a sequence of activities or a more or less
richly branched structure of such sequences [
The intrinsic mobility of mobile devices and the apps within have enabled users to
use them ubiquitously [
Many studies propose methods and processes to construct scenarios for
requirements analysis in various forms [
To maintain the mobility attribute of the mobile apps in the maintenance and evolution phase, the mobility loss resulting from changes in features must be detected and controlled. It shall prevent the changed features cause the users’ uncomfortable interactions in some important situational contexts. Such practice shall continuously detect and address the potential mobility loss within the proposed change requests.
The first critical step of proceeding the approach is to obtain the context information concerning the proposed change requests. Here we use scenarios to elicit the required context information.
When a change request is proposed in the maintenance phase, referencing the documented requirements, the features affected by the change request could be identified. Presumably, when similar mobility requirements analysis has been executed in the development phase, the previous context analysis results can be inherited.
A change request records an adjustment for an app which includes a narrative
abstract of the change. If the change is about specific features, the scene could be
extracted from the abstract. In addition, scenes and scenarios can be identified and
specified by interviewing the originator who submitted the change request, as well as the
stakeholders who are related to the affected features. Therein, the requirements
analyst shall pay attention to the edge of the complete use session of the feature and the
scene switching. For ambiguities, the stakeholder shall be further probed. On the other
hand, the event sequence of scenarios can be recorded in various forms, including
textual descriptions, use cases, activity sequence diagrams, etc. [
With the created scenarios, the requirements analyst shall be able to obtain a list of scenes where the change occurs. For each scene, the situational context (one out of the 12) will be identified. When there are multiple scenes describing the same situational context, the number will be recorded to facilitate the prioritization of the situational contexts. When the list of situational contexts is extracted from the scenarios, they shall be distinguished from the primary contexts for the app and assigned uniquely to each feature. 4.2
The way of interaction describes the users’ ways of switching from their activity in
the context to the interaction with the apps until the goal of app use is accomplished
[
There are four different ways of interaction, including accompanying, interrupting,
intermittent, and ignoring (shown in Table 2) [
Ways of Interaction
Description Accompanying Interrupting Intermittent Ignoring The paralleling engagement in both user’s interaction in context and the interaction with app. (e.g., Listen to music when reading) The user converts full concentration on the interaction with app and ceases the original activity. (e.g., Stop reading and start browsing friends’ status updates) The interlaced engagement in both the user’s interaction in context and the interaction with app, with the whole process of several short interactions, which are neither consistent nor interfering the proceeding of the original task. (e.g., Watch TV and send messages) The interaction with app is ignored by the user in order to maintain the proceeding of interaction in context. (e.g., Ignore all messages when taking exams)
According to the definition of the ways of interaction, it represents the users’ interaction switching from the context to the app. Therefore, for every context as categorized in the previous section, one or more ways of interaction is encouraged, and defined as the ideal way of interaction (IWoI), as shown in Table 3. To identify the IWoIs for a typical situational context, the three perspectives of the situational context, temporality, spatiality, and sociality must be taken into account. For example, Table 3 shows an example of determining the possible ideal ways of interaction for each context perspective.
Based on the table of IWoIs for context perspectives, the IWoI for each situational context is thus the intersection of ways of interaction set of all three perspectives. For example, the IWoI of IVC situational context (Intensive, Visiting, Constraining) is Intermittent, which is the intersection of (Accompanying, Intermittent), (Accompanying, Intermittent, Interrupting), and (Intermittent).
Similarly, for a feature offered by an app, some ways of interaction are also
required, defined as the expected way of interaction (EWoI). The EWoI of the feature is
determined by the persistence and obtrusiveness of the feature [
Table 4 shows one example of determining the EWoI of one app feature. For example, the “sending instant message” feature of WeChat is ephemeral (i.e., it takes several seconds to send a message) and obtrusive (i.e., the user will be notified when receiving a message). Therefore, the possible EWoI of this feature is intermittent or accompanying.
Therefore, the conflicts between such ways of interaction choices and the ones for the contexts will then cause the users’ uncomfortable use of the app or frequent ignoring the app when such contexts occur often. Thus, detecting and addressing such conflicts between IWoI and EWoI is the key to improve users’ comfortable use of the app in primary contexts, and further the sense of mobility overall. 4.3
Before the maintenance phase starts, the development team shall possess the project vision and scope, as well as the requirements documents in a certain form. Therefore, when a feature change request is proposed (e.g., based on the reviews of the end users) the team shall start collecting the scenarios from the stakeholders who propose the change based on the team’s experiences and overall understanding of the app. On the other hand, the affected features will be identified. The feature is associated with information such as the context and the EWoI which has been accumulatively specified during the development and maintenance process.
Based on the scenarios collected, the team shall then be able to specify the situational context of the feature with the reference of the situational context classification. If the primary contexts of the app are available in the requirements document, the context information shall be compared with the ones obtained from the scenarios. When the predefined primary contexts are not covered in the scenarios, they shall also be taken into account. On the other hand, when no previous primary contexts are defined, the situational contexts of the feature will then be only based on the scenes from the collected scenarios.
If the identified feature is a new one, the team shall specify this new feature as well as its EWoI. When the feature is identified from the previous requirements document, the EWoI, as well as the related primary situational contexts will be inherited. On the other hand, the identified situational contexts from the collected scenarios will be matched with primary contexts. When a significant number of new situational contexts are identified from the scenarios, the new situational contexts will be seen as a primary context. Then the IWoIs for all primary contexts will be specified.
Conflicts of interactions will be identified when both EWoI and IWoI are specified. For example, the EWoI of “playing a combat” feature of Vainglory (interrupting) has conflict with the IWoI of IVE situational context (intermittent). It indicates the users will mostly not have a good experience playing the game while he/she is watching an intensive ice hockey game (a scene for IVE).
When conflicts of interaction occur, the changes shall be made to the feature in terms of the functional and quality requirements related in order to solve such conflicts. Each requirement with conflicting ways of interaction will be further analyzed. Changes are made, or new requirements are added, based on the collective understanding towards the nature of the features to comply those requirements with the IWoIs of the primary contexts. For example, to address the conflict in the previous example, one option is to change the gameplay towards the intermittent way of interaction, which provides ephemeral play session not interrupting the original activity.
The process shall continue through the whole maintenance phase. It continuously detects and addresses the potential conflicts in ways of interaction and maintain the mobility of the target apps towards the users’ primary situational contexts. 5
In this section, we apply the mobility requirements analysis approach into a change control process in the maintenance of a mobile app, called FireStatus. FireStatus is an Android app designed to facilitate the emergent message transmission between the Emergency Response Centre and the Volunteer Fire Department. The client of the project, Perhon Palomiesyhdistys ry5, is one of the Finnish Volunteer Fire Departments. In the volunteer fire department, firefighters are not present at the fire station, but at home, at work, etc. The FireStatus app enables the volunteer firefighters, who are in various contexts, to receive messages of emergency calls and respond quickly.
The app was developed in a student project6. Its main features include receiving and responding to emergency messages (Screenshot 1 in Fig. 2.), checking the responding situation of the incident calls (Screenshot 2), and various settings of the alarm sound, the keywords, incident dispatching number, etc. (Screenshot 3).
When a volunteer receives an alarm message, he/she can respond with coming immediately, later or not coming by clicking one of the three buttons. The participation information is given in the Participant tab, which shows three firemen will come immediately (in the green bar) with their names and their skills shown in the gray area, another three comes in five minutes (in the yellow bar), one is unable to come (in the red bar) and nine are without any response (in the white bar). The settings tab shows the functions of changing alarm sound, changing vibration and so on.
We started an online interview with the end-users of the FireStatus app for their feedback on the application. Despite of the overall satisfaction on the app from the users, they did mention that the main feature of the app can be certainly improved to be more convenient. Therefore, tracing back to the original requirements document, we confirm the core feature of the app was recorded as Requirement 170057, which states a volunteer firefighter shall be able to get information about the accident when receiving the emergency alarm and make decision on whether to participate and when. Concerning this specific feature of the app, further questions concerning the scenarios of use are also forwarded to the users.
5 http://www.perhonpalomiehet.fi/ 6 http://www.uta.fi/sis/tie/pw/previous-projects.html
When a set of scenarios are collected with the situational contexts are easily specified (shown in Table 5). As the context analysis was not included in the development phase nor recorded in requirements document, the situational contexts acquired from the users’ scenarios will be seen as the primary contexts. A typical scene is assigned to each situational context to ease the understanding of such contexts.
Furthermore, we prioritize the acquired situational contexts by the occurrence of such context in the scenarios. For each situational context, one or more IWoIs are assigned based on the previous reference tables in Section 3 (shown in Table 6). The EWoI is defined as Interrupting.
Therefore, by comparing the IWoIs of the situational contexts and the EWoI of the feature, we can easily identify the conflicts. As shown in Table 6, the interrupting nature of this core feature of the app only suits the situational context of AVE, which means that the user shall have a pleasant use of the app only when he/she is in a situation similar to “being idle at home”. In other situations, for example, when the users are engaged in a social interaction (socially constraining, e.g., AVC, IVC), or when they have limited time to put attention and focus on reading the information (temporally intensive, e.g., IVE, ITC), intermittent or accompanying ways of interaction shall be more preferable by the users, towards which the feature shall be updated.
Currently, considering the current design of the app, information of the occurred incident and the participants are separately displayed (Screenshot 1 & 2). This shall result in long concentration and interruption towards users’ original action and should be improved. Furthermore, ways of acquiring information other than reading from the screen is also a good way to avoid interrupting. A set of change requests are proposed as new requirements shown in Table 7.
New Requirements The volunteer firefighter shall be able to view the incident information (e.g., location, severity, keywords, responded participants) and respond on one screen.
The volunteer firefighter shall be able to listen to the read-out of the incident information.
The volunteer firefighter shall be able to respond and change the response via voice control (e.g., Siri, OK Google) From opening the app to the response is sent, the duration shall be no longer than 3 seconds.
Among the new requirements, Requirement 170057.1 aims to reduce the interaction duration of the targeting feature and enable retractable action. In this way, the feature shall then provide more intermittent ways of interaction, which suits more for socially constraining situations and temporally intensive situations. Furthermore, to specify Requirement 170057.1 towards shortened concentration time and effective information acquiring, a set of sub-requirements can also be proposed, such as the notification sound varies according to the severity of the incident, the theme color varies according to the severity of the incident, the keywords related to the firefighter’s skills shall be highlighted and shown at front, etc. On the other hand, Requirements 170057.2 and 170057.3 aim to create an alternative accompanying way of interaction for the feature by introducing information read-out and voice control, so that the users are then able to continue focusing on their original activity while acquiring the information and making decisions. In addition, non-functional Requirement 170057.4 adds further constraints on and emphasize the short interaction duration.
With the help of the app development team and the end users, we further validated the new requirements. The development team agree that the six scenes shown in Table 3 are indeed the most common situations. Furthermore, despite not recognizing any enhancement possibilities at the beginning, the developers do believe Requirement 170057.1, 170057.1.3 and 170057.4 are necessary considering the situational context of use. However, they also emphasize that “simplicity” is the key attribute of the app, as the app targets to provide the pure functional service for the users from a special domain, who might be confused with more features added. Therefore, they consider reading-out information and voice control features unnecessary. Concerning the end users, a majority of them are satisfied with the current version of the app when the rest express rooms for improvement but not dissatisfaction. Concerning the proposed new features, the end users also like the way to reduce interaction duration by condensing key information on single screen and using easily detectable visualizations. Moreover, like the indication from the developers, only a minority of the end users like the idea of voice-based info acquiring and responding. 6
As the key quality attribute of mobile apps, their mobility should be taken into account in both development and maintenance phase. When one change request is proposed, whether it will cause mobility loss is a question to be addressed before the app is updated. By using scenarios as a supporting tool, we propose the continuous mobility requirement analysis approach for app maintenance with the process model and relevant techniques, illustrating the way of maintaining the mobility of the app. Via the demonstration of the example of proposing change request to FireStatus app, we validate the usefulness of this approach in detecting the potential mobility loss hazard and addressing the issue by updating requirements. This approach will facilitate the mobile app maintenance practice by enhancing the understanding of the relation between mobility-impacting factors, e.g., the situational context and ways of interactions.
On the other hand, this study can be improved by a more thorough classification in each of the perspectives of situational context. Furthermore, a more explicit and unified reference model for detecting the conflicts in ways of interaction is also needed. A predefined scenario modeling approach shall also facilitate the process of acquiring context scenes and identifying features. A collaborating analysis tool can support this approach well. Further validation and evaluation of the approach are required with the support of empirical data. The relevant future empirical study shall also investigate the relation between the feature changes in maintenance and the mobility loss, as well as the factors to it. A prospective case study with real-life mobile companies shall be planned to address the aspects mentioned above.
We thank the development team of the FireStatus app, Perhon Palomiehet association, and Ossi Puustinen for their help in this study.