典型用户和典型场景
光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机!不能光根据用户的语言就匆忙做决定。
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)