Over the last few months my job has required to do an increasing amount of business analysis. Technically, my role is detached from actual "business knowledge" - that is a practical understanding of the requirements of our customers that surround and drive the needs of the software environment we build for them. Any developer will tell you that this is impossible - but it is true that my need for this knowledge is minimal. I don't need to understand the legal requirements of a system, I need to know what to do. What, not why.
I've done analysis of this sort before, as a technical author, but never so in depth. So there has been something of a learning curve, and complications in that I have no direct communication with the customer. The analyst team is my intermediary.
If there's one thing that I have learned, it's that asking the right question is crucial, but the right question is not necessarily as straight forward as you might expect it to be. Part of the problem is that you're not asking questions for your own benefit. In the majority of cases the analyst is not the coder, and as the guy or girl writing the implementation your question really has to yield a resolution that is meaningful to them. I have an unfair advantage, as a coder, with insight into what kind of answer is going to be truly useful - many analysts in my experience do not have a good understanding of the needs of a coding team.
Your knowledge of the business you're developing for informs the questions you ask. In order to avoid ambiguity and confusion you need a solid grasp of the terminology and conventions of the business in question. In financial services we not only have to understand how personal finance operates as an industry but also need to anticipate the needs and restraints of regulation. Sometimes a plain english question is not going to yield the information you need. It can, at times, feel like learning a second language.
On the whole there's no such thing as too many questions. Where in every day communication we infer and assume information based on what is said, what isn't said and our familiarity with a subject, a computer system cannot. It can be as important to define what shouldn't happen as what should happen. Sometimes covering all the bases requires a monotonous and comprehensive approach.