第一章 基本事实
本书一开篇就列出了一些11条基本事实，包括：
- 需求其实并非在谈需求
- 如果我们必须构建软件，那么他必须为拥有它的人提供最理想的价值
- 如果软件不必满足需求，那么你怎么干都行。但是如果他打算满足需求，你就必须知道要求是什么，才能构建真正的正确的软件
- 构建一个软件和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者
- 需求不一定要写下来，但构建者必须知道他们
- 客户不一定总能给你正确答案，有时候客户也不可能知道什么是正确的，有时候他们就是不知道需要什么
- 需求不是偶然得到的，要通过某种有序的过程得到
- 你怎么迭代都可以，但仍需要理解业务的需求
- 没有银弹。所有方法和工具都无法弥补糟糕的想法和糟糕的手艺
- 想要成功地实现需求，需求就必须可度量可测试
- 作为业务分析师，你将改变用户思考这个问题的方式。不是现在就是将来
这些事实虽然有的你会点头称是，有的你仍然抱有疑虑，甚至有的情况是你从未遇到过思考过的。
但是随着思考的深入，你会赞同，这些确实就是事实。
刚开始接触需求分析的时候，大部分人都会抱怨“客户不懂事”，连自己想要什么都不知道，自己的需求都不知道，描述不清楚。
其实我们退后一步看看这件事情，就会发现很多人都不知道自己的需求。
比如现在换季，你想去商场里买一件外套。
那你可能可以理解为自己的需求是一件外套，但是这个外套是正装还是运动装，是羊毛的还是化纤的，是稳中的黑白灰，还是欢脱的粉紫蓝。但这些问题其实都不是最根本的问题。
如果深入思考下去，你会发现其实你想买外套的真正目的不是为了御寒，而是单纯的就想买新衣服。最终你会买一大堆的裙子、针织衫、裤子、鞋子、包包，唯独没有买的就是外套。
清楚这些事实后，书中给出了需求的定义：
需求就是产品支持其拥有的业务所必须完成的事情，或让拥有者接受并感兴趣所必须具备的品质。
一般情况下，需求分为：功能需求、非功能需求、限制条件。
前两个很好理解，最后一个限制条件，我们在之前的需求分析实战中也提到过，其实就是一个全局性的约束，包括：产品的上线时间限制、运行平台限制、浏览器版本限制，其他政策法规的限制。
第二章 需求过程
本书主要是基于Volere需求过程进行编写的。在本章中就Volere需求过程的各个活动进行了基本的介绍。
整本书是以一个IceBreaker项目为例，这个产品能预测何时何地道路会结冰，并调度卡车用除冰物质处理道路。
这个产品使得道路管理部门能够更准确的预测冰情，更精确地安排道路处理，从而使道路更安全。
也许这个例子距离我们比较远，但是我们仍然可以以自己的产品进行代入分析，或者继续使用我们的山竹图书馆作为案例。
小婧最近也在写山竹图书馆的连载，其实里面也会包含这本书以及《软件需求最佳实践》中的一些思想。
本章具体的各个过程我就不在此赘述了，因为后面的各个章节会进行详细的介绍。
在这里我觉得需要强调的是，为了让我们能最大化阅读本书的收获，在讲到相应过程活动的交付物时，结合自己的理解回答以下问题：
- 在你的环境中，该项交付物被称为什么？一般使用过程模型中的术语定义，并确定在你的组织中等价的交付物。
- 该项交付物与本项目有关吗？
- 对该项交付物知道多少？是否有足够的知识，能避免在它上面花费额外的时间？
- 谁负责得到该交付物，明确提交产品的哪一部分是由谁负责的，当涉及多个人时，需要定义它们之间的接口。
- 该交付物何时产生？将项目阶段与一般过程进行对照。
- 该交付物在何处产生，一般的交付产物，常常是由多个部分形成的，这些部分是在不同地点得到的。定义不同地方之间的接口，并规定他们的工作方式。
- 谁需要在组织内review这些交付物？在组织内寻找已有的文化检查点。在项目中是否有大家公认的阶段，是否由同级人员，用户或经理来review需求规格说明。
希望大家带着这些问题来和小婧一起共读接下来的章节。
写在最后：
我们来贴一下阅读计划哦。
计划从2016年11月1日开始，总共花费21天完成。
假设：每天花半个小时阅读，阅读速度约为15页/30分钟。
将本书划分为5个部分，具体计划为：
Part1
阅读内容：前言（1~2章）
时间：11-01~11-02，2天
Part2
阅读内容：问题及业务分析（3~7章）
时间：11-03~11-09，7天
Part3
阅读内容：解决方案及需求规格（8~11章）
时间：11-10~11-14，5天
Part4
阅读内容：需求验证（12~15章）
时间：11-15~11-18，4天
Part5
阅读内容：沟通与管理（16~17章）
时间：11-19~11-21，3天
小婧是一名行走在产品路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
