构建之法读书笔记六
第十章 典型用户和场景
10.1 典型用户和典型场景
①怎样定义典型用户？
我们首先要定义用户的角色。正如戏剧中有正面和反面的角色，软件系统中也有受欢迎的和不受欢迎的典型用户。
- 受欢迎的典型用户——指那些按设计者的期望使用系统的用户，如“网站的购物者”
- 不受欢迎的典型用户——指那些有不正当目的的用户，如在一个房地产业主论坛中滥发房屋中介广告的用户——这些用户也许在别的系统中（如房屋中介论坛）是受欢迎的
典型用户只是我们的设想，还要和这些典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化典型用户
②从典型用户到场景
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千种可能的交互情况，写场景时要有针对性。
③场景怎么写？
- 首先针对每一个场景，设计一个场景入口（描述场景如何开始）
- 接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）
- 然后给场景划分优先级，按优先级排序写场景
④场景之间如何区分呢？
- 找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素
- 把场景组织成一个故事，这样就能把一个完整的用户与系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础
10.2 用例
和典型人物、典型场景的方法类似，用例（UseCase）也是很常用的需求分析工具。用例有这样一些 基本元素：
- 标题：描述这个用例要达到的目标
- 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）
- 主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的
- 步骤（Step）：描述每一步的交互（例如一套正常的ATM取款流程）
- 扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）
10.3 规格说明书（Spec）
①规格说明书（Specification）简称Spec，分为以下两种：
1. 软件功能说明书（Functional Spec），主要用来说明软件的外部功能和用户的交互情况（把软件当作一个黑盒子）
2. 软件技术说明书（Technical Spec），又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子）
②写好一个Spec
第一，定义好相关的概念
第二，规范好一些假设（Assumptions）
第三，避免一些误解，界定一些边界条件
第四，描述主流的用户/软件交互步骤
第五，一些好的功能还会有副作用
第六，服务质量的说明
