标签:
今天读了《构建之法》的第八章。
第八章讲需求分析。需求分析有以下几个步骤:
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,估计很可能不靠谱了
对于较大的项目,经典的做法是采取分而治之。
前面都是在抄书,现在说点自己的想法:
看了这一章一个比较突出的感受是:软件工程这个领域出现失败是常有的事情,牵扯到大量的人,太多的环节都可能出现问题。
以前总以为学长们都很厉害,所有上了班的职员都很厉害,原来也不是这样啊...
标签:
原文地址:http://www.cnblogs.com/buaasts/p/4176325.html