by May 2, 2011 0 comments

Sachin Date, Quinnox Consultancy Services

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 net-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 also. This is due to the following reasons:

Applies To: Business analysts, UI designers, architects, developers & testers
USP:Learn various types of on-functional requirements for mobile apps
Primary Link::
Search Engine Keywords:Non-functional requirements

  • Mobile devices are uniquely constrained in several dimensions such as the processor speed, memory, 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.
  • 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, Wi-Fi), etc.
  • 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, maximum polling interval, etc.
  • 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 capture these requirements as accurately and exhaustively as possible, ensure that the application’s design addresses each requirement, develop the application to meet these requirements, and test the application against each requirement so as to verify compliance.

In the rest of the article, we 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 and memory

When an application is developed to run on a particular software platform such as J2ME, Android, etc, it can in theory be installed and run on any device that supports that platform. However for any given platform, the supported devices could have a very wide range of capabilities in terms of CPU speed and available memory. For example a J2ME application can be theoretically run on a low end feature phone such as the Nokia 3230 with a 123 MHz CPU and 6 MB of RAM as well as the high end Nokia N8 with 600+ MHz CPU and 256 MB RAM. However it has been designed to require a certain minimum CPU power and memory, it might in practice, fail on the Nokia 3230 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 while running it, 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 smartphone platforms:

iPhone: The Instruments tool in the XCode development environment from Apple.

Android: HPROF on Android (hprof output can be generated and analyzed in a variety of different ways. See Android developer documentation for details).

Blackberry: The Blackberry JDE comes with a comprehensive Profile tool

Windows Phone 7: You can use the free CLR profiler or the profiling tools available in Premium versions of Visual Studio. Either way, you will need to first convert your WP7 application to run as a desktop app.

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

Network conditions

There are four things to consider in this area.

Support for different network channels: Mobile devices can communicate with the network on one or more channels such as SMS, USSD, Wi-Fi, GPRS (2G/3G/4G), WAP, etc. Certain functions in your application may not perform well (or at all) on certain channels and protocols. If you wish to support only the high capacity channels such as Wi-Fi, or GPRS on 3G, you will risk shutting out the vast majority of low-end devices which may not support these radios. On the other hand if you do not specify which are the required (or recommended) channels for your application, it may result in the users inadvertently trying your application’s high-bandwidth features on a low-bandwidth channel such as GPRS on 2G or WAP, 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 channels that it is most likely to satisfy the minimum latency requirements on. For features such as streaming media you may want to require the user to switch on a high capacity channel such as Wi-Fi, or GPRS over 3G. Alternately, you may design the feature to degrade or fail gracefully if the user operates it on a low-capacity channel. For example, you may want to serve the media in a low bandwidth format such as 3GP over a 2G/3G channel and in a high bandwidth format such as MP4 over a Wi-Fi channel. A Twitter client, on the other hand can be written to work just as efficiently on a very low capacity channel 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 Wi-Fi. 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 gracefully 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 channel 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 case 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 channel transition: This network condition deals with the mobile application’s behavior when the device transitions from one channel to another. A classic example is when a user walks out of their office building and the device transitions from Wi-Fi to 3G. If there is a transaction underway in the mobile application when this happens, how will the application react to such a transition? It is useful to evaluate the application’s functionality in such situations and design it for a seamless transition to the new channel or for a graceful degradation or failure.

Support for multiple channels: This network condition relates to the mobile application’s behavior when there are multiple network channels active at a time. For example, Wi-Fi, 3G and SMS are all active – which is not at all an unusual situation on a mobile device. For networked features that can operate over multiple channels, it helps to designate a preferred channel(s) and design the feature for detecting the preferred channel (or the next preferred channel) and use that channel over others. For example, you may specify that the application will always prefer the Wi-Fi channel over all others.

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 channel becomes available or unavailable or when the signal strength changes. You should register for such notifications and perform network condition handling inside the network listeners. Also code all network calls defensively via extensive use of exception blocks and return value checking so as to ensure a graceful degradation or failure.

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 OSes, simply terminate your application. In each 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’, a.k.a 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/should function if the application gets background-ed or made dormant while that feature is executing.

Screen resolutions and screen form factors

An application that is designed for the 240 x 320 pixels resolution screen of the Samsung Metro multimedia phone will look tiny on the high resolution 480 x 360 pixels display of the Blackberry Bold 9780 smart phone. The text will likely be too small to read, the images may look too tiny to decipher and the widgets and controls will be too small to use. Overall the application will be mostly useless even though, technically it ‘functions correctly’. Similarly, an application designed for a high-resolution (high DPI) screen will have a major part of its UI go off screen on a low DPI screen phone, leading to quite an annoying experience at best.

Even if you decide to develop for only one platform such as Android or Blackberry, there is still a large set of screen resolutions to consider. For example, Blackberry devices come in at least five different screen resolutions and Android devices — given the open nature of the platform — come in dozens more.

Hence it’s important to keep a set of target screen resolutions in mind while designing the user interface of a mobile application. If it’s not practical to enumerate the complete set of supported screen resolutions, try to identify a reasonable range of values, for e.g. 400 to 500 pixels along the short dimension and 600 to 850 pixels along the long dimension. Then identify a small set of devices, which taken together, will constitute a representative set of screen resolutions lying this in range, and then design the UI of the application for these devices.

Normally you will find that the following kinds of changes will need to be done 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.

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 (slider keyboard) 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, it’s generally a good idea to add this support for all screens in the application and not just some of the screens so as prevent a usability surprise.

In the next series, we’ll talk about battery usage, support for OS versions, media capabilities and sensor characteristics.

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.