The OMG's CBDC WG members recommend the Federal Reserve define a task for developing and perfecting the Requirements for the U.S. CBDC.
The White Paper did a good job of describing what a U.S. CBDC could be and identifying, in prose form, the issues and expectations surrounding a CBDC. The OMG's CBDC WG members took the first step in trying to formalize these issues and expectations as a set of Desirement1) considerations categorized according to the four major objectives identified in the White Paper:
The next step is to start capturing real Requirements2) for a U.S. CBDC. The OMG DIDO-RA has an extensive discussion on Specifying Requirements which is particularly appropriate for Distributed Systems.
Regardless of where the requirements are captured or by what organizations, they can in general be considered governing statements. The following are some guidance on how to write healthy governing statements and consequently also requirements.
A Governance Statement based on an Engineering Governance Model developed at US Navy SPAWAR3) is defined as atomic, succinct, absolute, and definitive in nature. It contains specific instructions which can be validated through observation, measurement, or testing.
Another issue or controversy with specifying requirements is how the statements use imperatives originally defined in RFC2119 - Key words for use in RFCs to Indicate Requirement Levels, words like:
There is an excellent reference in How to Write and Exceptionally Clear Requirements Document4) and it is up to the Federal Reserve and the CBDC effort to settle on the form of requirements.
One of the best ways to analyze Non-Functional Requirements is to perform an evaluation of proposed or existing systems, subsystems, components, etc. The Distributed Immutable Data Objects - Reference Architecture (DIDO-RA) provides a starting point for conducting such an evaluation. Creating a Trade Study. Obviously, the DIDO-RA Trade Study is to be used as a reference and perhaps a starting point.