《构建之法》笔记
第二章 个人技术和流程
第四章 两人合作
第六章 敏捷流程
第十章 典型用户和场景
前言
典型用户（Persona）和场景（Scenario），软件功能说明书（Functional Spec）和技术说明书（Design Doc），功能驱动是设计（FDD），用例（Use Case）
一、典型用户（Persona）和场景（Scenario）
一个典型用户往往描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。
对每一个典型用户决定其的目标（他使用系统想要达到什么目的）。对每一个目标，列出达到目标所必须经历的过程，即场景，也可以叫故事（story）。
从场景到任务。
二、用例
常用的需求分析工具。基本元素：
- 标题：描述用例要达到的目标
- 角色（Actor）：和软件系统交互的角色，例如用户，其他实体，甚至时间（描述一些和时间相关的场景）
- 主要成功场景：一系列步骤描述角色怎么和系统交互，从而达到目标。
- 扩展场景：描述一些扩展的交互，例如一些意外情况
三、规格说明书（Specification）
软件功能说明书（Function Spec）
主要用来说明软件的外部功能和用户交互情况（把软件当作一个黑盒子）。
从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率（对用户而言）、国际化、本地化、异常情况等，不涉及软件内部实现细节。
模板：
- 目标包括什么，不包括什么（规范好一些假设）；
- 用户和典型场景（主流用户）；
- 术语及定义（定义好一些概念）；
- 用户是如何使用软件功能的（软件交互步骤）；
- 各种边界条件；
- 功能有什么副作用，对其他功能有什么显性或隐性的依赖关系；
- 什么叫“好”，什么叫“这个功能测试完了，可以交付了”;
- 软件发布后，有哪些项目相关的数据可收集，如何在实现阶段就把数据收集的准备工作准备好；
软件技术说明书（Technical Spec）
又叫设计文档（Design Doc），主要用来说明软件内部的设计规范（把软件当作一个透明的箱子 用于描述开发者如何去实现某一功能，或相互联系的一组功能。
注：设计文档应该说明设计是如何体现一些设计原则的。
四、功能驱动的设计（Feature Driven Design）
如何把用户需求变成团队成员可以直接操作的开发工作，FDD是针对这个问题的众多方法论之一。
构成步骤：
- 构造总体模型（Develop an Overall Model）
- 构造功能列表（Build a Feature List）
- 制定开发计划（Plan by Feature）
考虑因素（各实体和功能之间依赖关系；复杂程度；高风险难度功能适当提前；…） - 功能设计阶段（Design by Feature）
分析一组相关实体及其功能，通过时序图（Sequence Diagram）和其他工具，展示各个实体和函数如何动态地结合起来实现一个功能。 - 实现具体功能（Build by Feature）
具体团队成员实现类/函数，进行相关单元测试，并在代码复审后，把代码集成到产品构建中
注：FDD对单元测试之外的测试（集成测试、压力测试、对用户界面和用户体验的测试）讲述不足。
总结