ANSWER

While this is a broad question, it is often used by interviewers to find out whether the candidate has actually performed requirements elicitation in the past and has experienced its challenges. Once challenges are mentioned many interviewers proceed to ask what the candidate has done or would do in order to overcome those problems.

So, here are some of the problems faced by business analysts during the requirements elicitation/gathering activities:

Contradicting/Conflicting Requirements - These are requirements received from different stakeholders or from same stakeholder at different times and which cannot all be met at the same time because their are in conflict. What the BA can do: get all stakeholders in the same room (if possible), document and publish stakeholder requirements or meeting notes while they are fresh.

Communication Problems - This is a broad category of requirements issues and includes: miscommunication, language barriers, wrong assumptions, unclearly defined vocabulary or domain model, variance in vertical domain knowledge, using only one-way communication channels (over the wall requirements), notation differences (lack of standards), etc. What the BA can do: continuously improve communication skills, document info gathered and publish for review/feedback, verify assumptions, create a glossary of terms, use multiple subject matter experts, etc. 

Undocumented Processes - This is the reality in most organizations. The business runs with "word of mouth" or poorly documented processes and procedures. In these situations, to the high-level executive it may look like everybody is doing the work the same way when the actual details/steps of the process vary from end-user to end-user. The business analyst is often forced to reverse engineer the business processes every time a new projects is started. What the BA can do: Document existing business processes and the differences among the various users. Present the documented processes to the stakeholders/high-level executives. If possible and within the scope of duty, create and maintain an up-to-date library of existing business processes/operating procedures.

Lack of access to end-users - On many projects the stakeholders and IT management "think" they understand the requirements and what happens in the business and do not enable or allow the business analyst to have direct access to the end-users. What the BA can do: Present your case to the project sponsor as to why it is key to observe the users at work and find out how each activity is actually performed and the types of problems faced by the user in their day-to-day work.

Instability of UI Preferences - Stakeholders and end-users who are new to the requirement elicitation process or who are faced with new or unprecedented concepts or processes tend to have a hard time identifying (and feeling good about) their preferences and, therefore, they tend to keep changing their minds. What the BA can do: use prototypes and other visual tools such as diagrams to gather, document, and verify requirements.

Abundance of Choice - When stakeholders or end-users are presented with too many choices they generally have a harder time deciding the option to select. When they do make a decision they are less satisfied than if those who have to pick from a much smaller list of options. What the BA can do: provide stakeholders and decision makers with more than option (when possible), however do not give them more than 3 options to choose from.

Stakeholder Design - This is the case when the stakeholders or end-user have the urge to design the system (how the system should work) rather than providing the requirements (what the system should do). The problem with this pattern is that the BA is no longer able to distinguish between requirements and design decisions. What the BA can do: ask the stakeholders/users what the system should do and when you get the answer keep asking "Why?". Eventually you should be able to get to the actual problems faced by the user and you'll be able to understand the "real" requirements.

Bad Requirements - Requirements are considered "bad" if they are: ambiguous, incomplete, not verifiable, etc. When stakeholders provide and analysts document bad requirements, they result in systems which are not completed or not used. What the BA can do: develop a checklist of characteristics and tests which you can check for each requirement to ensure all the requirements send for sign-off are all good to go.

These are just some of the problems faced by requirements analysts during the elicitation process. There certainly are many more.