Sidebar
This is an old revision of the document!
Table of Contents
4 Requirements
return to Reference Architecture
The term requirement first appeared in software engineering in the 1960s.1)
The Business Analysis Body of Knowledge® version 2 from IIBA (BABOK),2) 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)
This definition is based on IEEE Standardized vocabulary.4)
Governance Requirements Model
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)
- 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)7), 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 points
- Compliance 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
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).
- Wisdom - An extrapolative and nondeterministic, non-probabilistic concept which is built upon Understanding concepts.
- Understanding - An interpolative and probabilistic concept that reflects Wisdom concepts
- Knowledge - A concept relating appropriate collection of Information concepts together, such that it's intent is useful
- Information - A concept aggregating data concepts together, in other words, Data that has been given meaning by way of relational connection
- Data - 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 built
The 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
In order to be effective, it is best to combine the Governance and the cognitive models together. The results look something like Figure 3. 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.
Example of a Using the Combined Requirements Model
The following is a Normative8) 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.
Figure 4 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
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 5, 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 3) need to have an Actor (i.e. be completed).
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 3 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
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.
Specifying Requirements
Requirements are captured in many ways. In the government realm, this is usually done through codification into laws and regulations. In the corporate realm, it often comes in the form of Charters, Bylaws and Policies and Procedures (P&P) .
Regardless of where the requirements are captured or by what organizations, they can n general be considered governing statements. The following are some ghuidance on how to write healthy governing statements and consequently also requirements.
A Governance Statement based on an Engineering Governance Model developed at US Navy SPAWAR9) 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 use of highly complex sentences, multiple sentences or conjunctions such as and, or, etc.
- Succinct A Governance Statement are short and to the point. The definition of terms or caveats that explain when a statement is applicable are 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 evaluatable 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 menu's 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.
One of requirements engineering’s greatest debates is on the use of imperatives, words like:
