The main thing we do in requirements gathering is to 'collect information on what users wanted'. And we build and deliver a system which fulfills users needs. You can eloborate this in any job interview based on the following points.
1. Users are not technical (business users), they will tell you their needs in terms of business, you need to convert their needs to technical specification. So your team can understand and build a system to server your users.
2. Sometimes users do not know what they need or they lack clarity, so you can suggest them a functionality or feature which works better.
3. Also it is better to prioritize the requirements, like Priority 1 features are must, Priority 2 features optional etc etc.
4. It is important to get what 'exactly' your users want, failed to do so will cause a bad system which doesn't help them.
Few problems during requirements gathering ...
1. Users sometimes asks impossible things, it may be possible to do a particular feature for them, however, considering cost and timeline it is impossible to do.
2. Users do not agree on what other users (their colleagues) have proposed. So it is better to involve all stakeholders in the requirements meetings.
3. If we ask users to prioritize requirements, they may prioritize everything as P1. (This happend to me )
4. Some requirements may be technically challenge to do, however we should be able to find a workaround if not worst case, propse alternate feature to users and get approval.
Hope this helps.
Sai Surya, SCJP 5.0, SCWCD 5.0, IBM 833 834
http://sai-surya-talk.blogspot.com, I believe in Murphy's law.
Remember the old programmer's rule: the quickest way to find out what users really want, is to give them what they ask for.
This is because they will tell you what they think they need, but it's very rare for your users to understand everything about what their systems should do. So be prepared for some nasty surprises when you start to look at their requirements in detail.