"The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B."
How to know what flavour the missing item was? Absolutely no mention of that...
The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X.
But that fact might not ever be recorded in the computer system, in a way that the old business process would've had a record of.
And this is just one small example - imagine something more complex!
So realistically, the job of a programmer is to force an expert to articulate all of their assumptions. IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do.
If they do, then they by definition become a domain expert. It's just that this takes a while, and projects usually don't give enough time for such to take place unfortunately.
Ha! As far as I remember it was almost exactly this when we interrogated them (but it's been a while).
Or you give them a prototype of the program, and see what they complain about?
Occasionally, you'll randomly get something they accept - but only for a few weeks until they come across some missing capability for some other thing they never told you about.
Yes, I wasn't entirely serious.
Though you can get pretty far by doing some roleplay, where you pretend to be the computer/system (perhaps put up paper screen to make it easier to roleplay, and pass messages written on paper) and have the expert interact.
When you are solving a real problem, you will still receive complaints, but they will be much more constructive.