Overview of the Quality Check Enhancements in Innoslate v4.10.
| Function | Description |
| Run the Quality Check | Step-by-step guide on how to run the Quality Check. |
| 4.10's Quality Check Attributes | Thorough overview of the Quality Check attributes. |
Innoslate v4.10 introduces enhancements to the Requirements Quality Check Feature within the Documents View. By incorporating the guidelines from the Guide To Writing Requirements Version/Revision: Rev 4 developed by the INCOSE Requirements Working Group, users are empowered to conduct a thorough evaluation of requirements. Innoslate v4.10 Quality Check's attribute names have been meticulously aligned with specific INCOSE Rules, enabling users to aim for a flawless 100% score by meeting the requirements specified in this document.
When opting for 'Quality Check' from the 'More' dropdown in the toolbar of Documents View, Requirement entities are equipped with 9 attributes as part of the Quality Check process in Innoslate v4.10. Following the Quality Check execution, the Quality Score column in the Documents View will display the pass percentage of each individual Requirement entity. This score is based on the evaluation of the true vs. untrue instances of quality indicator attributes through automatic checks. In case a rule is not met, explanations in the form of a bullet pointed list will be provided to clarify why it did not pass.
It is important to note that these are merely suggestions. Users have the option to override these suggestions by selecting 'Yes' in the dropdown menu for the attribute and the score will update to reflect this change. For a visual demonstration of this process, refer to the video below.
Note, how in the video the Quality Check read, analyzed and scored 149 requirements in 9-10 seconds.
How to Run the Quality Check
Follow the steps below to run the Quality Check in Innoslate.
- Open the desired Document in Documents View.
- Select 'More' on the toolbar and select 'Quality Check.'
- Depending on the size of the document, a spinner may appear to indicate that the Quality Check function is in progress. The larger the document, the longer it may take.
Once the Quality Check is complete, the Quality Score result for each Requirement entity in the Document will be updated.
Quality Check Innoslate 4.10 Attributes
Below is a comprehensive overview of each attribute, including the v4.10 Attribute name, its previous version's name (if available), the corresponding INCOSE Rule, the criteria it evaluates (Innoslate Checkpoint), and the Innoslate Response that will be displayed if the checkpoint is not true.
| Innoslate Quality Check Attributes (v4.10) | |
| Necessary | Feasible |
| Appropriate | Verifiable |
| Unambiguous | Correct |
| Complete | Conforming |
| Singular | |
Necessary (formerly Consistent)
INCOSE Rule: R30 - Unique Expression
Innoslate's Checkpoint : Evaluate the requirement for similarity to other requirements in the same document. If possible, provide the percentage of similarity between the checked requirement and the identified similar requirement. If there is a similar requirement, the attribute should be set to No.
If not true, Innoslate's Response: R30 - Potential duplicate of: [...]
Appropriate (formerly Design)
INCOSE Rule : R31 - Solution Free
Innoslate's Checkpoint: Evaluate the requirement to determine if it imposes a solution. If it does, the attribute should be set to No.
If not true, Innoslate's Response: R31 - Imposes a solution: [...]
Unambiguous (formerly Clear)
INCOSE Rule : R6 - Common Unit of Measure
Innoslate's Checkpoint: Evaluate the requirement to determine if a number value in the requirement is followed by the unit of measurement and if that unit of measurement is consistent with a primary measurement system (i.e., British Imperial, US, Metric). Must evaluate a unit in its abbreviated form or regular form. It should also evaluate if the units of measurement used throughout the requirements document are consistent with one primary measurement system. If inconsistent or missing a unit of measurement, the attribute should be set to No.
If not true, Innoslate's Response: R6 - Unit(s) not consistent with a primary measurement system (i.e., British Imperial, US, Metric): [...]
INCOSE Rule: R2 - Active Voice
Innoslate's Checkpoint: Evaluate if the requirement contains words or phrases indicating passive voice. If the passive voice is found, the attribute should be set to No. Currently checked for in the Clear attribute.
If not true, Innoslate's Response: R2 - Passive voice detected: [...]
INCOSE Rule: R5 - Definite Articles
Innoslate's Checkpoint: Evaluate if the requirement contains words for indefinite articles, "a" and "an". These should be replaced by the definite article, "the". If indefinite articles are found, the attribute should be set to No.
If not true, Innoslate's Response: R5 - Contains indefinite article(s): [...]. Consider replacing with the definite article, "the".
INCOSE Rule: R7 - Vague Terms
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases indicating vague terms. Words that provide vague quantification, such as “some”, “any”, “allowable”, “several”, “many”, “a lot of”, “a few”, “almost always”, “very nearly”, “nearly”, “about”, “close to”, “almost”, and “approximate”. Avoid vague adjectives such as “ancillary”, "relevant”, “routine”, “common”, “generic”, “significant”, “flexible”, “expandable”, “typical”, “sufficient”, “adequate”, “appropriate”, “efficient”, “effective”, “proficient”, “reasonable” and “customary.” Adverbs qualify actions in some way and are particularly troublesome if vague. Avoid vague adverbs, such as “usually”, “approximately”, “sufficiently”, and “typically”, which can lead to ambiguous, unverifiable requirements that do not reflect accurately the stakeholder expectations. As a general rule, words that end in “-ly” often result in ambiguity. If vague words are found, the attribute should be set to No.
If not true, Innoslate's Response: R7 - Contains vague term(s): [...]
INCOSE Rule: R8 - Avoid Escape Clauses
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases indicating escape clauses. Escape clauses that state vague conditions or possibilities, 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”. If escape clauses are found, the attribute should be set to No.
If not true, Innoslate's Response: R8 - Potential escape clause(s) detected: [...]
INCOSE Rule: R10 - Avoid Superfluous Infinitives
Innoslate's Checkpoint: Evaluate if the requirement contains phrases indicating unnecessary verbs or passive infinitive phrases. Superfluous infinitives such as “to be designed to”, “to be able to”, “to be capable of”, “to enable”, and “to allow”. An infinitive is a verbal consisting of the word “to” + “a verb”. If superfluous infinitive phrases are found, the attribute should be set to No.
If not true, Innoslate's Response: R10 - Contains superfluous infinitive(s): [...]
INCOSE Rule: R16 - Use of "Not"
Innoslate's Checkpoint: Evaluate if the requirement contains the word "not. If so, the attribute should be set to No.
If not true, Innoslate's Response: R16 - Contains "not".
INCOSE Rule: R17 - Use of Oblique Symbol
Innoslate's Checkpoint: Evaluate if the requirement contains the oblique symbol ("/"). If so, the attribute should be set to No.
If not true, Innoslate's Response: R17 - Contains the oblique symbol ["/"]
INCOSE Rule: R24 - Pronouns
Innoslate's Checkpoint: Evaluate if the requirement contains words indicating personal and indefinite pronouns. Personal pronouns are words such as “it”, “this”, “that”, “he”, “she”, “they”, and “them.” Indefinite pronouns are words such as “all”, “another”, “any”, “anybody”, “anything”, “both”, “each”, “either”, “every”, “everybody”, “everyone”, “everything”, “few”, “many”, “most”, “much”, “neither”, “no one”, “nobody”, “none”, “one”, “several”, “some”, “somebody”, “someone”, “something”, and “such.” If personal and indefinite pronoun words are found, the attribute should be set to No. Currently checked in the Verifiable attribute.
If not true, Innoslate's Response: R24 - Contains personal and/or indefinite pronoun(s): [...]
INCOSE Rule: R32 - Universal Qualification
Innoslate's Checkpoint: Evaluate if the requirement contains words for universal qualifiers, "all", "any", and "both". These should be replaced by the universal quantifier, "each". If universal qualifiers are found, the attribute should be set to No.
If not true, Innoslate's Response: R32 - Contains universal qualifier(s): [...]. Consider replacing with the universal quantifier, "each".
INCOSE Rule: R34 - Measurable Performance
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases indicating unmeasurable performance. Some words signal unmeasured quantification, such as "prompt”, “fast", “routine”, “maximum”, “minimum”, “optimum”, “nominal”, “easy to use”, “close quickly”, “high speed”, “medium-sized”, “best practices”, and “user-friendly.” These are ambiguous and need to be replaced by specific quantities within feasible ranges that can be measured. If unmeasurable performance words/phrases are found, the attribute should be set to No.
If not true, Innoslate's Response: R34 - Unmeasured quantification(s) detected: [...]
INCOSE Rule: R35 - Temporal Dependencies
Innoslate's Checkpoint: Evaluate if the requirement contains indefinite temporal words/phrases, such as “eventually”, “until”, “before”, “after”, “as”, “once”, “earliest”, “latest”, “instantaneous”, “simultaneous”, and “at last”. If these words/phrases are found, the attribute should be set to No.
If not true, Innoslate's Response: R35 - Contains vague time expression(s): [...]
INCOSE Rule: R37 - Acronyms
Innoslate's Checkpoint: Evaluate if the requirement contains acronyms that are defined as a separate entity in the project. Also should evaluate if there is more than one defined acronym that matches the acronym used in the requirement. If the acronym is not defined as a separate entity, the attribute should be set to No. If the acronym is defined as more than two separate entities, the attribute should be set to No.
If not true, Innoslate's Response: R37 - Contains undefined acronymn(s): [...]
Complete (New)
INCOSE Rule: R9 - Avoid Open Ended Clauses
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases indicating open-ended clauses, such as, “including but not limited to”, “etc.” and “and so on”. If these words/phrases are found, the attribute should be set to No.
If not true, Innoslate's Response: R9 - Potential open-ended clause(s) detected: [...]
Singular (formerly Complete)
INCOSE Rule: R20 - Purpose Phrases
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases indicating purpose phrases, such as, “purpose of “, “intent of”, “reason for”, “……to”, “in order to”, “so that”, and “thus allowing.” If these words/phrases are found, the attribute should be set to No.
If not true, Innoslate's Response: R20 - Contains purpose phrase(s): [...]
INCOSE Rule: R18 - Single Thought Sentence
Innoslate's Checkpoint: Evaluate if the requirement contains compound or multiple sentences. If so, the attribute should be set to No.
If not true, Innoslate's Response: R18 - Contains compound and/or multiple sentences.
INCOSE Rule: R19 - Avoid Combinators
Innoslate's Checkpoint: Evaluate if the requirement contains words/phrases that join or combine clauses, such as “and”, “or”, “then”, “unless”, “but”, “as well as”, “but also”, “however”, “whether”, “meanwhile”, “whereas”, “on the other hand”, or “otherwise”. If so, the attribute should be set to No.
If not true, Innoslate's Response: R19 - Contains combinator(s): [...]
INCOSE Rule: R21 - Parentheses
Innoslate's Checkpoint: Evaluate if the requirement contains parentheses and brackets that contain text. If so, the attribute should be set to No.
If not true, Innoslate's Response: R21 - Potential additional information detected inside brackets. Consider moving to the rationale.
Feasible (formerly Feasible)
INCOSE Rule: R26 - Absolutes
Innoslate's Checkpoint: Evaluate if the requirement contains words indicating absolutes, such as, "all", "always", "every", "never", "all", and "100%".
If not true, Innoslate's Response: R26 - Contains absolutes.
Verifiable (No Change)
INCOSE Rule: N/A
Innoslate's Checkpoint: If Unambiguous, Complete, Singular, and Feasible have found no problems, then the Verifiable attribute shall be set to Yes.
If not true, Innoslate's Response: Please resolve issues found with the Complete, Feasible, Singular, and/or Unambiguous attributes.
INCOSE Rule: N/A
Innoslate's Checkpoint: Evaluate if there is an existing verification requirement or a test case for the requirement.
If not true, Innoslate's Response: Must relate to verification requirement or test case.
Correct (No Change)
INCOSE Rule: N/A
Innoslate's Checkpoint: If Unambiguous, Complete, Singular, and Feasible have found no problems, then the Correct attribute shall be set to Yes.
If not true, Innoslate's Response: Please resolve issues found with the Complete, Feasible, Singular, and/or Unambiguous attributes.Conforming (New)
Innoslate's Quality Checker recognizes these industry-standard verbs, allowing users to create more clarity and precision in their requirements:
- "Shall" is employed for binding requirements that must be verified, with a corresponding verification method. It is usually applied to functional requirements.
- "Must" indicates certain quality and performance criteria that need to be verified and accompanied by a method of verification. It is usually applied to non-functional requirements.
- "Will" is used to express statements of fact, purposes, or expected events, and is not binding.
- "Should" represents attributes, goals, or best practices that the system design must consider (informational), but it is not binding.
- "Need" represents a high-level desire or expectation of stakeholders that guides the development of the system. Needs are often expressed broadly and form the basis from which detailed lower-level requirements are derived.
"Shall" and "must" are often used to split the functional and non-functional requirements, respectively. This allows for clear differentiation and consistency.
You can use "will," "need," and "should" when applicable, as they are not restricted to being functional or non-functional requirements.
Ensure each requirement has only one provision or declaration of purpose (such as shall) to avoid conjunction requirements.
Innoslate's Checkpoint: Evaluate if the requirement contains "need", "shall", "will", "must", or "should".
If not true, Innoslate's Response: Must contain one of these verbs: [need, shall, will, should, must]SPEC Innovations has recieved Copyright Permissions to use the INCOSE Working Groups' Writing Guide as inspiration and guide for the Quality Checker.
For further insight into INCOSE's rules and guidelines, please see their Guide To Writing Requirements Version/Revision: Rev 4 prepared by the INCOSE Requirements Working Group.