【构建之法】第8章-需求分析

本章重点：

• 软件需求的类型
• 利益相关者
• 获取用户需求的常用方法和步骤
• 竞争性需求分析的框架NABCD
• 四象限方法
• KANO图
• 项目计划和估计的技术
• 任务划分的技术WBS

1 软件需求

如何准确而全面地找到需求：

• 获取和引导需求（Elicitation）：软件团队需要找到软件的利益相关者，理解和挖掘他们对软件的需求，引导他们表达出真实的需求；
• 分析和定义需求（Analysis & Specification）：这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化，包括需求实现的最后期限、实现需求大致所需的时间和资源成本、各个不同需求的优先级、需求带来的收益等等；
• 验证需求（Validation）：软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知；
• 在软件产品的生命周期中管理需求（Management）：在软件的生命周期中，需求在发生变化，技术在发展，团队成员的能力也在提高。多方面的变化和发展都要求我们不断对需求进行重新审核并做出相应的调整。

软件需求的划分：

• 对产品功能性的需求；
• 对产品开发过程的需求；
• 非功能性需求：也叫“服务质量需求”（Quality of Service Requirement）；
• 综合需求。

软件团队和客户代表要在需求阶段把这些问题定义清楚。

2 软件产品的利益相关者

• 用户：或称最终用户（User，End-user）；
• 顾客：或称客户（Customer，Client）；
• 市场分析者；
• 监管机构；
• 系统/应用集成商;
• 软件团队；
• 软件工程师。

3 获取用户需求-用户调研

• 焦点小组（Focus Group）：找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么，用户对软件的评价等等；
• 深入面谈（In-depth Interview）：通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。这通常是一对一的采访；
• 卡片分类（Card Sorting）：把各种需求做成便于规整的小卡片（或小贴纸）上，然后反复进行下列活动-“讨论->明晰定义->归类->排序”；
• 用户调查问卷（User Survey）：这种方法是向用户提供事先设计好的问题，让用户回答；
• 用户日志研究（User Diary Study）：要求用户记录自己日常工作或生活中与所用软件相关的行为，供软件团队分析；
• 人类学调查（Ethnographic Study）：可以解释为-和目标用户“同吃同住同劳动”。

4 竞争性需求分析的框架

NABCD模型：

• N（Need，需求）
• A（Approach，做法）
• B（Benefit，好处）
• C（Competitors，竞争）
• D（Delivery，推广）

5 功能的定位和优先级

6 计划和估计

6.1 目标、估计和决心

• 目标：表达一个希望达到的状态；
• 估计：以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事；
• 决心：保证在某个时间之前完成预先规定的功能和质量。

6.2 找出估计后面的假设

软件工程专家Paul Rook说：“***我们其实并不是不会估计，我们真正不会的，是把估计后面藏着的种种假设全部列举出来。***”

6.3 提高估计能力的招数

• 参考前人的经验
• 快速原型法

7 分而治之（Work Breakdown Structure）

PM需要站出来领导大家，把看似巨大无从下手的项目逐步分解为可以操作的工作。