4 Requirements

return to Reference Architecture

The term requirement first appeared in software engineering in the 1960s.1) Boehm, Barry (2006). A view of 20th and 21st century software engineering. ICSE '06 Proceedings of the 28th international conference on Software engineering. University of Southern California, University Park Campus, Los Angeles, CA: Association for Computing Machinery, ACM New York, NY, USA. pp. 12–29. ISBN 1-59593-375-1. Retrieved January 2, 2013. http://dl.acm.org/citation.cfm?id=1134288

The Business Analysis Body of Knowledge® version 2 from IIBA (BABOK),2) 1.3 Key Concepts - IIBA | International Institute of Business Analysis“. www.iiba.org. Retrieved 2016-09-25. http://www.iiba.org/babok-guide/babok-guide-v2/babok-guide-online/chapter-one-introduction/1-3-key-concepts.aspx defines a requirement as having one or more of the following characteristics:

A condition or capability needed by a stakeholder to solve a problem or achieve an objective.A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.A documented representation of a condition or capability as in (1) or (2).3) Wikipedia Requirement This definition is based on IEEE Standardized vocabulary.4) IEEE/ISO/IEC 24765-2010 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Vocabulary , 2010-02-02, published 15 December 2015, IEEE, [https://standards.ieee.org/standard/24765-2010.html]]

Governance Requirements Model

Return to Top

In addition to this definition, requirements can be applied to various aspects of a project from a governance perspective. There are three different aspects of governance: Regulation, Execution and Compliance (See xapend.j_gov_model. 5) Stavros, Robert W. and Albrant, Jeremiah; Engineering Governance, SPAWAR, October 9, 2007,

General Governance Model

Regulation covers the specification of the requirements of the product or service. This can be either formal government regulation such as U.S. ADA compliance6) ADA Website Accessibility Under Title II of the Americans with Disability Act (ADA) - ADA Best Practices Tool Kit for State and Local Governments, Website Accessibility Under Title II of the ADA, Chapter 5, https://www.ada.gov/pcatoolkit/chap5toolkit.htm 7) Accessibility of State and Local Government Websites to People with Disabilities, U.S. Department of Justice, Civil Rights Division, Disability Rights Section https://www.ada.gov/websites2.htm , or it can be project specific such as the contract or the technical specification of a contract or can be as detailed as the steps defined for a particular test plan.Execution covers the lifecycle of a product or service being governed (i.e., design, building, maintenance, etc). This covers the functional and non-functional requirements of the product or service and can be in terms of static or dynamic compliance pointsCompliance covers the oversight of the product or service being governed. This covers the not only the product or service itself but also the process of Regulation and Execution. For example, is the contract or technical specification well written and maintained throughout the lifecycle of the product or service. Understanding requirements is an important part of specifying, building, using and maintaining any product. And when the System is Distributed on multiple machines, supporting multiple stakeholders the need for the proper governance is essential. The requirements must cover all three aspects of governance. For example, there can be a requirement that is expressed in the regulatory aspect which requires reporting of information. The Compliance aspect will have a corresponding requirement that validate and verifies the reporting of the information. These are then also reflected in the Execution Aspect that has to have processes and systems designed to collect and report the proper data.

Cognitive Requirements Model

Return to Top

In addition to the definition of a requirement and the specification of the requirements at each of the Governance Aspects, there is a need to further refine the requirements according to the level of specificity of the requirement. There are five different layers to specificity which are based upon the layers of the Cognitive Model. (See xapend.i_cog_model).

Cognitive Model

Wisdom - An extrapolative and nondeterministic, non-probabilistic concept which is built upon Understanding concepts.Understanding - An interpolative and probabilistic concept that reflects Wisdom conceptsKnowledge - A concept relating appropriate collection of Information concepts together, such that it's intent is usefulInformation - A concept aggregating data concepts together, in other words, Data that has been given meaning by way of relational connectionData - Data that is a raw concept; it simply exists and has no significance beyond its existence (in and of itself). It is the basis upon which Information concepts are builtThe flow between the cognitive layers is bidirectional and can have many-to-many relationships. For example, any particular Wisdom concept can be associated with any number of Understanding concepts. The inverse is also true; Understanding concepts can also be used to help support any number of Wisdom Concepts.

Combined Requirements Model

Return to Top

In order to be effective, it is best to combine the Governance and the cognitive models together. The results look something like Figure . Each cell in the overlaid models represents a single ROle or area of consistent governance providing some context for the requirements. For example, at the DataxRegulation cell, there is specific data that is required to be collected according to the regulations. For example, there is a regulation that requires a bank to collect taxpayer IDs for each account. During the Execution aspect (i.e., the Bank's policies and Procedures) the taxpayer ID is collected, the specific bank actually collects and records the taxpayer ID. During the Compliance aspect, there is a requirement to verify that each Bank actually has a taxpayer id with each account. This consistency in governance can be repeated for each row (i.e., Wisdom, Understanding, Knowledge, Information and Data) and for each column (i.e., Regulation, Execution and Compliance).

If any of the Roles (i.e., cells have no requirements, the governance is incongruent and can lead to a potential flaw or hole in the governance which is vulnerable to exploitation.

Combined Governing and Cognitive Models - Each Cell represents a Role

Example of a Using the Combined Requirements Model

Return to Top

The following is a Normative8) Normative - are statements based on opinions about what should happen. They are subjective rather than objective because they involve value judgment about what is right and what is wrong. example of using the Combined Requirements Model to review requirements for any Federal Deposit Insurance Corporation (FDIC) regulation. The actual data may be invalid or based on some convenient assumptions but is included as an example of how the combined model can be used. ]

In the example, the regulation starts with Wisdom. Within Regulation, the Wisdom is the U.S. Code of Federal Regulations. Although we can make light of Federal Regulations as being Wisdom try and think about it this way: “when working within the confines of a government, it is not wise to ignore or marginalize regulation”. When working within the banking industry, Understanding is knowing that there are U.S. Federal Regulations that pertain to banking in general. Knowledge is to know the specific laws that pertain to the Area-of-Interest (AoI), in this case banking and Federal Insurance covering banking(i.e, FDIC). There is knowledge that is provided within the FDIC legislation the that specifies which laws must be followed by an institution wanting to be insured (i.e., Section 18 of the FDIC regulations). Finally, at the Data layer, there are specific rules about what needs to be reported and how it is to be reported.

Normative Example of the Combined Governing and Cognitive Models

Figure roughly lays out a “straw man” of what the overall combined governance could be like. Within each governing Aspect and within each Cognitive layer there are specific requirements that covers that Role (i.e., cell).

The Current State of DIDO Requirements

Return to Top

The current state of DIDO governance is basically “Execution Centric”. This basically means that the governance is being developed by those that are actually creating the DIDO platforms (i.e., products). Although this approach may seem efficient as a way to overcome bureaucratic obstacles, it ultimately leads to failures in the end results. In Figure , the Execution is represented as a pyramid. This represents the bottom up approach used to developed most DIDO platforms today and is a reflection of the Agile Model Agile methodology popular on non-Mission Critical Systems.

As cryptocurrencies attempt to become financial instruments and represent actual national currencies, they are essentially positioning themselves as Mission Critical for the nations, their economies and their citizens. Therefore, to be successful, they must be governed properly which implies that each Role (i.e., cell) within the combined Governing and Cognitive models (See Figure ) need to have an Actor (i.e. be completed).

The current state of DIDO Governance

This is not unusual when a new disruptive product or service comes along, it is to be expected. However, in order to mature to the next level and gain wider acceptance, the product or service needs to mature its governance. The Combined Governing and Cognitive Model depicted in Figure offers a good framework that can act as a checklist of what is done and what needs to be done.

The relationship between the Roles (i.e., cells) in a many-to-many relationship that is not only bidirectional in up and down the cognitive layers but also between the governance aspects.

One Degree of Freedom Rule

Return to Top

Probably one of the most important rules is to not skip roles. Each and every role is important and all too often, in the name of expedience, attempts are made to short circuit the model and skip roles. For example, trying to specify in “regulatory wisdom” how to inspect products built during execution. This does not however mean that the roles are completely isolated. Within each of the Governance Aspects, the Cognitive Model’s hierarchy still applies. This can be summarized as the “one degree of freedom” rule.

The One Degree of Freedom Rule

Specifying Requirements

Return to Top