构建之法第八章学习小记
需求分析
需求分析是一个软件工程团队开工的第一步，也是至关重要的一步。如何与客户或队内成员妥善的交流，明确他们的需求，才有后续的设计与开发。如果误解了用户的需求，轻则修改一部分的代码、重则整个阶段的工作将功亏一篑！
1. 软件需求
人们为了解决生活中的问题，需要求助于软件。人们的需求五花八门，我们该怎么准确而全面的找到这些需求呢？
- 获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。需求可以来自各种管理机构、软件企业本身、技术团队本身。
- 分析和定义需求：从各个角度对需求进行量化、调整。
- 验证需求：软件团队还要把自己提取出的用户需求，形成报告或文档，与客户反复确认，以确保达成共识。
- 管理需求：随着时间的推进，需求可能发生变化。随着团队成员的能力的提高，可能对需求的重视程度会逐渐淡化。这些都要求我们不断地审核、调整需求。
2. 软件团队的利益相关者
- 很多人都是软件的利益相关者，我们在考虑软件需求时要考虑这些利益相关者。
| 类别 | 备注 |
|---|---|
| 用户 | 直接使用软件的人 |
| 顾客 | 购买这个软件或接受软件的人 |
| 市场分析者 | 代表“典型用户”的需求 |
| 监管机构 | 某些软件必须符合监管机构的规章制度 |
| 系统/应用集成商 | 复杂软件的开发和应用过程中，负责给客户提供咨询、服务、集成服务等工作 |
| 软件团队 | 完成整个软件开发的团队 |
- 软件开发不可能一次满足所有利益相关者的要求，但是我们一定要让相关角色在这个阶段有机会提出他们的需求和意见，同时，要弄清楚“他们想从软件中得到什么”。
3. 用户调研
软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程。
用户最需要的>
用户表达出来的>
软件团队能理解的 + 团队的商业目标>
软件团队成员具体表达出来的（PM写Spec）>
在各种约束条件下，具体执行表达出来的（Dev写代码）>
验证通过的（Test）>
通过各种渠道告诉目标用户（发布/推广）>
用户终于能用上了，但是他们不满意
一张“秋千图”可以形象的描述这个过程：
- 下面是几种常用的用户调研方法：
| 名称 | 备注 | 缺点 |
|---|---|---|
| 焦点小组 | 找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等 | 1. 大家会出于讨好其他人的心理,避免不一致的意见或冲突、2. 讨论者对于他们不熟悉的事物不能表达有价值的想法、3. 讨论者容易受到主持人有意或无意的影响 |
| 深入面谈 | 通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这通常是一对一的采访 | 费时费力，效果往往取决于主持面谈的团队成员的能力 |
| 卡片分类 | 各种需求做成便于规整的小卡片（也可以写在小贴纸上），然后反复进行下列活动：讨论 → 明晰定义 → 归类 → 排序 | - |
| 用户调查问卷 | 向用户提供事先规定好的问题，让用户回答 | 如果调查方式不当，不客气地要求用户回答几个问题。用户在回答这类问题时，可能会心不在焉，胡乱回答。失去调查的意义 |
| 用户日志研究 | 这一调研方式要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析 | 要求用户有很高的自律能力。另外，如何保护用户的隐私也是一个问题 |
| 人类学调查 | 和目标用户“同吃同住同劳动”。例如，与其坐在办公室里想象如何给老年人设计手机，不如去和老年人生活几天，从生活中得到体会和需求 | - |
- 结合实际情况，根据需求选择最合适的方法。
- 各种方法的分类图（下图）表示了这些方法在（态度∶行为、定性∶定量）上的分野：
