本书讲解了如何去确定一个软件系统应该做什么还有软件需求调研人员如何与不同的人沟通。需求文档是重中之重，但是大量预先的需求收集和文档会很容易导致项目失败。最常见的是需求文档变成软件开发的目的。我们不应为了写文档而写文档。文档只是为了软件开发更为方便的一种工具，我们不应将大部分的时间浪费在无用的文档撰写上。同时大量的文档也会出现记录语言不准备的弊病。因此我们需要学习和研究，如何更加准确，简洁的描写出用户的需求。这也是这本书一直讨论的问题。
用户故事能够合理的还原场景，使需求调研人员感同身受，这是我的理解，它代表了对用户有价值的功能。这时故事卡就是一种非常有用的工具。故事卡包含用户或者日客户有价值的功能的简短描述，是故事的可见部分，但客户团队和开发人员对于故事的对话更重要。在编写故事时，也有很多需要注意的点，比如故事必须要对用户或客户有价值，故事变为可用代码必须是可实现的。故事之间是独立的，他们之间并不会有很强的依赖性。有用户故事就有用户类型。这也是我们在项目开发中极易忽略但又特别重要的一点。大部分项目小组只考虑单一的用户类型，这是不可取的，会导致软件忽略原本需要的一些用户类型。软件写出来就是为了让人来进行使用的，没有了用户，软件的存在也就没有意义。
需求捕获就像出海捕鱼。鱼有大小之分，需求会随着时间也逐渐变化。需求调研人员需要做的就是将这些有捕捞价值的“鱼”使用各种各样的网捕捉起来，弃掉无用的鱼，也不能漏过任何一条有价值的鱼。而与需求调研人员合作的，便是用户代理。用户能够更好的为我们提供需求分析的案例，因此选好用户代理也是非常重要的。