1. CHAOS Report调查结果显示：软件项目成功因素的前三名：用户的参与；执行层的支持和清晰的需求描述。失败的前三名是：不完整的需求，缺乏用户参与和资源不足。
2.采用数据说话是技术人员走向成熟的一个要点。
3.想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而是不让用户将一大堆技术动作翻译到自己的业务场景中去。
4. 需求验证本是需求质量关，其目标是暴露更多的错误，也就是说我们要的不是签字，而是指出潜在的问题与错误！
5.需求规格说明书应该采用业务导向的属性层次结构来组织。树形层次结构应该面向不同的层面：决策者（高层），事务管理层（中层），操作层（基层）将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总。
6. 对于需求分析员而言，真正的专业主义是基于业务利益（解决问题，创造机会，提高管控力等）的沟通。
7.不切实际的用户期望的原因在于软件的无形和成本的不透明。
8.到底谁才是知道用户最需要什么功能的人呢？产品经理，开发人员还是用户代表？其实最了解用户需求的是软件本身。看访问量！
9.优先级的划分经常是拍脑袋的产物。
10.解决沟通失真的方案：1 文档；2 Re-view. (缓解沟通失真的最有效的方法是及时复述.)
11.项目经理的需求控制：有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。
12. 需求分析的本质在于业务分析，而非技术分析。方法：多问why.
13.有种低效的管理叫“打地鼠”，有种低质的医术叫“头痛医头，脚痛医脚”，有种低级的观点是“软件项目失败的关键在于项目管理技能不足。”
14.以“定性”的方法来描述非功能需求，实际上就是一种无效信息传递。
才读完了第一章，就有很多感触和共鸣。以上更多摘抄的是结论，而就本书的写作方法而言，既有归纳也有演绎，很给力。