开发人员怎么才能够快速理解需求？文档的制作融入了制作者的思想，因此他人理解总是需要一定的时间的。解决问题的思路有两个：一是提供标准通用的做法；二是简化文档，简单的东西总是要容易理解，但简单的东西并不等同于制作容易。
维护文档需要成本。不管如何，维护成本始终是无法避免的，关键在于，能否降低这部分的成本呢？维护成本和文档数量、复杂度成正比，因此文档的数量要尽可能的少、复杂度要降低。此外，减少维护的次数也是关键的因素之一，在讨论精益原则的时候我们说尽可能推迟决策就是这个意思。
针对以上的几点，XP提出了自己的实现思路－用户故事。用户故事简单，每个人都会写，每个人也都能理解，改变起来也很容易。但用户故事只是对系统功能的一个简单的描述，他并不能提供所有的需求内容，因此，在XP中，用户故事的实践需要现场客户的支持。用户故事之所以简单，是因为它只是开发人员和客户之间的一种契约，更详细的信息需要通过现场客户来获得支持。 从XP的观点来看，用户故事有这么几点作用：
客户自己描述、编写需求。对于任何一个需求来说，最理想的状态都是开发人员教授客户编写需求。最差的情况是开发人员代替客户编写需求。毫无疑问的，XP要求的就是最优秀的做法。客户要能够自己开发需求，前提条件是编写需求的技巧应该足够简单，能够很容易掌握，或是经过培训很容易掌握。用户故事就是这样一种简单的机制。
用户的观点。优秀的需求应该是站在用户的角度来思考问题，是用户能够利用系统完成什么，而不是系统自己完成。用户故事很好的达成了这一原则。因为用户故事是用户站在自己立场上编写，表现了用户对系统的期望和看法。
重视全局，而不是细节。需求有精度上的差别，软件开发初期最关键的，是建立一个高阶的需求概况，而不是立刻深入细节。对于XP来说，最主要的细节需求获取的方法是经过现场客户。现场客户随时提供对需求细节的指导。因此，用户故事的重点在于，尽可能全面的发现需求，以及，维持一个简单的需求列表。
评估的依据。用户编写的需求为软件的估算提供了依据。虽然这个依据是比较粗的，但随着项目的发展，开发速度的估算会越来越精确。在需求初期就进行适当的估算，其目的是让用户能够有一个比较直观的成本概念。这为用户制定需求实现的先后次序提供了指导。
用户自己的统筹安排。制定用户故事就像是上商场购物，虽然每件物品都是有用的，但是最后购买的次序和数量则要取决于钱包的厚度。在每一个用户故事具有了成本（即上一条中的估算）之后，用户就能够权衡实际成本和需要，并排定需求的座次。
迭代计划的输入。用户对用户故事的选择直接影响到迭代计划的制定，在第一个版本中，用户希望能够实现哪一些的需求（通过选择用户故事），经过估算，这些需求是不是能够在这个版本中实现，计划需要多长的时间。这些都是需求对迭代计划的影响。
故事的弊端
文章来源于领测软件测试网 https://www.ltesting.net/
