典型用户场景
从典型用户到场景
在分析需求时，我们要重点考虑一些用户，而不是所有用户，否则就会浪费大量的时间。为此可以专门对一些典型用户进行分析，分析他们的身份、关注点、软件使用目的和方式、需求等。典型用户不是一个概念，应该是一个个活生生的人物。
典型的用户模板可以包括以下内容：
有了典型用户后，我们要和典型用户的代表交流，理解他们的工作方式和需要。然后对于每个典型用户，我们要分析他使用系统想要达到什么目标，对于每一个目标，列出达到目标所必须经历的过程，这就是场景。
编写场景时，针对每一个场景，我们要设计一个场景入口，接着描述典型用户在这个场景中所处的内部和外部环境，然后给场景划分优先级，按优先级排序写场景。
有了场景，下面就由架构设计师和各个模块的负责人一起，沿着模块的所属关系把场景划分开。例如登录场景，就可以分为UI层、逻辑层、数据库等。不同的任务会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。
场景的模板：
用例Use Case
和典型人物、典型场景类似，用例也是很常见的需求分析工具，用例有这样一些基本元素：
1、标题：描述用例要达到的目标
2、角色
3、主要成功场景
4、扩展场景：如一些意外情况和失败情况
用例强调用讲故事的方法来让团队人员对功能有统一的了解，突出具体的行动，而且是可验证的。可以通过完成用例来逐步构建系统。
User Case方法论也有其局限性，如不适合非交互式系统、故事的粒度没有统一标准、同时体现UI细节和保持故事简明性相互矛盾等。
规格说明书
全称Specification，简称Spec，分为以下两种：
1、软件功能说明书（Function Spec），主要用来说明软件的外部功能和用户的交互情况
2、软件技术说明书（Technical Spec），又叫设计文档，主要用来说明软件内部的设计规范
功能说明书
它主要从用户的角度来描述软件，一般由PM或有经验的开发或测试人员编写，由质量保障成员（QA）来验证它的实现。
它的内容主要包括：
1、定义好相关的概念
2、规范好一些假设，如一个步骤必须前一个步骤成功
3、避免一些误解，界定一些边界条件
4、描述用户的使用过程
5、把副作用写好
6、服务质量的附加说明
软件公司的大部分人都不喜欢读文档，因此文档要写的生动一些，尽量用活生生的人物和故事，要多用图和表格，不要写长篇的文字。
Spec中要记录版本修订的时间和负责人，还要说明如何验证功能的描述，可以相互链接测试文档、项目任务。有任何改动应该事先参考Spec，事后修改Spec。
模板：
技术说明书
又叫设计文档，设计时要满足一些设计原则，设计文档应该说明工程师的设计是如何体现下列原则的：
功能驱动的设计
如何才能把需求变成团队人员可以直接操作的开发工作？功能驱动的设计（Feature Driven Design，FDD）是针对这个问题的众多方法论之一，这个方法适用于团队成员对于需求没有切身体会的情景。