作者认为这套需求过程可以适用于多种软件开发的情况。
这套需求过程虽然不是唯一的解决方案，但学习这个过程可以获得很多帮助。
有很多客户采用了这个需求过程。
这些客户和他们都达成一个共识：发现需求需要一个有序的过程。
项目启动、网罗知识、制作原型、编写需求、需求审核、需求复查、产品设计构建、产品使用与演进
需求发现是所有构建活动先驱，应该非常重视。
作者假设我们在开发一个新产品，用这个新产品来介绍这个过程。以此避免旧项目的限制。
作者介绍了一个破冰项目，它的目标是在道路结冰之前，调度车辆进行撒盐，这样会使得道路更安全。另外如果撒盐合适的话，可以减少预算和对环境的影响。
项目完成需要大量的准备工作。
作者先从启动会介绍需求分析工作。
作者认为启动会需要凑齐一下利益相关人：
要买的人、要用的人、设计系统的人、实现系统的人、可以咨询的人
并让他们对关键问题达成一致看法。
作者认为会议要确定：
系统要做什么，以及系统不做什么。
作者提出用白板画业务模型图。
业务模型图包含两个部分，一个部分展示系统所包含的功能，另一部分展示与系统相联系的其他系统。
画好这个图后，需要确定利益相关人。
需求分析师跟这些利益相关人合作，找到所有的需求。
作者认为项目启动会议需要达成共识：
1.能不能赚钱？
2.能赚多少钱？
3.能否做成？
为了达成这些共识，会议需要对项目成本进行评估，并提出可能存在的风险。
另外作者认为早死早超生，宁可几个人决定什么都不做，也不要组织更多的人，把大家的时间和感情浪费在没有希望的项目上。
如果还有很多事情不确定，就带着问题去调研，等调研后再评估。
需求分析师在会后要确定业务内容，为了方便，作者建议将业务模型图拆分成一些业务用例。
作者提出：业务用例是响应一个“业务事件”所必需的功能。
作者认为业务事件可以独立分配给不同的需求分析师。分析师可以通过做学徒、场景分析、用例研讨会等方法来发现工作的本质。分析师可以与其他利益相关者交流，获得最终产品的其他需求。
作者认为需求工作中最难的是发现系统的实质。别人提的解决方案或者当前工作的需要都不是问题的实质。可以通过想象没有技术下的工作来发现系统的实质。
了解到工作的实质后，再与利益相关者合作，决定最佳的产品。
1.他们需要确定对工作中的哪些部分进行自动化或者改变？
2.这些决定会对工作产生什么影响？
作者认为理想的需求过程：
工作范围图->业务用例->用户故事->PUC场景->需求
最好的产品并不是对原有情况的模仿，而是要与利益相关者间隙合作，找到更好的完成工作的方式。
作者提议使用贴纸进行当前业务的建模，用纸笔进行对将来产品的建模。
作则认为需求场景非常有用，可以在短时间内，让每个人理解工作要做什么，并达成一致意见。在他们达成一致之后，场景就成为需求的基础。
为了避免需求被误解，需求必须用一种无二义、可测试的方式写下来，同时通过利益相关者的审核，然后再传递给开发者。写下需求可能是繁重的负担，但是这对于需求沟通以及产品交付都很重要。
作者认为需求需要包含三个部分：
1.需求内容
2.需求理由
3.需求的验收标准
作者提到两种机制来编写需求：
1.需求规格说明模板，需求规格的一个提纲（问题模板）
2.需求项框架，需求有一些属性组成（单个问题的属性）
迭代式的工作并不排斥需求，而是寻求另一种方式来发现和沟通。
待续->2.8质量关
