4.3 Non-Functional Requirements

Return to Requirements

About

Return to Top

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) Prolifics Testiing, Achieving Requirements Testability, 10 October 2018, Accessed 10 November 2020, https://www.prolifics-testing.com/news/achieving-requirements-testability . 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 SMS message. 2) Sai Suren Kumar Kasireddy and Vishnuvardhan Reddy Bojja, Measurements of EnergyConsumption in MobileApplications with respect toQuality of Experience, School of Computing, Blekinge Institute of Technology, 37179 Karlskrona, Sweden, March 2012, Acessed on 10 November 2020, https://www.diva-portal.org/smash/get/diva2:829733/FULLTEXT01.pdf .

Assessing the Alternatives

Return to Top

Non-Functional requirements are by nature, hard to measure and hard to assess for compliance. The complexity of the assessment problem is compounded because products or systems as well as the environment they operate within are not static. Therefore, an assessment that is done today, may no longer be accurate in the future. When assessing Commercial Off-The-Shelf (COTS), Government Off-The-Shelf (GOTS), Modified Off-The-Shelf (MOTS) or NATO Off-The-Shelf (NOTS) or the inclusion of Open Source Software (OSS) the potential for changes (particularly enhancements) needs to be assed also.

One way to accomplish this is to provided an assessment which is weighted for the “ease of implementation” for new features. For example, a system or product may not have done much to support 4.3.4.1 Confidentiality, but the vendor of the product must determine that it is an easy upgrade to add it to the product. On the other hand, the support for Confidentiality might be extremely difficult. Sometimes, the feature may be easy to solve but requires time and money to accomplish. As a potential stakeholder, they can direct resources to help overcome this shortfall.

An overview of the Assessment Process

The Vendor's Assessment

Return to Top

The Vendor's assessment team must discuss with each other and use the DIDO-RA workbook to determine the weight of the requirement.

The Vendor's Assessment Team Activities

This is done by weighing each property, related to the Requirement, by giving a score between 1-100. 1 representing an easy development process, and 100 being impossible now, merely very difficult in a couple years.

Publish the assessment, and notify the vendor..

The Stakeholder's Focus Group

Return to Top

The Vendor's stakeholder assessment team must create a focus group of stakeholder's. This group is used in conjunction with the stakeholder assessment team to determine the importance of the Requirement and potentially direct more or less resources to this area.

The Stakeholder's Focus Group Activities

This is done by rating each property related to the requirement with either a '+' option representing a 'more important' status, or a '-' option representing a 'less important' status. On the Coefficient sheet choosing a '+' will cause a '-' to be put in the opposite cell in the table. EX: cell(1,2)='+' means cell(2,1)='-'. Also properties can't be compared to themselves, these cells have lines drawn through them to represent this.

At the end of filling out each table. Each row is counted for '+', the number of '+' in a row is equal to the coefficient for that property.

When completed publish the assessment and notify the stakeholder's.

The Stakeholder's Assessment Team

Return to Top

Once the assessments and importance coefficients are set, the DIDO-RA is passed to the stakeholder's assessments team. Here they will take the factor weighting and the coefficients to create the Figure of Merit (FoM). These figures are then published to assessment reports that are given to the Vendor, and/or given back to the stakeholder's assessment team for further review.

The Stakeholder's Assessment Team Activities

In the DIDO-RA workbook after the Coefficient/Factor Weight sheets are filled out, those values, associated with the requirement, are then sent to the corresponding Requirement Sheets in the workbook.

This data is then used to create the FOM(Figures of Merit). The formula to calculate the FOM = (C1)(FW1) + (C2)(FW2)+ (Cn)(FWn) for each property. These Property FOMs are then added into a Requirement FOM.

NOTE: Comparing Requirement FOMs from one vendor to another will cause a skewed comparison. To compare between vendors you must break the Requirement FOMs into its components. The components of Requirement FOM are the Property FOMs.

The Stakeholder's Award Team

Return to Top

The stakeholder's receive the Assessment Reports as well, if they deem the results satisfactory they will choose the product just reviewed.

The award is usually your software is chosen to be used.

Creating a Trade Study

Return to Top

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.