今天读了《构建之法》的第八章。

第八章讲需求分析。需求分析有以下几个步骤：

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，估计很可能不靠谱了

对于较大的项目，经典的做法是采取分而治之。

前面都是在抄书，现在说点自己的想法：

看了这一章一个比较突出的感受是：软件工程这个领域出现失败是常有的事情，牵扯到大量的人，太多的环节都可能出现问题。

以前总以为学长们都很厉害，所有上了班的职员都很厉害，原来也不是这样啊...

[读书报告]构建之法(三)