Non-Functional Requirements in Mobile Apps

On mobile devices, the battery is a scarce and valuable resource. On a mobile phone in particular, 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 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 IM client for Android, you may want to evaluate its battery usage against that of the Meebo, or Nimbuzz applications.

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 and keep the 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 test (b) 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 the battery) when it's not viewable to the user. In this case, to avoid unnecessary battery drain, you should pause / stop any kind of screen activity such as automatic screen refreshes and also pause / stop background thread or services in this mode.

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.

Note that two major sources of battery drain are CPU usage and network usage (such as polling the 3G, WiFi or the GPS radio at regular intervals). Finally ensure that no other application is running on the device while performing the battery tests 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 OSes are designed so as to be backward compatible. The OS writers tend to ensure that as long as your application uses the official developer SDK in a manner prescribed by the SDK documentation, your application written for OS version 1.0 will function correctly on version 2.0 and so forth. The exception is when you use deprecated APIs. Follow the same conventions and checks as when you write a desktop application so as to ensure compatibility across OS versions: viz:

1. Avoid extensive use of third party libraries
2. Avoid use of deprecated APIs
3. Use best practices in using APIs and avoid non-standard usage of API methods
4. Test your application on all OS versions that you claim to support and
5. If using features specific to an OS, ensure that they degrade or fail gracefully on previous OS versions.

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 can play content in, whether it will support full HD video or not, whether it can support multi-channel stereo surround sound, etc, are all decided by the OS capabilities and the device hardware. Before you decide to support specific audio/video features, ensure the following:

1. The mobile OS versions at which you are targeting your application contain support for these features. 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 isn't out-of-the-box support available for them in the 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 in your own 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. Smartphones 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 Hz — a measure of readings per second (as with the accelerometer sensor) or as minimum delay between two consecutive readings. This value may be available via the sensor API. For example in the Android SDK, you may call the Sensor.getMinDelay() to get this value.

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 developers and the sensitivity 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. For example, in the iPhone SDK, you can get the radial accuracy around the current location reported by the GPS sensor. There are also mobile applications available that a user can install on their mobile device and which will help the user 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 app. Other sensor characteristics that you may want to be aware of are operating temperature range and power consumption (e.g. in mA).

NFR Cheatsheet

Now that you have gone through each requirement in detail, here's a quick checklist to refer to while capturing requirements or creating the app's design or while developing and testing your mobile app:

Click on the image to enlarge

Click on the image to enlarge

Conclusion

In this article we have seen how a vast range of non-functional requirements can have a direct impact on the operating characteristics and hence the ultimate success or failure of a mobile application in a user's hands.

After identifying and defining these requirements it is important to reflect them in the unit and system test cases and scenarios so that all through the application's software development lifecycle, the application gets tested and verified against these requirements. Project estimators will also note that handling these requirements correctly will add to the project's effort and cost and may impact the schedule — a necessary addition so as to ensure a high quality application that will succeed in the real world.

Note: If you'd like a soft copy of this checklist, please mail us at pcquest@cybermedia.co.in with "mobile app check list, June 2011" in the subject line. Don't forget to include your name, designation and company name in the mail.