典型用户和典型场景
光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机！不能光根据用户的语言就匆忙做决定。
Visual Studio的典型用户
典型用户的价值
典型用户不再是一个抽象的概念，而应该是一个活生生的人。一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
在设计软件的过程中，我们往往会以自己使用产品的习惯对软件行业的熟悉程度出发设计，忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下，搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。
怎样定义典型用户
典型用户可以包括以下内容：
1.名字（越自然越好）
2.年龄（不同年龄和收入的用户有不同的需求）
3.收入
4.代表的用户在市场上的比例和重要性（比例大不等同于重要性高，如付费的用户比例较少，但是影响大，所以更重要）
5.使用这个软件的典型场景
6.使用本软件/服务的环境（在办公室/家里/沙发/床上/公共汽车/地铁……）
7.生活/工作情况
8.知识层次和能力（教育程度，对电脑、互联网的熟悉程度）
9.用户的动机、目的和困难（困难=需要解决的问题）
10.用户的偏好
注意：我们的软件不是为所有人服务的。
从典型用户到场景
有了典型用户之后，我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。注意，有些场景描述了成功的结果，有些场景描述了失败的结果。用户和系统有成百上千中可能的交互情况，写场景时要有针对性。
场景之间如何区分呢，这就要求我们找到这个场景的特殊之处，对于共同的流程可以一笔带过，重点描述场景中特殊的因素。
把场景组织成一个故事，这样就能把一个完整的用户与文件系统交互的流程记录下来，以后进行产品演示或验收都可以以此为基础。
从场景到任务
不同的任务会把一个场景编织起来，虽然有多个开发者参与这项工作，但是应该有一个开发者对整个场景负责。得到开发任务后，我们就可以创建和分配测试任务。
典型用户的模板
场景/故事/Story的模板
场景/故事/Story
版权信息/版本信息/维护人信息/版本记录
1. 背景
1）典型用户
2）用户的需求/迫切需要解决的问题
3）假设
2. 场景
关于这个场景的文字描述。
要列出这故事中出彩的地方，软件的哪些功能让用户特别满意？逻辑和界面设计要注意哪些因素？第一次使用的用户和多次使用的用户在体验上有何区别对待？
3. 其他资料
用例（Use Case）
和典型人物、典型场景的方法类似，用例（Use Case）也是很常用的需求分析工具。
规格说明书
功能说明书
功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部的实现细节。
功能说明书的模板
1.Spec的目标是什么，Spec的目标不包括什么？
2.Spec的用户和典型场景是什么？
3.Spec用到了哪些术语，它们的定义是什么？
4.用户是如何使用软件的功能的？
5.各种边界条件是什么，软件功能应该怎样随之变化——这边界条件多了去了：用户数量的变化，输入内容的上限下限，不同国家/地区/文化/语言/硬件/软件版本/环境参数……
6.功能有什么副作用，对于其他功能有什么显性或隐性的依赖关系？
7.什么叫“好”，什么叫“这个功能测试完了，可以交付了”？
8.软件发布出去之后，有哪些项目目标相关的数据可以收集，怎么在实现阶段就能把数据收集的工作准备好？
技术说明书
技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。软件的功能多种多样，放之四海而皆准的模板是不太实用的，但是软件的设计总是要遵循一些规律，不遵循这些规律，工程师们往往在实现后面软件的演化中吃苦头。设计文档应该说明工程师的设计是如何体现下列原则的。
l 抽象（Abstraction）
l 内聚/耦合/模块化（Cohesion， Coupling， Modularization）
l 信息隐藏和封装（InformationHiding，Encapsulation）
l 界面和实现的分离（Separationof Interface and Implementation）
l 如何处理错误情况（ErrorHandling）
l 程序模块对于运行环境、相关模块、输入输出参数有什么假设？这些假设和相关的人员验证过吗？
l 应对变化的灵活性（Adaptto Change）
l 对大量数据的处理能力（Scalability）
功能驱动的设计
第一步：构造总体模型（Develop an Overall Model）
第二步：构造功能列表（Build a Feature List）
第三步：制定开发计划（Plan by Feature）
第四步：功能设计阶段（Design by Feature）
第五步：实现具体功能（Build by Feature）