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 Desirement¹⁾ considerations categorized according to the four major objectives identified in the White Paper:

• Benefit Considerations,
• PolicyConsiderations,
• Risk Considerations
• Design Considerations

The next step is to start capturing real Requirements²⁾ for a U.S. CBDC. The OMG DIDO-RA has an extensive discussion on Specifying Requirements which is particularly appropriate for Distributed Systems.

Requirements are captured in many ways. In the government realm, this is usually done through codification into laws, regulations, and contracts including Performance and Conformance Specification.

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 SPAWAR³⁾ is defined as atomic, succinct, absolute, and definitive in nature. It contains specific instructions which can be validated through observation, measurement, or testing.

• Atomic - A Governance Statement only addresses a single topic. Indicators of non-atomic guidance are the use of highly complex sentences, multiple sentences, or conjunctions such as and, or, etc.
• Succinct - A Governance Statement is short and to the point. The definition of terms or caveats that explain when a statement is applicable is not acceptable as part of the Governance Statement. Indicators of non-succinct statements are the use of words or expressions such as: consider, when possible, if, etc.
• Absolute - A Governance Statement is valuable with one or more non-subjective questions. Indicators of non-absolute statements are those which are subject to the interpretation of the evaluator. For example, “All menus must be user-friendly“. No one produces menus that they feel are user-hostile.
• Definitive - A Governance Statement is precisely worded and explicit in nature. Their words, terms, and expressions need to be defined and not subject to interpretation. Indicators of non-definitive guidance are words that are not intuitively obvious to an outside reader. Some words that are examples of non-explicit words are: object, service, and function.

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:

• Shall (Requirement)
• Must (Requirement)
• Will (Requirement)
• Should (Requirement)

There is an excellent reference in How to Write and Exceptionally Clear Requirements Document⁴⁾ 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.