Over the last few days a number of people have asked me the same question: “How can we get more accurate requirements?” While I agree it is not nice to answer a question with a question, in this case you might bend etiquette a bit because in reality this question can be hard to answer. For example, why is it necessary and which problem does it solve? Or, what exactly do you mean with accurate? And do you have accurate requirements and you want more of those? And in that case, more than what? Or do you have inaccurate requirements which you want to become more accurate? And if so, how much more?
You might say: “Hey, that’s just playing with words”. Well, that’s right and so is writing and communicating requirements. In order to get accurate requirements you need a number of things. However, an often overlooked element to writing accurate requirements is understanding the structure of language and how language is perceived.
My friend Daniel told me a war story once about a software project team that had huge problems with so-called non-functional requirements. They knew they were out there and crucial, but the customer was not really helpful and capable of expressing them. In the end they forced a breakthrough by playing hard ball; (read out loud) “So you want a system that is very hard to use and frustrates each and every user all day long”. The shock did indeed create an opening, but I’m sure that, you like me, feel that most people do not like to be shocked, yelled at and bullied. Luckily for us, there is a nicer and more elegant way.
Let’s have a look at non-functional requirements like reliability, usability, efficiency, maintainability, portability and ask yourself the following question: What do these quality attributes have in common from the viewpoint of language? The answer is that they are all nouns where in reality these are verbs. Or in other words we are actually dealing with active processes in disguise because we are treating them like (physical) things. This phenomenon happens all the time and in all kinds of situations. When somebody tells you he or she is having a depression, he or she is actually feeling bad. The same thing with having fun. You don’t have fun, you feel good.
By now you might wonder why using nouns rather than verbs is bad. Well, it turns out that when process is lost or hidden it is much harder to solve a problem; or, like in our case, accurately specify and communicate requirements. When you keep treating processes like things, often jargon is required to discuss it. For example: “Oh, what’s the mean time between failure then” and before you know it you have completely lost the customer. And more fundamentally, the brain perceives things as rather unchangeable or static while processes are implicitly perceived as changeable and dynamic. This means that it's much easier to get to the essence of the meaning, increase the accuracy of requirements and to negotiate or down scope so that business value can be delivered at reasonable cost and schedule.
Let’s for example look at availability. A customer might issue the following rather bold requirement:
- The system must have an availability of 100%.
Some of us will question the unrealistic need for 100% availability with the chance of losing rapport or close contact with the customer. When you know enough about the problem space and the customer understands the jargon, a better approach is asking questions about the underlying processes. For example:
- What is the average period of time within a year the system is allowed to not be available?
- What is the average period of time within a year the system is allowed being unavailable for maintenance?
- What is the maximum time allowed for restarting the system after failure?
And when you haven’t got a clue or you have the idea the customer really does not fully understand concepts like availability, it is more elegant to ask more context free questions like:
- What is it like when the system is available 100% of the time?
- What will happen when the system is only available 90% of the time?
Maybe the customer does not have all the answers, but the discussion will be much easier and friendlier now because we have denominalized the process behind the initial requirement.
A good way to detect nominalizations or disguised or hidden processes is to test if you can put the sentence’s objective (noun) of a given requirement in a box, albeit a large one, or throw it out of the window. When you cannot, go after the processes behind it. Can you put usability in a box? Or availability?
For non-functional requirements or quality attributes standards like ISO/IEC 25000 provide categories and more important metrics for evaluation and verification purposes. These metrics do provide a good starting point for understanding and exploring the underlying processes.
There are more language patterns that, when violated, obscure or negatively affect effective communication. In a way they are all translation problems that cause information to become distorted, deleted or (over)generalized. To me this is a one source of obstacles you have to overcome when you are in need of more accurate requirements. When you want to know more about these language patterns, a good source is the NLP Meta-Model, but feel free to drop me a line when you want to know more or have questions.