今天我学习了构建之法的第五章——典型用户与典型场景。我们都知道，软件开发最终都是服务于用户，所以用户主导着我们的开发方向。软件开发离不开用户，所以能够搞清楚用户隐藏的要求也是软件开发过程中的的一个重要的课题，这就涉及到了典型用户。
典型用户，顾名思义，能够代表大部分用户的用户。很多时候，不考虑典型用户的话，软件的开发不可能把所有的方面都做的尽善尽美，开发人员不可能把所有的方面都能考虑到。这时候，典型用户就站了出来。但同时，典型用户也有两面性——受欢迎的与不受欢迎的。那些能够按照开发者期望进行操作的用户成为受欢迎的典型用户，相反，那些有不正当目的的用户为不受欢迎的典型用户。典型用户可以包括以下方面来进行区分：
1：名字；
2：年龄；
3：收入；
4：代表的的用户和比例在市场上的重要性；
5：使用这个软件的典型场景；
6：使用本软件/服务的环境；
7：生活、工作情况；
8：知识层次和能力；
9：用户的动机、目的和困难；
10：用户的偏好。
在做典型用户心理分析的时候，需要对具有不统不同以上特质的人进行分析，与他们进行交流，理解用户，理解他们的工作生活方式和需要。有了典型用户之后，再根据他们的目标，思考要达到这些目标所要经历的过程，这就是场景。场景有成功，也会有失败的情况。成功的场景怎么写？首先针对每一个场景，设计一个场景入口（描述场景如何开始）。接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等）。然后给场景划分优先级，按优先级排序写场景。
在UML这门课中，我们学习了用例这一概念，用例包括标题、角色、主要成功场景、步骤、扩展场景这些元素。用例具有一些使用原则：
1：通过将建的的故事来传递信息；
2：保持对全系统的理解；
3：关注用户的价值；
4：逐步构建整个系统，一次完成一个用例；
5：增量开，逐步构建整个系统；
6：适应团队不断变化的需求。
但同时，用例使用也有它的局限性：不适合交互式之外的系统；故事的粒度没有固定的标准，和具体的项目有关，初学者难以掌握；如果关键在于用户体验的细节，不能把UI的细节嵌入故事中，并保持故事的简明性。
规格说明书包括软件功能说明书和软件技术说明书。功能说明书，主要用来说明软件的外部功能和用户的交互情况，从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率、国际化、本地化、异常情况等，不涉及软件内部的实现细节。技术说明书又叫设计文档，它用于描述开发者如何去实现某一功能，或相互联系的一组功能。
把用户的需求变成团队可以直接操作等工作，这是功能驱动设计。要进行构建总体模型、构建功能列表、制定开发计划、功能设计、实现具体功能五个步骤。
如果软件团队在软件测试方面没有足够的投入，最终的系统会存在许多问题。