Why ”passive voice” requirements actually can become a night mare?
If you are like me and like clear and precise requirements with as much clear meaning as possible you might try to wash out some bad language in your requirements. Perhaps you review a set of IT system requirements on the highest level and find a requirement written like this:
“All critical errors shall be logged”.
You might continue and think; “That’s a bit vague but I guess that the reader of the requirement understands this, and the requirement is under a specific section of the set named System management, so is should be fine. I need to discuss with the author on what a critical error is, and we need to investigate how to verify that these errors defined as critical get logged”.
But you might also be a nerd like me and immediately say that “no, we must not have any passive voice requirements in our set of requirements, period!”. Its also in violation of the INCOSE guide in writing requirements, i.e. Rule R2 – Use active voice. But the author of the requirement is much likely not aware of that guide or quality rule in the first place..
Ok, fine. But what does this mean and why is this so dangerous to allow passive voice requirements?
Does it really matter if I write a passive voice requirement? I understand it and this should everyone else also do. Besides, it’s a short high level system requirement and we will get back to the verification details later. These details will come when I start to specify the subordinate level of requirements derived from this one or when I prepare a design solution which will take care of the requirement.
INCOSE says in the rule R2 mentioned above that “requirements not stating the subject must be avoided”. Whats that? I have written that “errors shall be logged”. The word Error is my subject, right?
No, its not actually. When looking into the example sentence in more depth its quite clear that it lacks a SUBJECT. The sentence does not explain WHO will actually log the errors that the writer of the requirement see must be logged. Let’s look at this figure:
From this figure its quite easy to understand that the solution for a passive voice requirement can both be a system function of some sort or a service provided by someone outside of the system.
Same applies to ALL types of passive voice requirements:
Lights shall be integrated in the dashboard… OK. Fair enough, but it this a requirement saying that we require someone to integrate the lights or is the purpose something else?
Perhaps the lights are supposed to be hidden (integrated) in the dashboard and the requirement is trying to capture this?!
The ONLY solution if you ever encounter requirements written in passive voice (and you will) is to go back to the author (or the stakeholder with the need) and ask what’s the purpose of the requirement in question. Ask WHY do you want to integrate these lights? Or WHY do you have to log critical errors?
The answer to these questions will help you to rewrite the requirement so it captures the intention and purpose behind its existence. Because if you don’t do this you will live with the impression that everything is fine, and the development is on its way towards a solution that will fulfil your requirement. The problem(s) will emerge with the first prototype or even worse during verification of the system towards the requirement. Then its LATE in the process and you will have to manage the probable delay or the added cost of doing a late design change.
So, PLEASE don’t ever write OR accept requirements written in passive voice. You have no idea what the result will be, and it will for sure at one point in time pop up and bite you in your butt!
One of the solutions can be to use requirement patterns, butt (hehe) more on that another time….