Agile software development: How do you react *financially* to changing user requirements?

Question

There's one thing I've always wondered when reading about all this "agile development" stuff here on SE and other sites:

In "traditional" software engineering, you

1. collect the user's requirements,
2. write a specification based on these requirements,
3. give it to the customer and bill him for the work done so far,
4. do a (rough) technical design, so that you can estimate the cost of implementation,
5. give the user a price quote for the implementation,
6. wait for the customer to sign the specification and accept the offer,
7. design, implement, test,
8. bill.

If, during the process, the requirements change, you send an offer (with a price) for the desired changes (or do it for free if the change is small, you like the customer and the customer doesn't do it too often).

So, how does this work (financially) in an agile project, where frequent requirement changes are a part of the process?

• Do you write an offer for every design change? (Wouldn't this be quite a mess?)
• Or do you negotiate a fixed price and hope that the customer does not change the requirements too often? (Could be risky, I know customers who would use this opportunity to request new features for years before accepting that the project is completed.)
• Or do you just bill the customer for the total time required? (Could be risky for the customer, who does not know the cost in advance.)