“A problem well stated is a problem half solved.” –Charles Kettering
Charles Kettering was the head of research at General Motors from 1920 to 1947. He was an inventor, engineer, businessman, and holder of over 100 patents. And he had an excellent point when talking about having your problems well stated.
Sometimes, the biggest challenge in software engineering is understanding what your problem truly is. Over the past several years, I have found this to be true more often than in the early years of my career. This is probably because software applications are a lot more complicated now, with many more features.
When the people requesting new features state their requirements poorly, the impact on development schedules is dramatic. Weaknesses in problem definition are likely to cause ten times as many delays compared to bugs found in testing. This is why business analysis is critical, and everyone needs to spend more energy in this direction.
Unfortunately, many business managers assume their vague requests are sufficient and refuse to do the legwork in working out the details, leaving it to the developers to guess the best course of action, which almost always ends in a suboptimal outcome.