Non Functional Requirements, Part B (To read part A, click here)
vii. Device Registration
In case mobile apps are built for employees, organisations typically want better control on who the users are and what devices these apps are accessing from. So, while mobile app can be downloaded from a public app store and installed, by default, user with valid username and password may not be able to use the app. The device’s unique id registered with the with organisation so that it can be authenticated that only valid users have access to the application and corporate data. Even in cases, where the mobile apps are for customers and partners, restrictions on no. of devices from which the app can be accessed can give comfort to both the users as well as the organisations and protect privacy and confidentiality of data.
viii. Private App Store
There are multiple ways, in which, enterprise mobile apps can be distributed. Mobile apps can be published in public app stores or can be distributed through corporate IT infra, or apps can be hosted in private app stores. Establishing private app stores can give organisations much better control on what employees can install on the devices, especially if devices are owned by the organisation. It is expected that, as mobility initiatives become enteprisewide, organisations would naturally opt for private app stores and hence it may makes sense to plan for one right for the initial stages of the initative.
ix. Device Deactivation / De-registration
Mobility initiatives face a major change management risk. A long with the ease & empowerment they offer to the employees particularly in the field, they tend to enforce discipline, bring about uniformity in processes, and also at times increase in efforts in the hands of the end user. One of the ways by which this risk can be mitigated is by threatening deactivation of the app in case of non use. So, one of the requirements we encountered was to deactivate the user login in case user did not login into the app for 3 continuous days. The reactivation in this case would require users to give explanations to supervisors and super bosses. Permanent device deactivation is also required in the form of device de-registration when the employee leaves the organisation.
x. Device Tracking
Device tracking is critical for organisations where mobile device is owned by the organisation. Mobile devices like smart phones and tabs are expensive investments, and hence it becomes necessary for organisations to track them so that they can be recovered in case of theft or loss. One of the requirements, that I had encountered was to recommend optimum path for sales or service executive while addressing customer sales / service requests and compare the actual path and deviations. Also, send real-time alerts to the executive to address urgent customer requirements in case of irate or priority customers. Thus device tacking may be become an important risk mitigation mechanism as well as means to achieve tactical benefits.
xi. Remote Back-up
Remote back-up of the data on the device can be useful in case the device is lost or damaged or is required to be reset. Hence organisations may seek mobile apps to have a feature to take back-up of the critical mobile app data and have it stored on the central servers.
xii. Remote Wipe-out
Remote wipe-out is the last option in case the device is lost. This can at least ensure that critical organisation data does not fall in the wrong hands.
These are some of the non functional requirements, which mobility initiative architects and analysts may or may not hear from business users but certainly may have to consider while implementing their respective enterprise mobility initiative. The list of these requirements above may not be comprehensive and also may not be applicable to all the mobility initiatives. One would be required to carry-out cost benefit analysis then decide whether the solution being implemented should design for these non functional requirements.