Hi and welcome Grant,

the best type of questions to elicit information are open questions that cannot be answered 'yes' or 'no' - e.g. "what type of questions usually elicit the best information?"!

Then confirm your understanding with closed questions that are designed to be answered "yes" or "no" - e.g. "so is the best type of question for eliciting information an open question?"

Before you get on to that though - set your objectives for the interview - what are you trying specifically to get out of the interview and how will you know that you have got it? Make sure you are interviewing the right person, plan your questions, let the conversation flow, start with open questions to elicit, use closed questions to confirm, record actions, decisions, issues etc, let the person being interviewed know the next steps in the overall analysis process and how you will use their information they just gave you and you're done.

Easy?!?

Hope that helps!

Guy

Hiya Grant, welcome to BA-land. :)

Two techniques you may find useful:

1. People, Systems, Data - (Article on how to do People-Systems-Data Requirements Analysis) Begin by identifying, in this order, the people who will be involved in the use case, then identify which systems will be used by those people in the use case, then identify the data that the systems will move around and otherwise manipulate. These will not be open-ended questions (which are indeed useful) but they will set the stage for more in-depth questions. Your challenge will be to get the users to walk with you through this exercise before they jump to their pet feature.
2. Use this Use Case question framework:

Description:
What is the Actor's Goal?
What are the high-level actions the actor will need to take to reach that goal?
Assumptions:
What are the assumptions we are making when analyzing this use case?
Frequency:
How many times per minute, per hour,etc.
Actor: 
Who uses the system (what is their job)?
What other systems will interact with the system?
Who or what provides information to the system?
Who or what retreives information from teh system?
Trigger:
What event causes this use case to happen?
What actor initiates this use case?
Preconditions:
What conditions must be true before this use case can begin?
What state is the system in before this use case can being?
Postconditions:
What conditions must be true when the use case ends?
What state will he system be in at the end of the use case?
Main Steps:
How does the actor interact with the system?
What does the system do at this step (present options, display data, execute a process)?
What does the system do next?
What does the actor do next?
Is there part of this use case that is another use case called by multiple use cases?
Alternative Courses:
What possible error conditions exist at each step of the main scenario?
If X doesn't happen, what should happen?
What are the interrupts that can happen at any time?
What is the "non-happy" path?
What other possible actions can the use take at each step?
If the use cancels out at any step, what should happen?

Let me know if that makes sense. These should give you the big picture and the neccessary detail to build a valid use case. If you've got a good idea for some of it, I would encourage you to create some Strawman Requirements for your users to fill-in and tear apart; it's easier to build-on/criticize than to start from scratch. ;)

Cheers and again welcome!

Justin