xp中需要什么样的文档？

我们的团队在开发过程中使用了xp的一些实践，应该说效果还是比较好的。但在需求这一阶段仍然有很大的问题困扰着我。我们的项目基本上都是javaEE的web开发，需求人员（开发团队之外的人，不受我管理，基本上是做售前和产品设计的人员）对于每次项目提交的需求阶段的成果就是美工做的页面，其他说明一概没有。这在项目的后期和测试阶段带来了很多隐患。没有定义具体的约束，数据的流向，前置后置条件，业务逻辑等等，因为开发人员的理解能力或者各自的理解而存在很多差异，导致开发的东西漏洞很多，甚至和需求不符。这当然不是开发人员的错，因为需求还是混沌的，页面根本说明不了任何问题。项目中出现的90%的bug也是由此而产生的逻辑错误等问题。
我一直在想，除了user story外，是不是可以有一份更加详细的文档来细化它，可以作为开发人员的参考。我试图将rup的user case引入，希望能得到较好的效果，其实目的除了细化需求的粒度外，还有个重要的因素就是作为一种凭证和依据，因为，莫名的不断的改变真的很让人反感，而且因为空口无凭也不好说对方。。。
希望各位有经验的给点建议，在xp中需要什么样的文档才好？

删除...

如果是T.D.D的话，测试用例无疑应该将约束包含在内了。
你可以用annotation标记在每个测试case上，然后用个什么工具抽取出来生成相关的文档。
因为XP了，那早期设计就不会非常的详细，否则就不敏捷了。但是必要的记录还是要有的，functional specification应该算是一种需求文档，High level design也应该有。RUP的那堆东西看情况吧，没有必要全都引入的。
其实世界上本没有路，走的人多了，便成了路。说不定你自己独创的一种做法也可以成为一种Best Practice呢。

我也觉得的确存在这个问题，需求文档的目的就是要传递信息，方式并不重要，而且变更是肯定的，粒度太细维护文档是多余的开销

非常感谢你的建议！
tdd的使用还需要进一步推荐。问题就在于case的编写上，这些约束还是要通过某种方式得到而不是开发人员主观的臆断。你上面说的总体功能规格说明我也觉得需要有，另外需求上还是使用story的形式，只是粒度要细一些。