Original image from Bookhaven
The “Devil” in any requirement specification is that one turn of phrase or even one word that if missed can mean many more days and months of work trying to verify it formally. The task of requirements analysis is predominantly about finding such details before the cost rises exponentially.
The fear of missing such a slight inflexion is so crucial that in many engineering companies there are commercial and technical analysts whose sole job is to map all the stated desires of the customers with the minimum of ambiguity. And to do this early enough so that project money is not wasted on re-qualification of designs or re-testing and verifying.
A second front in requirements analysis it that it provides information and ammunition to renegotiate with the customers to clarify requirements. In doing so your company can demand change request payments and document changes so that everything is justifiably traceable.
At times, however, all that seems to get done in projects is talk and talk again about requirements.
The problem with thinking that requirements much be analysed in such detail is that a requirement specification is not the original vision or ideal picture of the person or group of people who wrote it. And to not address this is effectively only taking on the “little Devil” and becoming a “big Devil” yourself by ignoring it!
To be clear here: most engineers and scientists working on any type of engineering project, will immediately reference the specification rather than try talking to the creator of the specification. It is the convention and the way people are trained.
To ask what someone was thinking about simply invites ambiguity and vagueness; what any engineering project needs is specificity. It requires zero ambiguity and exactness. The task of traceability and all the legal obligations that can come with that demand it.
This is true; but there is another side to this thinking that is actually a weakness.
By addressing the specification, and only the specification, you are concerning yourself with the map of what to do; the instructions of how to go about creating the product or system. You assume that the instructions are correct and in doing so all the requirements can gain equal importance.
What you are not doing is trying to see what the other person sees and have an understanding of where it came from and what it means. And you are not finding out the different levels of importance for each requirement. When you only concentrate on the specification the “big Devil” or the thing that is going to catch you out and make life hell is your own approach.
Why would you bother finding out what your customers see?
The shortest answer is that nobody ever creates anything from scratch; there is always a large part of what they are familiar with and have worked on or seen before in what they produce next. If you can get to understand this picture from their point-of-view then you can simplify the description of what you need to do and the effort you need to undertake to verify all the requirements.
You can do this because once you know what the picture looks like and what it was based on you can repeat-build a lot of the components using qualified and already-built designs. And in doing so you can remove the effort in verifying these particular requirements.
There is more though: you should not be concentrating on all the requirements as many are just not important at all.
When I say that some are not important I really mean that maybe as much as 95% of all the requirements are not important.
This may seem like a bold statement but there is a very good reason for this.
Typically when you meet the customers for negotiations and progress meetings, a lot of discussions ensue about details and various requirements. Usually there is no critical or crucial requirement that demands more attention; “fire-fighting” them all tends to happen.
In a meeting though, you talk to people. And even though you may use abstract statements in the passive voice or technical terms, this is not the underlying current of any meeting.
Underneath all the formal speech are people with fears and desires; worries and idealised pictures in their mind; irrational logic and personal realities. And within these feelings and images there are maybe 2 or 3 big ideas and desires that they want to see fulfilled in the project.
Even if there are hundreds of requirements, drilling down, for example, into the tiny details of nut sizes, each one of the customers will always have only 2 or 3 requirements and ideas that need to be met. These critical requirements in each of the customers’ minds are analogues of the psychological ideas of Abraham Maslow.
Even though these needs are not recognisable as survival or appreciation, there are always only a few really important concepts in a project that should demand most of the attention.
Therefore you can see that if you are to be effective at requirement analysis, then it pays to understand these needs first and continue to revisit them so that you can speak in your customer’s language throughout, and prioritise your project workload and activities along complementary lines.
To not do this is to introduce friction and inefficiency to a project. And to create your own unnecessary problems that need to be solved
Lastly, by understanding your customers deepest fears and big ideas in a project, and by learning to speak in their language, you will find that requirement resolution and verification is easier. By cultivating an “us-together” mentality rather than “them-and-us” the project activities and your requirements analysis will be much more effective and in tune with what they really want.
There will be no “Devil in the details” that has to be exorcised; there will only be focused and rewarding work.