dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability [2021/06/16 11:46] nick [DDS Specifics] |
dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability [2021/10/03 13:23] (current) 50.19.247.197 ↷ Links adapted because of a move operation |
||
|---|---|---|---|
| Line 5: | Line 5: | ||
| [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability| Return to Top]] | [[dido:public:ra:1.4_req:2_nonfunc:20_maintainability:testability| Return to Top]] | ||
| - | //[[dido:public:ra:xapend:xapend.a_glossary:t:testability]]//, //Testable//, //Testing// and //Test// are not synonyms for each other. Just because a system or program is undergoing //testing// using various //tests// does not necessarily mean that the system or program is actually //Testable//. The following table provides definitions for each of these four terms, associates each with the appropriate Structured Assurance Case, as well as, level in the Cognitive Model's Science and Knowledge Management [[dido:public:ra:xapend:xapend.i_cog_model|DIKW]] (Data, Information, Knowledge and Wisdom) pyramid. | + | //[[dido:public:ra:xapend:xapend.a_glossary:t:testability]]//, //Testable//, //Testing// and //Test// are not synonyms for each other. Just because a system or program is undergoing //testing// using various //tests// does not necessarily mean that the system or program is actually //Testable//. The following table provides definitions for each of these four terms, associates each with the appropriate Structured [[dido:public:ra:xapend:xapend.a_glossary:a:assurance|Assurance]] Case, as well as, level in the Cognitive Model's Science and Knowledge Management [[dido:public:ra:xapend:xapend.i_cog_model:start|DIKW]] (Data, Information, Knowledge and Wisdom) pyramid. |
| ^ DIKW pyramid level ^ Structured Assurance Case ^ Term ^ Description ^ | ^ DIKW pyramid level ^ Structured Assurance Case ^ Term ^ Description ^ | ||
| Line 13: | Line 13: | ||
| Other functional requirements are not so definite, but expressed in terms of a range of acceptable values. For example, a [[dido:public:ra:xapend:xapend.a_glossary:g:gui]] will respond in less than 5 seconds or the heart pulse rate is between 35 to 200 beats per minute. | Other functional requirements are not so definite, but expressed in terms of a range of acceptable values. For example, a [[dido:public:ra:xapend:xapend.a_glossary:g:gui]] will respond in less than 5 seconds or the heart pulse rate is between 35 to 200 beats per minute. | ||
| - | In contrast, [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|non-functional requirements]] are generally more abstract: they relate to the __quality__ of the system or program being delivered (i.e., portable, reliable, maintainable, securable, scalable, etc.) and are usually not directly measurable or observable but must be inferred from characteristics found in the delivered system's or product's architecture, design and implementation. These kinds of requirements require ways to characterize assurance and are specified in terms of claims (i.e., the system has a [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability | High Availability]]), [[dido:public:ra:xapend:xapend.a_glossary:s:subclaim|sub-claims]], and [[dido:public:ra:xapend:xapend.a_glossary:a:argument|arguments]] (i.e., [[dido:public:ra:xapend:xapend.a_glossary:a:availability]] can be predicted using a [[dido:public:ra:xapend:xapend.a_glossary:m:mttr]] of 5 minutes, 15 seconds or less of [[dido:public:ra:xapend:xapend.a_glossary:d:downtime|downtime]] in a year for all components). These kinds of requirements are generally specified in [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec]]. These specifications tend to focus on hardware specifications; however, [[dido:public:ra:xapend:xapend.a_glossary:p:performance|performance]] specifications can also capture non-functional metrics. | + | In contrast, [[dido:public:ra:xapend:xapend.a_glossary:n:nonfuncreq|non-functional requirements]] are generally more abstract: they relate to the __quality__ of the system or program being delivered (i.e., portable, reliable, maintainable, securable, scalable, etc.) and are usually not directly measurable or observable but must be inferred from characteristics found in the delivered system's or product's architecture, design and implementation. These kinds of requirements require ways to characterize [[dido:public:ra:xapend:xapend.a_glossary:a:assurance|assurance]] and are specified in terms of [[dido:public:ra:xapend:xapend.a_glossary:c:claim|claims]] (i.e., the system has a [[dido:public:ra:1.4_req:2_nonfunc:14_reliability:02_availability | High Availability]]), [[dido:public:ra:xapend:xapend.a_glossary:s:subclaim|sub-claims]], and [[dido:public:ra:xapend:xapend.a_glossary:a:argument|arguments]] (i.e., [[dido:public:ra:xapend:xapend.a_glossary:a:availability]] can be predicted using a [[dido:public:ra:xapend:xapend.a_glossary:m:mttr]] of 5 minutes, 15 seconds or less of [[dido:public:ra:xapend:xapend.a_glossary:d:downtime|downtime]] in a year for all components). These kinds of requirements are generally specified in [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec]]. These specifications tend to focus on hardware specifications; however, [[dido:public:ra:xapend:xapend.a_glossary:p:performancespec|performance specifications]] can also capture non-functional metrics. |
| * **Note** Testability metrics are not limited to operational systems or programs but can also take advantage of system or program level artifacts that describe architecture, design, discussion papers, outside references, software and executables. | * **Note** Testability metrics are not limited to operational systems or programs but can also take advantage of system or program level artifacts that describe architecture, design, discussion papers, outside references, software and executables. | ||
| Line 24: | Line 24: | ||
| [[https://www.prolifics-testing.com/news/achieving-requirements-testability]] | [[https://www.prolifics-testing.com/news/achieving-requirements-testability]] | ||
| )) that can make it difficult to determine if requirements are actually "testable": | )) that can make it difficult to determine if requirements are actually "testable": | ||
| - | * **Noise:** Text containing no information relevant to any aspect of the problem. For example, a requirement on a standalone application that does not need access to the [[dido:public:ra:xapend:xapend.a_glossary:e:ethernet|Ethernet]] | + | * **Noise:** Text containing no information relevant to any aspect of the problem. For example, a requirement on a standalone [[dido:public:ra:xapend:xapend.a_glossary:a:application|application]] that does not need access to the [[dido:public:ra:xapend:xapend.a_glossary:e:ethernet|Ethernet]] |
| * The system shall conform to IPV6 ... | * The system shall conform to IPV6 ... | ||
| * **Silence:** A feature not covered by any text within the Requirements documents or specifications | * **Silence:** A feature not covered by any text within the Requirements documents or specifications | ||
| * **Over-specification:** Description of the solution rather than the problem. For example, | * **Over-specification:** Description of the solution rather than the problem. For example, | ||
| - | * The [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]] must use blockchain. (blockchain is one of many distributed technologies used by Cryptocurrencies) | + | * The [[dido:public:ra:xapend:xapend.a_glossary:d:distsystem|distributed system]] must use [[dido:public:ra:xapend:xapend.a_glossary:b:blockchain|blockchain]]. (blockchain is one of many distributed technologies used by Cryptocurrencies) |
| * The system must use a checkbox to select the appropriate option | * The system must use a checkbox to select the appropriate option | ||
| * **Contradictory:** Mutually incompatible descriptions of the same feature. For example, | * **Contradictory:** Mutually incompatible descriptions of the same feature. For example, | ||
| Line 44: | Line 44: | ||
| * **Jigsaw puzzles:** Requirements distributed across a document and then cross-referenced | * **Jigsaw puzzles:** Requirements distributed across a document and then cross-referenced | ||
| * **Duckspeak:** Requirements included merely to conform to standards that have no or little relationship to the problem at hand. Perhaps required as part of a boilerplate. | * **Duckspeak:** Requirements included merely to conform to standards that have no or little relationship to the problem at hand. Perhaps required as part of a boilerplate. | ||
| - | * **Terminology invention:** “user input/presentation function”; “airplane reservation data validation function”. For example, | + | * **Terminology invention:** “user input/presentation function”; “airplane reservation data [[dido:public:ra:xapend:xapend.a_glossary:v:validation|validation]] function”. For example, |
| * The system shall use a double blind logged journal entry (huh, what is that?) | * The system shall use a double blind logged journal entry (huh, what is that?) | ||
| * **Putting the onus on developers and testers:** to guess what the requirements really are. | * **Putting the onus on developers and testers:** to guess what the requirements really are. | ||
dido/public/ra/1.4_req/2_nonfunc/20_maintainability/testability.1623858392.txt.gz · Last modified: 2021/06/16 11:46 by nick
