《构建之法》笔记---第十章 典型用户和场景

《构建之法》笔记

第二章 个人技术和流程
第四章 两人合作
第六章 敏捷流程
第十章 典型用户和场景

---

---

前言

典型用户（Persona）和场景（Scenario），软件功能说明书（Functional Spec）和技术说明书（Design Doc），功能驱动是设计（FDD），用例（Use Case）

---

一、典型用户（Persona）和场景（Scenario）

一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
对每一个典型用户决定其的目标（他使用系统想要达到什么目的）。对每一个目标，列出达到目标所必须经历的过程，即场景，也可以叫故事（story）。
从场景到任务。

二、用例

常用的需求分析工具。基本元素：

• 标题：描述用例要达到的目标
• 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（描述一些和时间相关的场景）
• 主要成功场景：一系列步骤描述角色怎么和系统交互，从而达到目标。
  • 步骤：描述每一步的交互
• 扩展场景：描述一些扩展的交互，例如一些意外情况

三、规格说明书（Specification）

软件功能说明书（Function Spec）

主要用来说明软件的外部功能和用户交互情况（把软件当作一个黑盒子）。
从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部实现细节。

模板：

1. 目标包括什么，不包括什么（规范好一些假设）；
2. 用户和典型场景（主流用户）；
3. 术语及定义（定义好一些概念）；
4. 用户是如何使用软件功能的（软件交互步骤）；
5. 各种边界条件；
6. 功能有什么副作用，对其他功能有什么显性或隐性的依赖关系；
7. 什么叫“好”，什么叫“这个功能测试完了，可以交付了”;
8. 软件发布后，有哪些项目相关的数据可收集，如何在实现阶段就把数据收集的准备工作准备好；

软件技术说明书（Technical Spec）

又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子 用于描述开发者如何去实现某一功能，或相互联系的一组功能。
注：设计文档应该说明设计是如何体现一些设计原则的。

四、功能驱动的设计（Feature Driven Design）

如何把用户需求变成团队成员可以直接操作的开发工作，FDD是针对这个问题的众多方法论之一。

构成步骤：

1. 构造总体模型（Develop an Overall Model）
2. 构造功能列表（Build a Feature List）
3. 制定开发计划（Plan by Feature）
   考虑因素（各实体和功能之间依赖关系；复杂程度；高风险难度功能适当提前；…）
4. 功能设计阶段（Design by Feature）
   分析一组相关实体及其功能，通过时序图（Sequence Diagram）和其他工具，展示各个实体和函数如何动态地结合起来实现一个功能。
5. 实现具体功能（Build by Feature）
   具体团队成员实现类/函数，进行相关单元测试，并在代码复审后，把代码集成到产品构建中

注：FDD对单元测试之外的测试（集成测试、压力测试、对用户界面和用户体验的测试）讲述不足。

---

总结