'''Detailed discussion of the ExtremeListening portion of ExtremeProgramming.'''

I have my doubts if the CTLR will be enough to make delighted customers. I learned in every project that Listening is far from sufficient to learn the needs and expectations of customers. They may not know what they want, or describe the paper-way-of-working or omit all things they consider obvious. In the worst case they describe an espoused system, not the system in use. 
This CTLR approach may work for some well known domains (payroll?) but will fail on less beaten tracks, I fear. 
-- MartineDevos

Part of ExtremeProgramming is a careful balance of political power between the developers and the client. The story gathering process is certainly not, "Well, User, what do you want the system to do?" There's a lot more structure and ritual to it, some of which I don't understand well enough to write about.

Requirements is a dialog, not a document. Also, programmers should make technical decisions, and business people should make business decisions. You will eventually get in trouble if this isn't true. Finally, if you think a big payroll system is well understood, I would wager good Swiss money that you haven't built one.
-- KentBeck

The requirements document isn't a goal; it is a side-effect of the requirements process.  In some organizations it is an essential side-effect. When Fred Bigwig roars, "Why are all the buttons pea-green?", it is helpful to be able to say "Because you ordered pea-green buttons on April 29th."  People do forget what they asked for, and do make contradictory requests.  Requirements documents can guard against the first problem and highlight the second problem. 
--BetsyHanesPerry

In organizations which take requirements documents and adherence to same seriously but where the requirements for addons are changing frequently, one should look at the ScrumProcess.  It is a highly structured method which
can be very successful. --MarkSwanson.
----
CategoryRequirements