Sometimes requirement authors can get carried away and write
long verbose requirements or even longer descriptive text. These can cause
quality issues and more often than not can be easily split into smaller chunks.
This aids readability.
Over long requirements can imply that the V&V would be similarly
overly complicated.
Layout DXL script to identify oversized objects
This DXL script will identify over long objects (the size is
defined in the layout script) in a layout DXL column. All objects are
considered whatever the type, but tables are only displayed as a single row in
order to reduce the clutter.
If the size is below the required number of characters, then
it is excluded from the display by a filter. If not, then the number of
characters is displayed.
The reviewer/author can then split the object at a convenient location and the filters
can be reapplied.
As the project progresses then the requirement scope and
therefore the requirement text may change.
Occasionally, a requirement can become a description, or a
description can become a requirement. Worst case scenario is that the author
can forget to set the Object Type (it happens !).
We need to flag these mismatches so that only the true
requirements can then move forward for the completion of the verification and
validation attributes.
DXL script to apply a filter for Object Text and Object Type mismatch
This DXL script simply applies a filter for :
all requirements (as defined by the Object Type)
that do not have a “shall”
Often at the start of a project some of the design criteria, limits or ranges are not known and “To Be Defined” (TBD) or “To Be Checked”/”To Be Completed” (TBC) are used in place of, or together with, the proposed values. For example, the value maybe defined but followed by (TBC).
As the project progresses, then more detail will be
designed, and the requirements can be completed without these limitations.
What would be very useful is a DXL script to identify these
requirements which have been annotated in this way.
DXL script to apply a filter for TBD/TBC
This DXL script simply applies a filter for TBD or TBC for
all requirements (as defined by the Object Type).
Spell checking is always an issue in requirements. It is
important that all spelling mistakes are removed before a requirement is sent for
review so that the reviewers do not spend time correcting typos and forget the
technical stuff.
Layout DXL script to identify spelling mistakes
This script uses the spelling functions of DXL and will identify any misspelt words in a layout DXL column.
It does not prevent mistakes as you type like Word but if
combined with a view to filter on ‘not equal to “OK”’ then it is a simple task
to quickly spell check and correct. The current implementation is for English (UK)
as this is the most common language for requirements but the DXL script could
be adapted for other languages.
Perhaps one of the most important quality attributes necessary for a requirement is to be able to verify the requirement. Some of the phrases and words that we use in every-day language, because they are ambiguous or cannot be verified, should never be used in requirements; some should only be used in exceptional and justified cases. There are also non-specific phrases, pronouns, indefinite pronouns, unmeasured quantifications, indefinite temporal keywords and other grammatical constructs that also should never be used in a requirement.
Layout DXL script to identify banned words
This DXL script will identify any banned words (or rather terms that should be avoided) in a layout DXL column.
It does not prevent mistakes as you type but if combined with a view to filter on requirements and ‘not equal to “OK”’ (which is the default) then it is a simple task to quickly identify areas of concern and correct. The banned word list is currently hardcoded into the DXL script but it could be enhanced to read the list from a specialist module to provide more visibility and ease the maintenance task. The list could be tailored for individual companies.
It is interesting to note that IBM have recently launched
their own Requirements Quality Assistant for DOORS Next.
“Using Watson Natural Language Service and pre-trained AI, the Requirements Quality Assistant has 10 built in quality indicators designed to be consistent with guidelines from the International Council on Systems Engineering (INCOSE) and NASA for writing complete, clear and testable requirements to accelerate your review process, increase requirement quality and reduce training for junior requirements engineers.”
Although this DXL script is not as sophisticated as IBM’s, it nevertheless will highlight words that should be avoided – and at over 150 terms, our list is longer than in the INCOSE guide!
