第一章 概览
软件需求是一个沟通问题，文章一上来就阐明了这个观点，这是软件需求与分析的重点。一个项目的成功取决于许多东西，但是最基本的就是开发人员要理解客户的需求，而弄清的唯一途径，也就是沟通。我们需要协同来完成任务，这就意味着，任何一方都不能在这一过程中保持绝对地位。为了确保能在客户那里收集到足够的信息，我们要保证有一个获取信息的过程，用户故事也就应运而生。用户故事描述了对用户、系统或软件购买者有价值的功能，它主要分为卡片（代表客户需求）、对话（需求描述）和确认（需求细节）。用户故事代表对用户有价值的功能，主要对象是用户。
用户故事中有几项十分重要：
①细节：故事的大小也应该做到符合道理，大小适合，过大的话需要分解，过小的话则需要组合；
②时间：也是一个重要的细节，这代表着用户的期望，方便开发人员随时反省项目进行进度；
③客户团队：用以确保软件满足用户的需求的监督者，解决各方面的问题，排列工作优先级、回答问题、测试软件、记录故事，可以由测试人员、产品经理、实际用户或交互设计师组成；
④优势：相较于传统的面向瀑布模型的过程，客户和用户可以在项目整个过程中全程参与。在这一过程中，用户可以和编程人员更好地配合，让用户参与去编写故事，可以更好的弄清需求的优先级；可以一起决定迭代长度。为了保证发布计划，我们还会讲故事排列成堆，一堆表示一轮迭代，同时包含着一定的故事，在每轮的迭代中不断修改计划，可以让项目进度更加合理；
⑤规划发布和迭代：发布由多轮迭代构成。考虑故事的优先级，需要考虑实际、成本等一系列东西；
⑥验收测试：用来验证实现的用户故事是否符合客户团队的期望。团队中应该有人员来主管测试工作，可以大大减少开发人员走弯路，也就加快了整个项目的进度；
⑦改变：相对于之前的需求文档或是用例，用户故事做出了很大的改变，不再依靠一张图或是一份文档就简单地记录客户的需求，更容易与客户进行交流，也更易用以获取真实的需求。
第二章 编写故事
一个良好的用户故事应该有以下特点：独立的（Independent）、可讨论的（Negotiable）、对用户或客户有价值（Valuable to Purchasers or Users）、可估计的（Estimatable）、小的（Small）、可测试的（Testable），也就简称为INVEST。
首先，我们要尽量减少故事之间的相互依赖，故事间的依赖会导致问题的估计更加困难。可以通过：互相依赖的故事合并或是用不同的方式分割故事来消除依赖。我们也要意识到，故事是可以讨论的，我们可以在卡片上确定需求，并且可以给予一定的注释，增加可阅读性，也更易讨论。简单的注释才能带来好结果。故事要对客户有价值，避免那些只针对开发人员的故事、用户界面、技术方面的定义。所以更好的方法，是让用户来编写故事。故事也要是可估计大小的，为了做到这个，就要避免：开发人员缺少领域知识、开发人员缺少技术知识、故事庞大这三种情况，也就是要做到小。或者应该说大小合适，不能出现史诗故事，应分割为复合故事（整合小故事）和复杂故事（很大且不易分解的故事）。对大故事进行分解，对小故事则要进行合并，保证整个用户故事的合适。故事还必须是可测试的，成功的被测试才代表故事正确的被实现。
第三章 用户角色建模
很多情况下，需求分析人员会忽略一些用户故事，但是他们又是不可或缺的。所以，在以用户为中心的设计和交互设计的规则上，识别用户角色和虚构人物会对编写故事有诸多好处。事实证明，一个项目常常有多种受益者，他们的需求都是不同的，它们代表着不同的用户角色。不同的角色的故事有差异，也存在相同点。所以关键就是进行角色建模，通过以下步骤：通过头脑风暴，列出初始的用户角色集合（要求开发人员和客户一起参与，大家尽可能提出可能参与的角色）、整理最初的角色集合（把有关联的角色进行排布，初步整理）、整合角色（整合和浓缩角色，对角色进行合并或丢弃，最后排列）、提炼角色（对每一组角色进行详细的描述，确定他们各自的信息，并对角色之间的关系初步了解、区分）。通常，我们还需要虚构人物（假想用户角色代表，使人物更生动、更具体）和极端人物（考虑那些与众不同的人，可能会让我们写出之前遗忘的故事）进行使用。通过这一系列的行为，便对用户需求中涉及到的用户角色进行了建模，利于我们后面的进一步的进程。