The word 'proper' is a trigger word for me . So lets talk about requirements gathering; what is 'proper' requirements gathering? How much detail do you need to get for it to be good enough?
Requirements are like measuring the perimeter of a country; the shorter your ruler the longer it is, the more curls and crannies you find. And so it is with requirements; the more detail you get into the more you find. But there is a point at which the requirements become the application. There is a point where the process of examination of the problem to find what is needed explores the design, where screens are designed, data structures determined, reports specified.
With agile you realise that development is a process of navigating a virtual space of possible applications. Your strategy is to use evolutionary processes to navigate towards the solution needed based on the fitness function of meeting the users real need. If you go to a user with a blank sheet of paper how can they know what they will need in detail? They don't really know. The process of finding out what they need is design.
With Agile the requirements are limited to statements that the user can express; very high level and general. They are place holders for a more in depth exploration and feedback. And so we get to the most critical aspect: feedback. Without a feedback cycle and iteration the software does not evolve. The waterfall style development processes inevitably turn into ad hoc evolutionary projects. The difference with Agile is that we are honest; we don't try to say we can know more than we do, or have some magical power to get perfect requirements before starting. We put our ego on the shelf and acknowledge that there are no perfect requirements, no perfect designs, no perfect code. We place evolutionary principles such as short iteration cycles, regular user feedback, and unit testing at the centre of our approach,