Did you know? When it comes to requirements patterns, both good and bad requirements patterns are valuable for analyzing quality. Requirements Quality Analyzer RQA, in version 2014, includes a very interesting feature to define parameterized metrics. Those parameterized metrics are seamlessly integrated together with the rest of out-of-the-box metrics, and provides the end user an easy to use extensibility to describe your own metrics.
A special type of these parameterized metrics has to do with finding specific requirements patterns inside the requirement description. It’s important to note that while patterns for authoring must cover the full length of the requirement grammar; patterns for quality checking can be as short or long as needed.
An example of such a pattern may help you ensuring that, in the context of automotive requirements, every time you write a requirement in the way
“Whenever the speed is below 10 mph….”
it comes with the corresponding speed in km/h as in
“Whenever the speed is below 10 mph (16 km/h)….”
To do so, a suitable pattern should be created first, and then a parameterized metric can easily check for the proper pattern in your requirements.
In addition to this usage of “good” patterns for quality control; we can also identify a number of “bad” patterns useful to detect poorly written requirements. An example could be when you find specifications full of requirements without a clear ‘agent’ firing the requirement. For example, in the requirement
“There shall be an icon to show that ….”
many times a system element should be in charge of that light, so the requirement should be rephrased as
“The dashboard shall show an icon when….”
To deal with this problem, aside of the “good” patterns to identify good requirement structures:
“Agent + shall + action + entity + ...”
other not so good (“bad”) patterns can also be created to warn about the use of those structures that must be avoided:
“There + shall + be + …”
By using those “good” patterns to identify “bad” requirements, RQA and RAT will warn you when the forbidden (in case your organization decides to forbid such a way of writing a requirement) structure is used in your organization.
As a conclusion, patterns for good requirements and patterns for bad requirements, are all useful for a quality analysis.