Sidebar
6.05 Formally Define Non-Functional Requirements
The OMG's CBDC WG members recommend the Federal Reserve define a task for 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). 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).
It is recommended the Federal Reserve consider reviewing and specifying values for each of these Non-FUnctional Requirements.
1. Portability
2. Reliability
4. Security
6. Usability
7. Performance
9. Elasticity
10. Scalability
