今天读了《构建之法》的第八章。
第八章讲需求分析。需求分析有以下几个步骤：
1.获取和引导需求
找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。
2.分析和定义需求
对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化。
3.验证需求
通过分析报告、用户调查等形式向利益相关者验证团队对需求的认知。
4.在软件产品的生命周期中管理需求
在软件的声明周期中不断对需求进行重新审核并作出调整
需求分为以下几个方面：
1.对产品功能性的需求
要求产品必须实现某些功能
2.对产品开发过程的需求
要求软件开发流程必须满足某些约束条件
3.非功能性需求
“服务质量需求”，能在用户可接受的时间/空间代价内满足他们的需求
4.综合需求
需要多个模块共同完成的需求
获取用户需求的主要方式是用户调查，常用的调研方法有：
1.焦点小组
和一群目标用户的代表讨论
2.深入面谈
与客户详细面谈
3.卡片分类
把收集到的需求进行讨论->明细定义->归类->排序的循环过程
4.用户调查问卷
5.用户研究日志
要求用户记录自己日常工作或生活中与软件相关的行为
6.民族学/人类学调查
和目标用户“同吃同住同劳动”
7.眼动跟踪研究
8.快速原型调研
先让用户使用简单的模型
9.A/B测试
需求分析需要考虑到竞争，书上给出了一个比较系统的框架，NABCD
N：需求
创意解决了什么需求？
A：做法
使用什么招数？
B：好处
能给客户带来什么好处？
C：竞争
有哪些已有的和潜在的竞争？
D：推广
如何推广？
对于功能的定位，可以分为四种，也就是书上说的四个象限
| 外围功能 | 杀手功能 | |
| 必要需求 | 第二象限 | 第一象限 |
| 辅助需求 | 第三象限 | 第四象限 |
在时间估计上，书中介绍的方法是
1.找到一个主持人
2.经过多轮讨论，直到得到一个大家都比较满意的精度数值
在这个过程中，主持人要记住在每一轮估计中探询数据背后的假设。
在实践估计上，书上还给出了一个公式：
Y=X(+/-)X/N
X：估计时间
N：类似开发的次数
所有，如果N=0，估计很可能不靠谱了
对于较大的项目，经典的做法是采取分而治之。
前面都是在抄书，现在说点自己的想法：
看了这一章一个比较突出的感受是：软件工程这个领域出现失败是常有的事情，牵扯到大量的人，太多的环节都可能出现问题。
以前总以为学长们都很厉害，所有上了班的职员都很厉害，原来也不是这样啊...