6.05 Formally Define Non-Functional Requirements

Return to Recommendations

The OMG members recommend the Federal Reserve invest Research Development Test & Evaluation (RDT&E) Funding in defining, developing and perfecting the Non-functional requirements that are acceptable to the Federal Reserve and its Stakeholders.

Non-Functional Requirements are often incorrectly assumed rather than 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 Short Message Service (SMS) message. 2) Sai Suren Kumar Kasireddy and Vishnuvardhan Reddy Bojja, Measurements of Energy Consumption in Mobile Applications with respect to the quality of Experience, School of Computing, Blekinge Institute of Technology, 37179 Karlskrona, Sweden, March 2012, Accessed: 10 November 2020, https://www.diva-portal.org/smash/get/diva2:829733/FULLTEXT01.pdf .

It is recommended the Federal Reserve consider reviewing and specifying values for each of these Non-FUnctional Requirements.

1. Portability

2. Reliability

3. Maintainability

4. Security

5. Manageability

6. Usability

7. Performance

8. Interoperability

9. Elasticity

10. Scalability