Hi,
in short, if issues like the ones you describe were not common, there would be little need for business analysts :-) The way I see it, the analyst's/modeller's role is not to draw pretty pictures but to translate between two vastly different worlds - the technical and business, i.e. non-technical.
When non-technical people try to switch to a technical mode, it ends up in a confusion. To be fair, the same happens when technical people start thinking they understand the business - has anyone had to use an application with a UI designed by the programmers alone?
Long story short, there is little you can do to prevent people from being vague about details, at least initially. What you need to do is cross-check everything, challenge (non-controversially!) the requirements presented to you and try to understand the big picture. Once you have collected a set of requirements, present them back to the users - not as a simple list or a document but as if you were presenting a design that the users have not seen before. That way you are giving them a chance to say "wait, you got that wrong".
When you start designing your use cases, have a good look at them and see if they seem complete. Do you have many use cases with only a main success scenario and no exceptions? That may mean something is missing.
When you walk through a process and the users tell you "then the Branch Manager has to approve an account", make sure to ask: "what other things does the Branch Manager do?" as well as "what happens if the account is not approved?". Simply put, cross-check everything, look at each requirement from different prospectives. Over time, the users are likely to adjust to this way of thinking and you will have a better chance of gaining deep insight into the subject matter.
As far as the algortighmic language goes, does this happen in writing or when you talk to them face-to-face? In case of a written language, that is an issue on its own - relying on written documents to accurately convey the gist of requirements from the users to you is tricky. If on the other hand the users actually try to SPEAK like that, it must be because they are trying to adjust to what they think you want to hear. Try to stop them and ask them "what does the process usually look like, without any IFs and BUTs". Only after you have a clear grasp of that, focus on the exceptions. It is likely to be easier on the users as well as on yourself.
Hope this helps!
Bruno
