Extreme Programming projects do not try to produce a detailed requirements document and then freeze it. Instead, the Onsite Customer is actively encouraged to steer the project by changing his mind about what exactly it is that the team is supposed to deliver.
By freezing requirements, a team is choosing to delay when it recognizes that the requirements have changed. The longer the period of the requirements freeze, the more likely that when the application is eventually delivered it will not match what the users really need. It may, however, still be a reasonable fit, allowing a new project to start to delivery additional functionality while the users happily work with the first version. For most purposes, however, if an application does not meet current requirements it is effectively a buggy application.
Slow-moving environments lend themselves to requirements freezes; fast-moving environments do not. The difference is that between efficiency and effective adaptation. In a nearly static environment, it makes sense to optimize for efficiency, so requirements can be carefully documented and baselined. In a fast-moving, dynamic environment, optimized for efficiency is completely the wrong strategy; effective
adaptation is a much better option. Rather than try to control the changes, we must instead strive to respond rapidly to each change as it occurs.
— Pete McBreen, Questioning Extreme Programming, Chapter 16