怎样定义典型用户
受欢迎的典型用户——指那些按照设计者的期望使用系统的用户。
需要注意的是 我们的软件不是为所有人服务的。
我们要和典型用户的代表交流，理解用户，理解他们的工作方式和需要。然后再修改，细化用户。
从场景到任务
有了场景后，就由架构设计师和各个模块的负责人一起，沿着子系统/模块的所属关系把场景划分开。
不同的任务将会把一个场景编织起来，虽然有多个开发者参与这项任务，但是应该有一个开发者对整个场景负责。得到开发任务后就可以创建和分配测试任务。
用例
和典型人物、典型场景的方法类似，用例也是很常用的需求分析工具。
1.通过讲简单的故事来传递信息。2.保持对全系统的理解。3.关注用户的价值。4.逐步构建整个系统，一次完成一个用例。5.增量开发，逐步构建整个系统。6.适应团队不断变化的需求。
规格说明书：1.软件功能说明书。2.软件技术说明书，又叫设计文档。
功能说明书
谁来写Spec？通常是项目的PM，或者是有一定经验的开发或测试人员
谁来实现Spec？是开发人员、UX/UI设计人员
谁验证Spec是否全部实现了？是质量保障人员（QA）。
技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。
功能驱动的设计
第一步：构造总体模型。第二步：构造功能列表。第三步：制定开发计划。第三步：功能设计阶段。第五步：实现具体功能。
个人感受
过去各种思想、想问题的思维都太单一了，考虑问题不系统。
思考问题思路过去单一的话不利于问题或项目的有序的进行，很大可能会使项目出现偏差。
解决办法
必需改变思考问题的思路，使思维更逻辑化、系统化。