Basics of Nonfunctional Requirements for iOS Apps
Nonfunctional requirements (NFR) provide guidelines on how to build an iOS app correctly (such requirements are also known as quality requirements or design requirements). Let’s start with a categorization and examples of NFR. Say that you’re building a wayfinding app that will plot a route from one location to another. Here are the general categories of NFR and examples for each, specifically in the context of the wayfinding app:
Performance: This is essentially how fast your app works. A performance requirement for the wayfinding app could be that it plot a route in less than 20 seconds.
Responsiveness: This requirement ensures that your app is ready to respond to a user’s input or an external event no matter what it’s doing currently. For example, does your app allow the user to switch to another function even while it’s busy calculating a route.
Scalability: Scalability is how well your app deals with increasing use, or size of data. For example, you might require that the time your app takes to plot a route is linear with the distance between the two points.
Usability: This relates to how easily people can use your app. A measure of usability could be the time it takes for end users to become familiar with your app’s functions, without training or help.
Reliability: This is the percentage of time that your app works correctly to deliver the desired results, despite potential failures in its environment. For the wayfinding app, it’s the percentage of time that it correctly plots the route, given that the network may not be available or that bandwidth may be limited.
You might require that your app work with a reliability of 99 percent, which means that in a given 24-hour day, it can fail to plot a route for no more than one percent of the day, or about 15 minutes.
The term availability can be used interchangeably with reliability, because most people are more likely to understand that word.
Security: Say that your app saves all the previous routes it calculated and lets you reuse a saved route rather than recalculate it.
If security isn’t a requirement, you can store all app data in unencrypted files and on the SD card. If security is an issue, however, you can encrypt the files and store them in the app’s private file area so that their content isn’t easily accessible and so that they’re deleted when the app is uninstalled.
Modifiability: This requirement governs how easily your app may be changed. For the wayfinding app, this requirement might state that the app can use more than one map without needing to be rebuilt.
Maintainability: This relates to the ease at which your app finds bugs and fixes them. For example, if a map is incorrect, can you fix the problem simply by downloading a correct map or do you have to purchase the next version of the app.
Cost is also often important. When you build an app, you must decide which nonfunctional requirements apply to your app. You also have to refine your NFRs so that you can test them. For example, for a performance NFR, you must be able to measure the speed of your application at the appropriate places (such as while the screen appears).
Certain nonfunctional requirements are especially important for mobile devices, such as performance and responsiveness.
Don’t attempt to meet all possible nonfunctional requirements in an app. Why spend resources implementing features that users won’t value? Instead, define and, wherever applicable, quantify the extent to which you want to meet the NFR. Also, NFR always involves trade-offs. Meeting a single nonfunctional requirement can sometimes cause your app not meet another one.
For example, performance and security are often at cross-purposes. Increased security is often implemented by encrypting and decrypting stored data. However, having to decrypt data in order to use it, and encrypt it after the app is done using it takes time, thereby reducing the app’s performance. The trick with meeting NFRs is to find the right balance.