Sidebar
Table of Contents
4.3 Non-Functional Requirements
About
Non-functional requirements are often incorrectly assumed rather than being explicitly defined by users. This can lead to problems towards the end of a project as the user expectations for non-functional requirements are not met. Many times, the developers dismiss non-functional requirements as non-testable and therefore not enforceable.
This lack of specificity in non-functional requirements sets the stage for conflicts between the users, system architects, systems engineers, and developers. For example, users expect software to start and run every time it is used however, the non-functional requirement of reliability may never have been explicitly specified.
Users expect new features to be added to a system and tested before they use them. Users assume the software is maintainable without an explicit declaration for “maintainability”. In many ways, they expect it to be an unwritten requirement and or goal. In other words, users expect the system to be analyzable, changeable, stable and testable1). For example, smartphone users will switch apps to other apps if the energy consumed by the app is not efficient. Efficiency is therefore a non-functional requirement. Energy consumption may also be a functional requirements (i.e., An application can not use more than 1040 mW (milli-Watt) per Short Message Service (SMS) message. 2).
The DIDO RA assumes the following non-functional requirements:
Creating a Trade Study
A trade study or trade-off study helps consumers compare products on an equal footing, in other words, to help a consumer compare apples-to-apples so to speak. For example, when comparing cameras it is important to know the resolution metric of the camera. Simplistically, the higher the resolution, the better the camera. Speakers on the other hand might use the highest or lowest speaker frequency responses as a metric. Each metric is unique to the product being evaluated. However, if two cameras each have the same camera resolution, then the additional metric of frequency response might be used as a differentiator.
In the examples above, the camera resolution and frequency responses are specific to the product being evaluated and are referred to as functional requirements. However, there are also a set of requirements with corresponding metrics that capture products non-functional requirements (i.e., sometimes referred to as the “ilities” and include things like maintainability, portability, reliability, etc.)
Often a trade study is based on a collection of Figure of Merits with each FoM representing a single evaluation score for a single function. In the examples above, the camera resolution, or the high frequency response. An entire camera may have a FoM, but it represents the cumulative FoM of each function. A Camera may have other FoMs such as weight, battery life, size, or exchangeable lenses.
