Non-functional Requirements

Enterprise Mobile Initiatives, as discussed in the previous post, are complex & challenging endeavors. While it may be a single app, or multiple apps, the easier part of the Enterprise Mobility jig saw puzzle is to address business / functional requirements. These are mostly explicitly stated by business users. The more challenging aspect is addressing non functional requirements. These typically come up over a period of time as the mobile apps start getting used by enterprise users. If these requirements are not addressed quickly, then can even lead to failure of the mobility initiative.

I have listed some of the prominent non functional requirements below, based on my experience. I must confess, however, we learnt some of these requirements the hard way while the mobile apps were in use by the end users. In one case, we had to recall the app, pause the initiative, fix the issue and relaunch. This meant rework, anxiety and project cost escalation. I do not say these requirements would be applicable to the mobility projects that you may be associated with, but certainly, you should pay as much attention to these non functional requirements as much you would to functional requirements.

i. Offline functioning of Mobile Apps

A large number of use cases of Mobile apps are related to sales & distribution/customer service, enabling this staff operating in the field. The consumer that they have to deal with, in the field needs to be served quickly, without hick-ups. Connectivity of mobile devices especially inside buildings is always a challenge, and our early experience showed that sales / customer service staff has to face a lot of customer ire, when the app couldn’t function for lack of connectivity. So, mobility apps may be required to operate in off-line mode.

ii. Data Sync capability between the mobile device and data center servers

Once a mobile app is required to operate in an offline mode, it is inevitable to have business rules and validation logic coded in the mobile app and also app transaction data stored in the mobile device, although temporarily. Typically, the requirement in case of off-line mode apps is to send the data to the back-office apps so that business transactions can be triggered / fulfilled within the promised SLAs. Sync capability can be built either auto (mostly) or manual.

iii. Data Security in case of storage data in the mobile device

Apps supporting off-line mode operation, store data in the mobile device itself. In one of the apps that I was building, the stored data included customer data and along with the signature. The Risk team flagged it as a major risk, and we were required to not only sand box the data folders but also store the data encrypted. So, mobility solution architects are required to assess sensitivity and risks associated with the data managed by the app and establish appropriate level of controls.

iv. Mobile Apps Version & Release Management

Expect, if the mobile initiative / app being implemented is mission critical, the mobile app to undergo a number of enhancements. Such new versions of the mobile app carry not only enhanced functionality but also fixed bugs and so, the occurrences of release of versions can be frequent in the initial phases of the project. Thus enterprise mobility initiatives need to plan for proper version management and version release processes. Download and self installation of the new versions as soon as they are available may be required to be automated and coded in the mobile solution.

v. Remote Support

Most of the mission critical enterprise mobility initiatives are meant to be used by mobile workforce, who operate in the field with minimum support or touch-points with office locations with proper IT support infrastructure. In case, the mobile apps involve complex and long transactions such as new customer acquisition transactions, mobile workforce needs top quality support. Such support either could be local or remote. For remote / centralised training & support desk to be effective, they need to be provided with software tools, which can enable them to either take remote control of the mobile devices or view shared screens.

More non-functional requirements will be covered in the next blog post.

Reproduced from Wanders Through The Mist