One of the more common complained I often hear programmers make is that they don’t not get good enough requirements, and even when they get them its many time too late and more often than not they significantly changes along the way.
(and by change I don’t mean getting new requirements all the time which also happens, but to the same requirement starting as one thing and then ending as something different)
at the end of such a complaint there is always the assumption, which sometimes is said explicitly and sometimes not, that if “they” could write proper requirements all our problem will be solved.
Perfect requirements are a Mythin order to understand this statement one must think what is the purpose of a requirement. that is why do we use this mechanism. and the goal is actually quite simple. we need to get a need which usually sit at the user/customer head and be able to move it into the programmer head in such a way that the programmer will have full and complete understanding of what’s need to be done.
unfortunately the mean to pass ideas from one head to another without any lose of meaning does not exists in our world (yet), and therefore no matter how hard we try we can only do better and not perfect.
How are we doing?Apparently not great. programmers still complain that they need to get better requirements. However I feel that we got it wrong. We have been trying for the last decade or so to make things better. Good and smart people have come up with ways to improve requirements writing and invented better way for formalization for example Tom Gilb points out that
“Requirements, the root to failed projects.”and has some great ideas on how we can improve on that. but at the end this is in my opinion he wrong way to go.
if you can't beat them, join themWe programmers must accept the fact that understanding the business is our responsibility. Expecting others to explain things to us is quite a childish approach. At the end it is us who knows best how to gather the needed knowledge in such a way that we can understand it we fully understand things, therefore it is we that need to go out and follow these ways and reach the needed understanding. Fleshing out the requirements to a point in which we can implement them is our responsibility.
Yes there are people who can help us along the way, and yes some of them belongs to the product side which traditionally is in charge of writing requirements. But no its not their responsibility to explain it to us. They are in charge of picking out the good features, they are in charge of finding the best ways the product can grow and serve the customer. when they do its our job to understand what they want and then implement it to the best of our ability.
It is the programmer job to understand the requirement.