构建之法阅读笔记07

第十章 典型用户和场景

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）

第三，避免一些误解，界定一些边界条件

第四，描述主流的用户/软件交互步骤

第五，一些好的功能还会有副作用

第六，服务质量的说明

 

 

心得体会：

在过去我只从我的角度出发去解决问题，从来没有从用户的

角度，这一章主要说的就是要从用户的角度去解决问题，软

件是给用户带来方便的，所以在以后的学习中，应该注重从

用户的角度出发去开发和完善软件。