.png){kind=logo}
Quality Assessment
Quality Assessment is a feature that is integrated into the ValiAssistant. It analyzes the selected Requirements' texts based on a set of INCOSE rules and provides the user with a Quality Score and a Quality Comment on how to improve the Requirements if the score is low. This information is written into two specific columns which can be enabled on the Requirements tables called “Quality Assessment Comment“ and “Quality Assessment Score“. Information on the overall Quality of the Requirements will also be highlighted in the Insights Dashboards in the Requirements Module.
The Quality Assessment can be accessed in three different locations. Based on the location where it is accessed it takes specific Requirements into consideration for its assessment.
Access through the ValiAssitant Button
While in a certain Specification or on “All requirements” by accessing the ValiAssitant in the upper right-hand corner the user can select “Quality Assessment“ as shown in Figure General Quality Assessment.
General Quality Assessment - Access through the ValiAssistant
When accessing the Quality Assessment through the ValiAssistant all of the Requirements in the current Requirements Table will be analyzed.
Access through the Action Column
The Quality Assessment can be triggered directly from the Action columns on individual Requirements or on a set of bulk selected Requirements as shown in Figure Individual Quality Assessment.
Individual Quality Assessment - When accessing the Quality asessment through the action column only the individual or the bulk selected Requirements will be considered.
When accessing the Quality Assessment through the action column either the individual or the bulk selected Requirements in the current Requirements Table will be analyzed.
Access through the Insights
The Quality Assessment can also be triggered through the Insight Dashboards on Specification level as shown in Figure Quality Assessment Insights.
Quality Assessment Insights - A refresh button triggers the Quality Assessment of the Requirements in the Specification.
When accessing the Quality Assessment through the Insights all of the Requirements in the currently selected Specification will be analyzed.
Quality Assessment Flow
After triggering the Quality Assessment Valispace will indicate how many Requirements are going to be analyzed.
Then Valispace will inform that the Quality Assessment was successful.
In the end you will get additional information about the Quality of your Requirement Text in the “Quality Assessment Comment” and “Quality Assessment Score”.
Additional Quality Information - The information is displayed in the two columns highlighted here.
After a Quality Assessment the overall quality score will be communicated to the Insight Dashboard and represented based on the score as “Low“ (score below 50), “Medium“ (score between 50 and 70) and “High“ (score above 70), as shown in Figure Insights Quality Score.
Insights Quality Score - Overall Quality score board for the analyzed Requirements.
INCOSE taken into Consideration for Assessment
R1 - Use a structured, complete sentence: subject, verb, object.
R2 - Use the active voice in the main sentence structure of the need or requirement statement with the responsible entity clearly identified as the subject of the sentence.
R3 - Ensure the subject and verb of the need or requirement statement are appropriate to the entity to which the need or requirement refers.
R5 - Use definite article “the” rather than the indefinite article “a”.
R6 - Use appropriate units when stating quantities. All numbers should have units of measure explicitly stated.
R7 - Avoid the use of vague terms such as “some”, “any”, “allowable”, “several”, “many”, “a lot of”, “a few”, “almost always”, “very nearly”, “nearly”, “about”, “close to”, “almost”, and “approximate”.
R8 - Avoid escape clauses such as “so far as is possible”, “as little as possible”, “where possible”, “as much as possible”, “if it should prove necessary”, “if necessary”, “to the extent necessary”, “as appropriate”, “as required”, “to the extent practical”, and “if practicable”.
R9- Avoid open-ended clauses such as “including but not limited to”, “etc.” and “and so on”.
R10 - Avoid superfluous infinitives such as “be designed to”, “be able to”, “be capable of”.
R12, 13, 14 - Use correct grammar, spelling, punctuation.
R15 - Use a defined convention to express logical expressions such as “[X AND Y]”, “[X OR Y]”, [X XOR Y]”, “NOT[X OR Y]”.
R16 - Avoid the use of “not”
R17 - Avoid the use of the oblique ("/") symbol except in units, i.e. km/hr
R18 - Write a single sentence that contains a single thought conditioned and qualified by relevant sub-clauses.
R19 - Avoid combinators that join clauses, such as “and”, “or”, ”then”, ”unless”, ”but”, ”as well as”, ”but also”, ”however”, ”whether”, ”meanwhile”, ”whereas”, ”on the other hand”, or ”otherwise”.
R20 - Avoid phrases that indicate the purpose of the need or requirement.
R21 - Avoid parentheses and brackets containing subordinate text.
R22 - Enumerate sets explicitly instead of using a group noun to name the set.
R24 - Avoid the use of pronouns and indefinite pronouns.
R26 - Avoid using unachievable absolutes such as 100'%' reliability, 100'%' availability, all, every, always, never, etc.
R28 - Express the propositional nature of a condition explicitly for a single action instead of giving lists of actions for a specific condition.
R29 - Classify the needs and requirements according to the aspects of the problem or system it addresses.
R31 - When defining design inputs avoid stating a solution unless there is rationale for constraining the design. Focus on the problem “what” rather than the solution “how”.
R32 - Use “each” instead of “all”, “any" or “both” when universal quantification is intended.
R33 - Define quantities with a range of values appropriate to the entity to which they apply and to which the entity will be verified or validated against.
R34 - Provide specific measurable performance targets appropriate to the entity to which the need or requirement is stated and against which the entity will be verified to meet.
R35 - Define temporal dependencies explicitly instead of using indefinite temporal keywords such as “eventually”, “until”, “before”, “after”, “as”, “once”, “earliest”, “latest”, “instantaneous”, “simultaneous”, “at last”.
R38 - Avoid the use of abbreviations.