Non-Functional Requirements in Mobile Applications

A careful specification and adherence of non-functional requirements such as performance, security, privacy and availability are crucial to the success or failure of any software system. To see why, imagine if your bank’s website were to display the following disclaimer on its homepage: “We do not guarantee the security of your personal data or your account information while transacting on our online-banking portal”. Will you still use it? Almost certainly not!

The correct specification and adherence of non-functional requirements similarly plays at least an equal, if not a greater role in the success of mobile applications.

This is due to the following reasons:

  1. Mobile devices are uniquely constrained in several aspects such as multi-tasking support, available network bandwidth, screen real estate etc. These constraints translate into strict bounds being imposed on the operating characteristics of an application running on a mobile device.
  2. Mobile applications need to operate successfully (or degrade gracefully) within a wide spectrum of operating conditions, such as a range of supported screen resolutions and form factors, network bandwidth situations and network types (2G, 3G, 4G, WiFi) etc.
  3. Mobile applications sometimes need to interact with the device’s sensors such as GPS, accelerometer, the ambient light sensor, camera etc. The application must respect the sensor’s operating characteristics such as its operating range, sensitivity, accuracy, minimum polling interval etc.
  4. Finally, users expect a different quality of user experience from an application running on the mobile device than they do from their desktop computer. For example, it is much less acceptable to have to reboot the phone when a mobile application hangs. Thus the latitude for error tends to be less for a mobile application than for the desktop version of the application in the same situation.

Thus, it is critical to:

  1. Capture these requirements as accurately and exhaustively as possible.
  2. Ensure that the application’s design addresses each requirement.
  3. Develop the application to meet these requirements.
  4. Test the application against each requirement so as to verify compliance.

In the rest of this article, I will dig deeper into the major types of non-functional requirements for mobile applications, describe the impact of each requirement on the operating characteristics of a mobile application and wherever possible, provide guidelines for specifying and implementing each requirement.

CPU & Memory

When an application is developed to run on a particular software platform such as Java ME (formerly known as J2ME), Android, iOS etc. it can in theory be installed and run on any device that supports that OS platform. However, for any given OS, the supported devices could have a very wide range of capabilities in terms of CPU speed and available memory. For example, an Android app can be theoretically run on both a low end Android phone having limited RAM and a single core CPU, and on a high end device sporting several gigabytes of RAM and an Octa-core processor. However, if the app has been designed to require a certain minimum CPU power and memory, it will in practice, fail on the low end Android phone. If your application makes extensive use of arithmetic and logic operations such as those involved in streaming and decompression of audio and video and in rich animations, or it lets the user view and manipulate large sets of information or images, you should specify minimum CPU and memory requirements for the application in exactly the same way it is done for desktop applications.

To determine these requirements objectively, you can evaluate each feature in your application from the point of view of its CPU and memory consumption by running it in a profiling tool, and accordingly arrive at a lower bound for the entire application from this analysis.

Here’s a list of the CPU and memory profiling tools you can use for some of the common smart phone platforms:

iOS: The XCode development environment comes with a rich suite of performance measurement, analysis and monitoring tools under the Performance Tools package. Chief among them is the Instruments performance measurement tool, and several analysis and monitoring tools that will together provide you everything you need to measure, analyze and monitor performance at the finest grain in memory, CPU, network usage and much more.

Android: Android Developer Tools (ADT) comes with the Dalvik Debug Monitor Server (DDMS) which will show you a variety of information about the running state of the Android app such as thread and heap information, process information, the LogCat display etc. Additionally, you can use the Traceview and dmtracedump tools to trace method calls and track which methods your code has spent most time in. The Systrace tool will let you see the bigger picture on your app’s performance by showing the performance characteristics of your application’s processes alongside the Android system processes on a common timeline. You can use the very powerful HPROF tool or DDMS itself to analyze heap usage and see which method calls are contributing the most to heap usage. The hprof output can be generated and analyzed in a variety of different ways. See Android developer documentation for details. Several third party apps are also available on the Play Store to help measure and analyze CPU, memory and battery performance of your app.

Blackberry: Blackberry 10 apps can profiled using two different profiling tools that are available as part of the Blackberry 10 Native SDK and the Momentics IDE. If you have developed a Cascades QML Blackberry app, you can use the Cascades Profiler to profile the application’s performance characteristics. On the other hand if you have written a native Blackbbery app that uses Core C/C++ APIs, you can use a tool called the Application Profiler.

Windows Phone 8.x: Microsoft has integrated a Performance and Diagnostics Hub in Visual Studio 2013 that will let you profile the performance of your Windows Phone 8.x app. The idea is to set the app to run in the emulator or the actual device (running it on the device is recommended for performance measurement), select the appropriate profiling tool within the Performance and Diagnostics Hub in VS 2013 and begin profiling.

For all platforms, you will also be able to find several third party performance monitoring tools on their respective app store sites.


Network Conditions

There are four things to consider in this area:

Support for different network protocols: Mobile devices can communicate with the network on one or more protocols such as SMS, USSD, WiFi, EDGE, UMTS, LTE etc. Certain functions in your application may not perform well (or not perform at all) on certain protocols. If you wish to support only the high capacity protocols such as WiFi & LTE, you will risk shutting out the low-end devices which may not support these protocols. On the other hand, if you do not specify which are the required (or recommended) protocols for your application, it may result in the users inadvertently trying your application’s high-bandwidth features on a low-bandwidth protocol such as EDGE, thereby frustrating themselves out of the application.

For a networked application, it is crucial that you evaluate each network-enabled feature of the application from the point of view of determining the protocol that it is most likely to require. For features such as streaming media, you may want to require the user to switch on a high capacity protocol such as WiFi, UMTS (3G) or LTE (4G). Alternately, you may design the feature to degrade or fail gracefully, if the user operates it on a low-capacity protocol. For example, you may want to serve the media in a low bandwidth format such as 3GP over EDGE and in a high bandwidth format such as MP4 over a WiFi or a 3G/4G protocol. A Twitter client, on the other hand can be written to work just as efficiently on a very low capacity protocol such as SMS (assuming you have a SMS translation gateway in place that your application can talk to), or a high capacity channel such as WiFi. However, when operating over the SMS channel, you should turn off the transmission or receipt of anything that is not pure ASCII text, thereby ensuring a graceful degradation.

Finally, be sure to inform the user if a particular feature is likely to degrade, or not be available on a certain channel. Also inform them about additional usage charges if choosing to operate over certain channels such as SMS so as to prevent a billing surprise.

Signal drop or signal strength reduction: Be sure to evaluate each network-enabled feature in your application in the situation, where the protocol over which it is operating becomes unavailable or its signal strength reduces. Ensure that the feature is either network-fault tolerant or degrades or fails gracefully in such a situation. Conceptually this network situation isn’t any different from the scenario in which a network enabled desktop application encounters a loss of network or network congestion. The main difference with the mobile situation is that a mobile application is more likely to encounter a network drop or signal strength reduction situation than the desktop version of the application due to the inherently mobile nature of the platform.

Network protocol transition: This network condition deals with the mobile application’s behavior when the device transitions from one protocol to another. A classic scenario is one where the user walks out of their office building and the device transitions from WiFi to 3G. If there is a transaction underway in the mobile application when this happens, how will the application react to such a protocol transition? It is useful to evaluate the application’s functionality in such situations and design it for a seamless transition to the new protocol or for a graceful degradation or failure.

Support for multiple protocols: This network condition relates to the mobile application’s behavior when there are multiple network protocol radios active at a time. Note that most smart phone operating systems today automatically prefer WiFi if it is available, rather than using cellular data (e.g. EDGE/UMTS/CDMA2000/LTE). Android and iOS display this behavior. Windows Phone 7 had a bug that prevented WiFi from being given a preference but that appears to have been fixed now in later versions. In the older versions of Blackberry (definitely up through Blackberry OS 6), one could programmatically specify that in one’s app that WiFi was desired.

In general, you will not have this option today to choose a specific radio – Wifi or cellular – in your app.

However, note that the SDKs of most major mobile platforms provide a means to register for listening to one or more network related events or notifications when a network protocol radio becomes available or unavailable or when the signal strength on that protocol changes. You should register for such notifications and perform network condition handling inside the network listeners. Also, program all network calls defensively via extensive use of exception blocks and return value checking so as to ensure a graceful degradation or failure of the call.


Interrupts, notifications and multi-tasking

When a phone call, SMS or some type of notification (such as a calendar notification) arrives, your mobile device will usually inform your application of this event. If the user chooses to respond to the event, the OS may either background your application or, in case of non-multi-tasking mobile operating systems, simply terminate your application. In either case, the OS will usually give your application a chance to respond to the pause, background or termination event by invoking a handler method that you should implement.

It is important that your mobile application handles the interrupt in such a way that:

  1. It does not come in the way of the OS’s processing the user’s decision to respond to the interrupt (such as accepting a call or reading an SMS), and
  2. It does not result in any damage to your application’s ability to function normally after the OS ‘foregrounds’ i.e. resumes your application after the user finishes handling the interrupt or after they choose to ignore the interrupt.

You should evaluate each feature in the application from the point of view of determining how it would, and should function if the application gets sent into the background by the OS, or made dormant while that feature is executing, and how it will recover from this interrupt condition after the OS or the user brings the application back into the foreground after servicing the interruption.


Screen resolution and screen form factors

If you design your app for only low resolution screens, one of two things will happen if a user runs it on a high resolution screen phone – either the high resolution phone will not apply automatic pixel doubling, in which case, your app will occupy a tiny area of the screen of the high resolution phone, or the high res phone will apply pixel doubling in which case your app’s UI might look odd in places where images and fonts are unnaturally large. Either way, things are likely to look bad, even though, technically the app functions correctly. Similarly, an application designed for a high-resolution (high Dots Per Inch – DPI) screen may have a major part of its UI go off screen on a low DPI screen phone, if the OS does not do automatic pixel filtering, leading to quite an annoying experience at best.

Open platforms such as Android that runs on hundreds of different types of phone and tablet devices are particularly susceptible to screen DPI issues.

Hence it’s important to keep a set of target screen resolutions in mind while designing the user interface of a mobile application. Practically, you will need to identify one or more screen resolution (or alternately screen size) families that you want to support. For example, let’s say you want your app to support all kinds of popularly available display sizes. It is useful to divide this wide range into a) 4.x to 6.x inch displays, b) 7.x to 9.x inch mini tablets and c) 9.x to 12.x inch full size tablets. Now, find out the screen resolution range for each family size. Finally, identify one or two representative devices in each family that you want to test the app on.

Normally, you will find that the following kinds of changes will be needed for supporting different screen resolutions:

Font adjustment: The text font size may need to be adjusted up (for high resolution screens) or down (for low resolution screens) so as to keep the text readable.

Layout tweaks: The layout may need to be adjusted to increase or decrease the spacing between and around labels and widgets shown on the screen so as to prevent them from getting clustered together on high-res screens or spaced apart too much on low-res screens.

Image changes: Background images or background art may have to be provided in two different versions: a large size/high resolution version and a small size/low resolution version so that it properly fills the amount of physical space available on the screen.

Most smart phone SDKs have a fairly well-defined methodology for specifying which screen sizes/resolutions your app supports and then a way to specify the imagery, fonts and layouts for each screen size family. Your app should make full use of these OS and SDK provided mechanisms to support different screen sizes  of devices running that particular mobile OS.

Touch and non-touch screens: If you are supporting platforms such as Symbian and Blackberry that can work on both touch, non-touch and dual-input i.e. physical keyboard + touch devices, you should ensure that touch is enabled for all features in your application when the application is operating in touch screen mode. There is usually API support available to your application to detect whether the application is operating on a touch enabled screen.

Portrait and Landscape modes: Avoid adding the complexity of supporting both portrait and landscape modes if your application does not need to work in both modes. However, if you decide to add support for both modes, try to add this support for all screens in the application and not just some of the screens so as prevent a usability surprise.


Battery usage

On mobile devices, the battery is a scarce and valuable resource.

There are three major sources of battery drain in a mobile device:

  1. The main processor,
  2. The device’s screen (and therefore also the Graphics Processor a.k.a. the GPU), and
  3. The communications processors (such as the ones used for interacting with the cellular network, WiFi, GPS and Bluetooth at regular intervals).

On a mobile phone, the battery should remain maximally available for the phone application i.e. for making and receiving phone calls. Your application may therefore fall by the wayside or even get uninstalled by the user, if it drains too much battery. The definition of what constitutes ‘too much’ may vary depending on the nature of the application and the hardware capabilities of the platform it is running on. A good way to evaluate the battery usage characteristics is to evaluate your application against a ‘control’ application which is usually a ‘well-known application’ in its class. For example, if you write a universal Instant Messaging app for Android, you may want to evaluate its battery usage against that of something like the Nimbuzz IM app or WhatsApp.

There are three main battery power tests that you must perform:

Normal use test: Start on a full battery and use the application for 6-12 hours and measure the battery level at the end of each ½ or 1 hour. You may use an automated testing tool to do this so as to keep the test running for the required time interval. This test will tell you how quickly your application drains the battery when in ‘normal’ use, with all the foreground and background features of the application running normally.

Idle run test: Turn off the screen lock and power saver modes on the device. Then start on a full battery. Keep your application running on its main, home or dashboard screen as appropriate, and measure the battery level at ½ or 1 hour intervals. This test will measure the battery drain due to such things as intentional or unintentional automatic screen refreshes, and due to the background threads or services running in your application.

Screen lock test: Perform the idle run test again but with the device screen in locked mode. This will allow you to test if your application is consuming any CPU and/or network resources (and hence also the battery) when the app is not viewable to the user.

In each case, you may want to plot the battery level against time so as to get a quick visual indication of the overall trend. Perform the same tests for the ‘control’ application in order to see how your application’s battery drain characteristics compare with that of the control application.

While performing the battery tests ensure that no other application is running on the device and turn off the telephone feature so as to avoid receiving a call while the test is underway. If possible also turn off applications such as email and chat clients that tend to run in the background.


Support for operating system versions

Most of the commonly used mobile phone operating systems are designed so as to be “forward compatible”. The OS writers try hard to ensure that as long as your application uses the official developer SDK in a manner prescribed by the SDK documentation, your application that is written for OS version 1.0 will function correctly on version 2.0 and so forth. Of course beyond a point this forward compatibility breaks down and the application creator needs to at least recompile the application for a later OS version. Users tend to upgrade the OS on their mobile devices very frequently. Therefore forward compatibility is a very important thing to ensure in your mobile app. If your app stops working after the user upgrades their mobile device to a newer OS version, the user may simply uninstall the app and not bother to download the newer upgraded version, even if it’s available.

To ensure that your mobile app continues to run on later OS versions you should follow the same conventions and checks as when you write a desktop application so as to ensure compatibility across OS versions: viz:

  • Avoid extensive use of third party libraries,
  • Avoid use of deprecated APIs,
  • Use best practices in using APIs and avoid non-standard usage of API methods,
  • Test your application on all OS versions that you claim to support,
  • If using features specific to an OS, ensure that they degrade or fail gracefully on previous OS versions.
  • Finally, every time your app starts, check whether a newer version is available and ask the user to download the same (or do an automatic update from within the app). Normally, the app store will inform the user via a push notification whenever a newer version of your app is available on the store. However, you may additionally want to proactively perform the version check test anyways upon application start. If you notice that the user is too far behind in the app version from what is the latest version available on the app store, you may want to force the user to upgrade the app before letting them use it.


Media capabilities

The mobile device’s operating system and the device’s hardware that your mobile application runs on, will usually determine what audio and video capabilities your application can provide. For example, which audio/video formats (such as 3GP, MP3, AAC, AAC+ etc) your application supports, whether it will support full HD video or not, whether it can support multi-channel stereo surround sound etc., are all decided by the mobile OS’s capabilities and the characteristics of the device’s hardware.

Before you decide to support specific audio/video features, ensure the following:

  1. Be sure to find out if the version of the mobile operating system that your app will run on, contains support for any specialized media capabilities such as surround sound that your app wants to support. Target your app at only versions at and above that version. In most cases you will also need programmatic access to these features, therefore also ensure that there is SDK support available to operate these features from within your application code.
  2. If the OS supports the feature but there is no out-of-the-box support present for them in the OS’s SDK, ensure that there is strong support available via third party libraries, or be prepared to incur the often substantial cost of rolling out support by writing your own software library.
  3. Finally, ensure that the mobile hardware you are targeting the application for has the hardware capability for running the feature you wish to have.


Sensor characteristics

A large number of phones (even low end feature phones) come with a camera, which can be considered to be a type of sensor. Smart phones and tablet devices typically contain many more kinds of sensors such as GPS, accelerometer, gyroscope, ambient light & proximity sensor and also the ability to connect to an external sensor via USB or Bluetooth. If your mobile application makes use of a sensor to receive information, you need to pay attention to at least the following characteristics of the sensor:

Maximum Sample rate: This is the maximum rate at which your application code can ask the sensor for a useful reading. Sometimes, this value is expressed in Hertz – in this case a measure of readings per second (as with the accelerometer sensor), or in the form of a minimum delay between two consecutive readings. This value may be available via the sensor’s API.

Operating range: Most sensors have a maximum range beyond which they will not provide a useful value. For example for an accelerometer, this value will be specified as +/- X g which means that if your application tries to use the sensor in situations where the g-force is more than +/- X, the sensor will not provide you with a useful measurement.

Sensitivity: This is a measure of how much the sensor’s reading changes in response to changing conditions. Sensitivity information is normally not available directly to application developers. The sensor’s sensitivity also usually changes over the operating range of the sensor, making it a complex parameter to work with. Normally, as long as your application respects the recommended operating range of the sensor, you will get the best possible sensitivity from the sensor.

Accuracy: Be sure to know about the accuracy of the sensor you are using. APIs will sometimes provide this value to you for certain sensors. There are also mobile applications available that a user can install on their mobile device and which will enable the user to calibrate a sensor so as to improve its accuracy. If your mobile application is critically dependant on a particular sensor, you may wish to advise the user to calibrate it before they use your application.

Other sensor characteristics that you may want to be aware of are the operating temperature range and power consumption (e.g. in mA).



iOS Performance Measurement Suite

Android Performance Best Practices

Microsoft Windows Phone Application Analysis


Android: Supporting Multiple Screen

iOS: Supporting High-Resolution Screens In Views

Windows Phone: Multi-resolution apps for Windows Phone 8

Blackberry: Developing applications for different screen sizes

Footnote: This article was first published by PC Quest magazine in two parts in their May and June 2011 issues. Here is the link to the online version:


Everything you wanted to know about mobile technology in one easy to read book

Everything you ever wanted to know about mobile technology in one easy to read book



6 thoughts on “Non-Functional Requirements in Mobile Applications

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s