Of the monster called software requirements...

There was a joke I heard long back of which I vaguely remember only the end. Well, the joke wasn’t funny, but the ending caught my attention, and it goes like this:

'So, the software engineer goes to heaven and meets St. Peter. At the pearly gates, St. Peter asks the young fellow, "Since you sacrificed your life, you are granted one wish. What is it that you want to ask for?" The young man said in an instant, "Please help all customers in the world make up their minds…"'

While, I didn't laugh at the joke told to me by a banker friend of mine, it did get me thinking, "Are software requirements so much of a known problem that even bankers are cracking jokes on it?"

I did not get time to research to answer my own question until some time back.

Are software requirements really a problem? And why is requirements management in a software project considered to be problem?

The answer to my question does not really point only to software requirements. There are a lot of activities that can be attributed to failure of a software project and requirements are just one reason. Nonetheless, it is a key reason since that is what sets the direction of flow.

The effects of wrong or bad requirements cascade down all the way to the product which can lead to critical customer dissatisfaction. This is so well understood that there is no need to demonstrate it. But what is more important that asking the two questions above is asking, “Why requirements are poorly captured or developed?”

Let’s see why:

1. Poor communication: Even the advent of technology has not helped mankind to communicate effectively with each other. We have emails, telephones, video conferencing systems, faxes, text messages over mobile phones today to help us communicate, but with such technology comes its own baggage of pitfalls. We still have to consider tones, languages, cultural differences in words, accents, and gestures. We have a smart bunch of people in the world working 24/7 to come up with newer acronyms, terminologies and short texts which are not accepted as fast as they are developed. Not to disregard, that most times the technology itself fails and creates a huge break-down in the communication channel. This leads to a huge gap between people who are speaking and those who are trying their best to listen.
2. Individual intelligence and perceptions: The thing that separates us from our closest relatives is higher intelligence. And it is this natural wonder within us that sometimes causes us to fail. People usually feel compelled to think outside the boundaries of rationale thinking. While this is good when you are trying to prove the String Theory, it is absolutely not, when you are trying to understand customer requirements. People try to be poetic and refuse to call an apple an apple.
3. Inadequate documentation: People have a misunderstanding that processes require you to capture as much documentation as possible. The reason why this is a 'misunderstanding' is because a good process will not talk of absolute documentation, but adequate documentation. If one line was sufficient to write a world class application that meets all quality standards, business objectives of your organization, and client’s expectation, then one need not write the second line. If not, then one has write as much as is necessary to get the work done properly.
4. Variability Factor: I keep saying this over and over again and will take the liberty of doing so one more time. Customers have the right to be fickle minded. But Customers, understand this, the more you change your mind during the journey, the more likely it is that you will reach the wrong destination.
5. Bad Estimation: The blame for this cannot be singled out to one particular person or team. Collectively, it is the initial stakeholders of the project that are to blame. Some want to control budget, others time, someone else wants top quality, while the vendor teams want to save the contract(s). It is pretty obvious that one can’t please everyone; hence creating an estimate to do exactly the same would be foolish. The stakeholders need to come to a common understanding and a reasonable trading-off on requirements needs to be done before estimating and be committed to it once it is done.
6. Ineffective Change Management: Even with all the stability in requirements, we must understand that software development is an evolutionary process. Unlike other industries where requirements can be frozen at the start of the project, ours tend to be empirical in nature. While we should try and freeze most requirements, we should also concentrate on having a good system in place to manage these changes. But currently, in most projects this process is not as strong as it is supposed to be. This final problem encompasses all the problems listed above.

Determining the right approach can be tricky, but not so tricky, if you understand where the problems lie. The list above is just to get you thinking in that direction and find the right mix of people, process and technology to overcome this very common hurdle.