首页 > 代码库 > 构建之法——读书笔记（6）
构建之法——读书笔记（6）
第8章 需求分析
8.1 软件需求
寻找需求：
1. 获取和引导需求（Elicitation）
软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。
2. 分析和定义需求（Analysis&Specification）
这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化（需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等）。
3. 验证需求（Validation）
软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
4. 在软件产品的生命周期中管理需求（Management）
在软件的生命周期中，需求在发送变化，技术在发展，团队成员的能力在提高。
对软件需求的划分：
1. 对产品功能性的需求：要求产品必须实现某些功能。
2. 对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件，例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束（安全性检查、代码版权核查、代码规范和支持文档的核查）。
3. 非功能性需求：例如：执行时间限制等。
4. 综合需求：可能牵涉到其他系统的情况。
8.2 软件产品的利益相关者
用户：
顾客：购买这个软件或者根据合同或规定接收软件的人。这些人不一定是软件的直接用户。
市场分析师：市场部门要代表“典型用户”的需求。
监管机构：
软件工程师：工程师也是软件需求阶段的一个重要角色，软件的各种约束、特性会影响到他们的工作效率、开发难度和软件维护的难度。他们应积极参与到软件需求阶段中来。
8.3 获取用户需求——用户调查
用户最需要的>
用户表达出来的>
软件团队能理解的+团队的商业目的>
软件团队成员具体表达出来的（PM写Spec）>
在各种约束条件下，具体执行表达出来的（Dev写代码）>
验证通过的（Test）>
通过各种渠道告诉用户目标（发布/推广）>
用户终于能用上了，但是他们不满意
1. 焦点小组（Focus Group）
2. 深入面谈（In-depthInterview）
一般是一对一。
3. 卡片分类（Card Sorting）
讨论->明晰定义->归类->排序
4. 用户调查问卷（User Survey）
5. 用户日志研究（User Diary Study）
6. 人类学调查（Ethnographic Study）
这种方法听起来学术味很浓，其实可以解释为——和目标用户“同吃同住同劳动”。
7. 眼动跟踪研究（Eye Tracking）
一些研究发现了F模式。
8. 快速原型调研（Quick Prototype）
9. A/B测试（A/B Testing）
8.4 竞争性需求分析的框架
大部分普通用户的需求都有好几个互相竞争的机构在提供服务，对于互联网类型的软件来说，更是如此。很多需求并不是用户提出来的，而是技术的突破让产品团队看到了可以让用户做到以前不敢想、不敢做的事情——但这个时候大多数用户并没有意识到自己有这个具体需求。
1. N（Need，需求）
2. A（Approach，做法）
3. B（Benefit，好处）
4. C（Competition，竞争）
5. D（Delivery，推广）
8.5 功能的定位和优先级
8.6 计划和估计
8.6.1 估计的练习
探询估计数值背后的假设，这是作为项目经理最重要的能力。
8.7 分而治之（Work Breakdown Structure）
做好WBS的几个要点：
1.保证所有子节点覆盖了全部父节点包含的内容。
2.保证各个子节点不要相互覆盖。
3.叶子节点要保证足够小，能在一个里程碑中完成。
4.从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发
构建之法——读书笔记（6）