构建之法-10-典型用户和场景

典型用户和场景.png

---

10.1 典型用户和典型场景

• 1-定义典型用户
  我们开发一个软件之前要先思考分析我们的用户在哪里，用户长什么样子，有什么需求。所以，我们要先仔细斟酌软件的典型用户有哪些。
  可以给用户准备统一的模板：例如，包括年龄、收入、教育、偏好等等。当我们要做一个购物网站时，就会有很多角色：商户、买家、浏览者、广告、管理员等等。
  

  

  典型用户——网管阿毛

• 2-从用户到场景
  分析出典型用户之后，开始思考该用户使用软件的详细过程——场景/故事/Story。那么，场景怎么写？
  

  

  商户上货场景

• 3-从场景到任务
  例如，用户登录场景：

1. UI层。子任务为：界面设计，货物资料处理，文件上传处理，编辑控件等。
2. 逻辑层。子任务为：用户输入字段合法性处理，上传图像逻辑和缩略图处理，资料保存逻辑等。
3. 数据库。子任务为：资料读取的存储过程，图像的索引建立和维护等。

• 4-场景/故事/Story的模板

场景 / 故事 / Story
版权信息 / 版本信息 / 维护人信息 / 版本记录

---

1．背景
（1）典型用户
（2）用户的需求/迫切需要解决的问题
（3）假设
2．场景
关于这个场景的文字描述。
要列出这故事中出彩的地方，软件的哪些功能让用户特别满意？逻辑和界面设计要注意哪些因素？第一次使用的用户和多次使用的用户在体验上有何区别对待？
3．其他资料

---

10.2 用例（Use Case）

用例有这样一些基本元素：

标题：描述这个用例要达到的目标
角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（在描述一些和时间相关的场景时有用）
主要成功场景（Main Success Scenario）：一系列步骤描述角色是怎样和系统交互，从而达到目标的。
步骤（Step）：描述每一步的交互（例如一套正常的ATM取款流程）
扩展场景（Extension）：描述一些扩展的交互，例如一些意外情况（例如取款时账户余额不足）。

用例的原则：

1. 通过讲简单的故事来传递信息
2. 保持对全系统的理解
3. 关注用户的价值
4. 逐步构建整个系统，一次完成一个用例
5. 增量开发，逐步构建整个系统。
6. 适应团队不断变化的需求。

局限性：

1. 故事/人物/场景非常适合交互式的系统，但是对于其他类型的需求（算法，速度，扩展性，安全性，以及和系统技术相关的需求）则不适用。
2. 故事的粒度没有统一的标准，和每个具体项目有关。初学者比较难以掌控。
3. 如果软件的关键在于用户体验的细节，那么如何把这些UI的细节嵌入每个故事中，并仍然保持故事的简明性？这是一个难题。有些团队把目前的技术扩展为Use Case Storyboard，当一个简明的故事加上很多附加说明和图画的时候，这事实上就成为了我们下面要提到的功能说明书（Functional Specification），以及下一章要提到的各种帮助建模的图形工具。

---

10.3 规格说明书

10.3.1 软件功能说明书（Functional Spec）

一些概念：

功能说明书——描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等
谁来写Spec——项目的PM，或者是有一定经验的开发或测试人员
谁来实现Spec——开发人员、UX/UI设计人员
谁来验证Spec——测试人员、QA质量保障人员

怎么写好一份Spec：

第一，定义好相关的概念。
第二，规范好一些假设（Assumptions）。
第三，避免一些误解，界定一些边界条件。
第四，描述主流的用户/软件交互步骤。
第五，一些好的功能还会有副作用。
第六，服务质量的说明。

把Spec写的生动：

1. 用活生生的人物和故事描述用户是怎样用软件的。
2. KISS（Keep It Simple, Stupid）——保持简单、直接的描述。涉及UI的部分可以直接上图，也可以画表格，不要写长篇累牍的文字。
3. 如果是技术文档，最好把示例代码写上，单元测试也写好，让程序保证Spec的正确性，也让读者能够验证Spec的正确性。
4. 把边界条件规定清楚，理工科思维的工程师们看到这里大脑就兴奋起来了——他们想找出你Spec的破绽！

记录所有的改动：

1. 记录版本修订的时间和负责人——这样出了问题好去找人。
2. 在Spec中要说明如何验证关于功能的描述，从Spec的描述中就能知道单元测试该怎么写，最好把测试用例也链接上。
3. 把Spec和测试用例、项目任务等放在一起（例如放到TFS上），相互链接。
4. 变化是一定会发生的，与其在Spec中有意忽略这一点，不如主动挑明哪些部分是容易发生变化的，提前做好预案。说明哪些部分如果发生改变，会有何种连锁反应。
5. 在做任何改动的时候，一定要事先参考Spec

10.3.2 软件技术说明书（Technical Spec）设计文档（Design Doc）

设计文档应该说明工程师的设计是如何体现下列原则:

抽象（Abstraction）
内聚/耦合/模块化（Cohesion, Coupling,Modularization）
信息隐藏和封装（Information Hiding, Encap-sulation）
界面和实现的分离（Separation of Interface and Implementation）
如何处理错误情况（Error Handling）
程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过么？
应对变化的灵活性（Adapt to Change）
对大量数据的处理能力（Scalability）

---

10.4 功能驱动的设计（Feature Driven Design，FDD）

把用户的需求变成团队成员可以直接操作的开发工作，然后源源不断地实现这些需求:

第一步：构造总体模型（Develop an Overall Model）
第二步：构造功能列表（Build a Feature List）