====== 6.02 Move from Desirements to Requirements ====== |< 100% >| | [[cbdc:public:cbdc_omg:04_doc:90_recommend:start| Return to Recommendations ]] | Provide Feedback | 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(( A **Desirement** is a blended word combining the word **Desire** and **Requirement**. **Desirement** is something that is desired, but not absolutely required and is often used to caption the capabilities of a product or system before it has reached the formal requirements phase. Source: [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:d:desirement | Desirement]] )) considerations categorized according to the four major objectives identified in the **White Paper**: * [[cbdc:public:cbdc_omg:04_doc:12_summary:start#benefits| Benefit Considerations]], * [[cbdc:public:cbdc_omg:04_doc:12_summary:start#policy_considerations| PolicyConsiderations]], * [[cbdc:public:cbdc_omg:04_doc:12_summary:start#risks| Risk Considerations]] * [[cbdc:public:cbdc_omg:04_doc:12_summary:start#design| Design Considerations]] The next step is to start capturing real Requirements(( A **Requirement** specifies a capability or [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:condition|condition]] that must (or should) be satisfied. A requirement may specify a function that a system must perform or a [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] condition a system must achieve. )) for a U.S. CBDC. The OMG DIDO-RA has an extensive discussion on [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:00_aboutreq:07_reqspec | Specifying Requirements]] which is particularly appropriate for Distributed Systems. [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:r:requirement|Requirements]] are captured in many ways. In the government realm, this is usually done through codification into laws, regulations, and contracts including [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:p:performancespec | Performance]] and [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:c:conformancespecification | 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:g:governance | Governance]] Statement based on an __Engineering Governance__ Model developed at US Navy SPAWAR(( Stavros, Robert W. and Albrant, Jeremiah; __Engineering Governance__, SPAWAR, October 9, 2007, )) 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.b_stds:tech:ietf:2119 | RFC2119 - Key words for use in RFCs to Indicate Requirement Levels]], words like: * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:shall_req | Shall (Requirement)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:m:must_req | Must (Requirement)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:w:will_req | Will (Requirement)]] * [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:xapend:xapend.a_glossary:s:should_req| Should (Requirement)]] There is an excellent reference in __How to Write and Exceptionally Clear Requirements Document__(( QRA, __How to Write and Exceptionally Clear Requirements Document__, Accessed 5 March 2021, [[https://qracorp.com/write-clear-requirements-document/#elementor-toc__heading-anchor-1]] )) 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 [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra | Distributed Immutable Data Objects - Reference Architecture (DIDO-RA)]] provides a starting point for conducting such an evaluation. [[https://www.omgwiki.org/dido/doku.php?id=dido:public:ra:1.4_req:2_nonfunc#creating_a_trade_study | Creating a Trade Study]]. Obviously, the DIDO-RA Trade Study is to be used as a reference and perhaps a starting point. /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /* To add a discussion page to this page, comment out the line that says ~~DISCUSSION:off~~ */ ~~DISCUSSION:on|Outstanding Issues~~ ~~DISCUSSION:off~~