Non-words and ‘could mean anything’ words
Requirements Engineering is a specific engineering discipline which is concerned with the elicitation, decomposition, and management of system requirements throughout the entire lifecycle of a system. What I’m interested in (and hopefully you are too) is the management of a specific subset of system requirements – safety requirements.
Safety requirements are held to be carefully managed through meeting five (actually 4+1) principles first developed for software safety assurance by Hawkins, Habli, and Kelly [1], which I’ll paraphrase if I may:
PRINCIPLE ONE: Safety requirements shall established which mitigate the identified hazards.
Of course, an implicit need here is to have identified correctly and completely the set of hazards – but we’ll put that to one side for now.
PRINCIPLE TWO: The intent of each safety requirement shall be maintained as the design and associated analyses decompose into further levels of abstraction.
This could be put simply as the decomposition of requirements as the design becomes more granular; moving from system, to component(s) and down to the software boundary.
PRINCIPLE THREE: The safety requirements shall be met.
The simplest of the principles, in theory at least.
PRINCIPLE FOUR: Hazardous behaviour(s) of the system shall be identified and mitigated.
Even when the safety requirements are correctly instantiated into a design, there may be unintended consequences of their instantiation – even if the design is fully compliant with the requirements. This could be because of an issue with the requirements, or the design process for example. However they arise, any unforeseen hazardous behaviour(s) must be identified and mitigated.
PRINCIPLE ‘PLUS ONE’: The confidence achieved in meeting the four principles shall be commensurate with the associated level of risk.
Even if time and resource were infinite, there is no such thing as ‘total safety’. As such this ‘plus one’ principle attributes proportionality, in that the higher risks require more confidence than lower risks.
Using these principles allows engineers to ensure the quality of their safety requirements through life. So what makes a ‘good’ safety requirement?
Good Practice for Safety Requirements
There’s an oft-cited acronym which capture what a ‘good’ requirement should be, and I’m happy to roll it out again for the sake of brevity. A requirement must be SMART:
- Specific
- Measurable
- Atomic
- Realistic
- Time-bound.
Requirements using ‘non-words’ can never be held to be SMART, and nor can they ever meet the ‘four plus one’ principles. But what are these non-words?
Safety Requirements Poor Practice
Unfortunately poor practice abounds with requirements engineering throughout system safety, and the type of poor practice I encounter the most (anecdotally, rather than scientifically) is the use of non-words. Expressing requirements in natural language is often problematic for all but the most simplex systems, but sometimes necessary. Focussing on requirements expressed in natural language, keep in mind the five principles above, and the SMART acronym as we consider some galling examples of non-words in safety requirements.
Perhaps the biggest offender of these non-words (or the one that infuriates me the most at least) is ‘system xx shall support…’. What are we to make of this ‘support’? Are we to design a trestle with which the system can hold something aloft? Perhaps we should arrange for a group of avid fans to gather around and cheer as the system operates?
If a requirement is ‘to support’ something, then the requirement must express what is meant by support – either using a definition or a measure of performance associated with the requirement. Perhaps both of these.
‘Shall be capable of…’ is another poor example (or should that be a good example of poor practice…I digress). If we take such a requirement at face value, a supplier could easily provide a system or component which is capable of a function, but not necessarily supplied in a configuration which delivers the capability – and yet still be off contract. We’ll leave that one for the lawyers.
Natural language is a common communication tool which divides us all, and there are a couple of non-engineering examples of non-words I’d like to offer to drive the point home. The first is a sign which warns that ‘Shoes should be worn’. Does this mean one’s footwear should be threadbare and at the end of their life? Or maybe our feet simply have to be shod.
The second is the expression ‘time flies’. This could be dealt with by the response ‘doesn’t it just?’ Or, maybe the utterer is in fact discussing a particular genus of insect from the ‘time’ family? It could even be an instruction for one to start one’s stopwatch and time the activities of flies. Without further clarification and context, one cannot know for sure.
Avoiding Non-words
The most obvious solution to the eradication of non-words is the use of formal specifications, in which formal notations are used to declare requirements in a clear, unambiguous manner. The benefits raised through formal specifications would be further enhanced by managing safety requirements through life in a Modelled Based Systems Engineering tool.
Sometimes natural language is necessary however, so to avoid the traps set by non-words, a clear set of rules for syntax is required – accompanied by a managed glossary of terms. Measures of performance are also key if stakeholders are to understand precisely how they are to get off contract with the safety requirements allocated to them.
Reference
- Hawkins, R., Habli, I. and Kelly, T., 2013, August. The principles of software safety assurance. In 31st International System Safety Conference (pp. 12-16). Boston, Massachusetts USA: The International System Safety Society.
