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/07/29 09:44] murphy |
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 [[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|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 [[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: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 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. |