The whole point to agile development is that we know that requirements are going to change midstream (probably many times). That's fine because the customer can change the priority of the items at any time.

One thing that isn't mentioned (there isn't room to discuss SCRUM or XP or any other methodology in less than several books) is that you often have someone between the customer and the technical people for translation purposes. This person, we'll call it the business analyst role, would have some knowledge of the problem domain along with some technical knowledge. The analyst can do some basic modeling of the processes in a form that both the techs and the customer can understand (use cases, process flow diagrams, etc.).

Techs often consider the customer to be stupid because the customer doesn't understand the technology and vise versa. Agile methods provide a situation where business people make the business decisions and technical people make technical decisions; i.e. everyone does what they are good at and not what they are bad at.