In ESDM, quite a bit of emphasis is placed on understanding what kind of software the user needs or would like. It is very important for the developer to think through how the software will be used by the customer. In order to do that properly, some time must be spent with different customers and what they say should be recorded or written down so that it can be translated into requirements later.
Sometimes, there is a very big difference between what a customer says he wants and what he actually needs. As software developers, there is no question that we are in a much better position to explain how the software should work than the customer. But, at least sometimes, the customer needs help with exactly “what” the software should do as well. What I have found to be effective, is to think like a user and ask what I would want the software to do in order to do that user’s job more effectively. This means researching the business domain of the user and understanding his business goals. Once this is understood, it is relatively straight forward to translate this to a requirements document.
Ideally, experienced developers should be involved from the very beginning of the project. The task of requirements analysis and deciding what the software should do should not be left up to administrative managers, executives, and the customer alone. The sooner experienced developers start to participate, the better.