Requirements Engineering and Schrödinger’s Cat?
The recent Invisible Thread blog on ‘The
New approaches to development, such as the use of User Stories in Extreme Programming and Agile, or more model based approaches such as Mode
However, I also started to realize that the real lesson from the Mars Climate Orbiter is that good, clear, well-written requirements are still essential to the success of your endeavor, particularly at the contractual boundaries.
Requirements are essentially focused on risk reduction– did we think about all of the little things that could go wrong as the result of miscommunications, and did we document those so that it was clear to everyone involved that these were the rules by which we were playing?
I have met many people over the years who have tried to argue that you can do all of this in models – but I still do not believe a model substitutes for a simple statement such as ‘these are the units we shall be using…… ’
‘But hold on’ I hear you cry! ‘That is a lousy requirement!’ ‘I cannot sign up to that!’ – at least I hope I hear it.
Because the reality is that bad requirements are just as bad, if not worse, than no requirements.
You may no longer be dealing with layers upon layers of textual requirements, creating meters of paper to be delivered to your client (by hired van, in the dead of night, when the printer has broken down, and there is no one left in the building but you, and the project payment depends on this delivery………a story for another time perhaps) but it is still just as important to make sure the statements are well articulated.
More importantly, when you start to use tools such as Doors or Door
There are many sources of information on how to write good requirements – Ian Alexander in the UK, and Ivy Hooks in the USA, are black belts in this topic, and INCOSE always have great materials to support the new practitioner and the unwary – but a few simple rules are common across all these sources:
The real basics of a ‘good’ requirement involve making it:
A good requirements engineer should already be asking what I mean by ‘good’! And that brings us to the concept of a glossary – an example could be:
"The equipment shall survive exposure to temperatures ranges of -40C to +65C" – this is only meaningful if we know what ‘survive’ and ‘exposure’ really mean in this context
Defining your terminology is essential, as is avoiding abbreviations or ensuring they are in your glossary and easily accessible.’
And remember the basic anatomy of a requirement:
Always aim to get the who or what, the end result and the success criteria in every requirement.
But most importantly remember: if you do not clearly explain what you want, do not be surprised if you do not get it!