Differences

This shows you the differences between two versions of the page.

--- dido:public:ra:1.4_req [2021/03/05 18:47]
nick [Specifying Requirements]
+++ dido:public:ra:1.4_req [2021/08/17 14:41] (current)
murphy
@@ Line 1: / Line 1: @@
 ====== 4 Requirements ======
 [[dido:public:ra|return to Reference Architecture]]
-The term requirement first appeared in software engineering in the 1960s.((
+The term [[dido:public:ra:xapend:xapend.a_glossary:r:requirement|requirement]] first appeared in software engineering in the 1960s.((
 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]]
@@ Line 12: / Line 13: @@
 )) 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 needed by a [[dido:public:ra:xapend:xapend.a_glossary:s:stakeholder|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).(([[https://en.wikipedia.org/wiki/Requirement#cite_note-2 | Wikipedia Requirement]]
@@ Line 24: / Line 25: @@
 ))
-===== Governance Requirements Model =====
+  * [[[[dido:public:ra:1.4_req:00_AboutReq]]
-[[dido:public:ra:1.4_req | 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 [[dido:public:ra:xapend:xapend.j_gov_model]]. ((
-Stavros, Robert W. and
-Albrant, Jeremiah;
-__Engineering Governance__,
-SPAWAR,
-October 9, 2007,
-))
-<figure GovModel>
-{{  :dido:public:ra:xapend:screen_shot_2021-02-11_at_10.45.05_am.png?300  |}}
-<caption>General Governance Model</caption>
-</figure>
-  * **Regulation** covers the specification of the requirements of the product or service. This can be either formal government regulation such as U.S. ADA compliance((
-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
-))((
-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 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 =====
-[[dido:public:ra:1.4_req | 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 [[dido:public:ra:xapend:xapend.i_cog_model]]).
-<figure cogModel>
-{{  :dido:public:ra:xapend:screen_shot_2021-02-10_at_6.43.23_pm.png?600  |}}
-<caption>Cognitive Model</caption>
-</figure>
-  * **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 =====
-[[dido:public:ra:1.4_req | 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 {{ref>combReq}}. 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 **Data**x**Regulation** 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.
-<figure combReq>
-{{  :dido:public:ra:screen_shot_2021-03-02_at_10.00.02_am.png?600  | }}
-<caption>Combined Governing and Cognitive Models - Each Cell represents a Role</caption>
-</figure>
-===== Example of a Using the Combined Requirements Model =====
-[[dido:public:ra:1.4_req | Return to Top]]
-The following is a Normative((
-**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 [[dido:public:ra:xapend:xapend.a_glossary:f: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 combReqExmp>
-{{  :dido:public:ra:screen_shot_2021-03-02_at_12.28.41_pm.png?700  | }}
-<caption>Normative Example of the Combined Governing and Cognitive Models</caption>
-</figure>
-Figure {{ref>combReqExmp}} 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 =====
-[[dido:public:ra:1.4_req | 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 {{ref>currCombReq}}, 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 [[dido:public:ra:xapend:xapend.a_glossary:a:agile]] Agile methodology popular on [[dido:public:ra:xapend:xapend.a_glossary:m:missioncritical | 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 {{ref>combReq}}) need to have an Actor (i.e. be completed).
-<figure currCombReq>
-{{  :dido:public:ra:screen_shot_2021-03-02_at_6.58.49_pm.png?400  |}}
-<caption>The current state of DIDO Governance</caption>
-</figure>
-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 {{ref>combReq}} 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 =====
-[[dido:public:ra:1.4_req | 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.
-<figure OneDegreeRule>
-{{  :dido:public:ra:screen_shot_2021-03-04_at_10.04.51_pm.png?500  |}}
-<caption>The One Degree of Freedom Rule</caption>
-</figure>
-===== Specifying Requirements =====
-[[dido:public:ra:1.4_req | Return to Top]]
-Requirements are captured in many ways. In the government realm, this is usually done through codification into laws, regulations and contracts including [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec | Performance]] and [[dido:public:ra:xapend:xapend.a_glossary:c:conformancespecification | Conformance Specification]]. In the corporate realm, it often comes in the form of [[dido:public:ra:1.3_gov:1_legaldocs:1_charter | Charters]], [[dido:public:ra:1.3_gov:1_legaldocs:2_bylaws | Bylaws]] and [[dido:public:ra:1.3_gov:1_legaldocs:3_pp | Policies and Procedures (P&P) ]] and contracts with other entities (see above).
-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((
-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 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.
-Another issue or controversy with specifying requirements is how the statements use imperatives, words like:
-  * [[dido:public:ra:xapend:xapend.a_glossary:s:shall_req]]
-  * [[dido:public:ra:xapend:xapend.a_glossary:w:will_req]]
-  * [[dido:public:ra:xapend:xapend.a_glossary:s:should_req]]
-  * [[dido:public:ra:xapend:xapend.a_glossary:m:must_req]]
-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]]
-))
-  * [[dido:public:ra:xapend:xapend.b_stds:tech:iso:square_qual_rqrmts]]
   * [[dido:public:ra:1.4_req:1_func]]
   * [[dido:public:ra:1.4_req:2_nonfunc]]
+  * [[dido:public:ra:1.4_req:3_assessment]]
 /**=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

DIDO Wiki

User Tools

Site Tools

Differences

Page Tools