《构建之法》读书笔记——第10章 典型用户和场景

第10章 典型用户和场景

10.1 典型用户和典型场景

光看用户的表面语言或行动还是不够的。我们还要找到用户语言或行动背后的动机!不能光根据用户的语言就匆忙做决定。

10.1.1 Visual Studio的典型用户

 

10.1.2 典型用户的价值

典型用户不再是一个抽象的概念,而应该是一个活生生的人。一个典型用户描述了一组用户的典型技巧、能力、需要、想法、工作习惯和工作环境。

 

在设计软件的过程中,我们往往会以自己使用产品的习惯对软件行业的熟悉程度出发设计,忘记了我们的软件是给千千万万个不那么会用电脑的人使用的。在这种情况下,搞一个“典型用户”会强迫我们在考虑问题时从用户的角度出发。

10.1.3 怎样定义典型用户

典型用户可以包括以下内容:

         1.名字(越自然越好)

         2.年龄(不同年龄和收入的用户有不同的需求)

         3.收入

         4.代表的用户在市场上的比例和重要性(比例大不等同于重要性高,如付费的用户比例较少,但是影响大,所以更重要)

         5.使用这个软件的典型场景

         6.使用本软件/服务的环境(在办公室/家里/沙发/床上/公共汽车/地铁……)

         7.生活/工作情况

         8.知识层次和能力(教育程度,对电脑、互联网的熟悉程度)

         9.用户的动机、目的和困难(困难=需要解决的问题)

         10.用户的偏好

 

注意:我们的软件不是为所有人服务的。

10.1.4 从典型用户到场景

有了典型用户之后,我们还得决定每一个典型用户的目标——他/她使用系统想要达到什么目的。对于每一个目标,列出达到目标所必须经历的过程,这就是场景,也可以叫故事。注意,有些场景描述了成功的结果,有些场景描述了失败的结果。用户和系统有成百上千中可能的交互情况,写场景时要有针对性。

 

场景之间如何区分呢,这就要求我们找到这个场景的特殊之处,对于共同的流程可以一笔带过,重点描述场景中特殊的因素。

把场景组织成一个故事,这样就能把一个完整的用户与文件系统交互的流程记录下来,以后进行产品演示或验收都可以以此为基础。

10.1.5 从场景到任务

不同的任务会把一个场景编织起来,虽然有多个开发者参与这项工作,但是应该有一个开发者对整个场景负责。得到开发任务后,我们就可以创建和分配测试任务。

10.1.6 典型用户的模板

略。

10.1.7 场景/故事/Story的模板

场景/故事/Story

版权信息/版本信息/维护人信息/版本记录

1. 背景

         1)典型用户

         2)用户的需求/迫切需要解决的问题

         3)假设

2. 场景

关于这个场景的文字描述。

要列出这故事中出彩的地方,软件的哪些功能让用户特别满意?逻辑和界面设计要注意哪些因素?第一次使用的用户和多次使用的用户在体验上有何区别对待?

3. 其他资料

10.2 用例(Use Case)

和典型人物、典型场景的方法类似,用例(Use Case)也是很常用的需求分析工具。

10.3 规格说明书

10.3.1 功能说明书

功能说明书从用户的角度描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率(对用户而言)、国际化、本地化、异常情况等,不涉及软件内部的实现细节。

10.3.2 功能说明书的模板

         1.Spec的目标是什么,Spec的目标不包括什么?

         2.Spec的用户和典型场景是什么?

         3.Spec用到了哪些术语,它们的定义是什么?

         4.用户是如何使用软件的功能的?

         5.各种边界条件是什么,软件功能应该怎样随之变化——这边界条件多了去了:用户数量的变化,输入内容的上限下限,不同国家/地区/文化/语言/硬件/软件版本/环境参数……

         6.功能有什么副作用,对于其他功能有什么显性或隐性的依赖关系?

         7.什么叫“好”,什么叫“这个功能测试完了,可以交付了”?

         8.软件发布出去之后,有哪些项目目标相关的数据可以收集,怎么在实现阶段就能把数据收集的工作准备好?

10.3.3 技术说明书

技术说明书又叫设计文档,它用于描述开发者如何去实现某一功能,或相互联系的一组功能。软件的功能多种多样,放之四海而皆准的模板是不太实用的,但是软件的设计总是要遵循一些规律,不遵循这些规律,工程师们往往在实现后面软件的演化中吃苦头。设计文档应该说明工程师的设计是如何体现下列原则的。

l  抽象(Abstraction)

l  内聚/耦合/模块化(Cohesion, Coupling, Modularization)

l  信息隐藏和封装(InformationHiding,Encapsulation)

l  界面和实现的分离(Separationof Interface and Implementation)

l  如何处理错误情况(ErrorHandling)

l  程序模块对于运行环境、相关模块、输入输出参数有什么假设?这些假设和相关的人员验证过吗?

l  应对变化的灵活性(Adaptto Change)

l  对大量数据的处理能力(Scalability)

10.4 功能驱动的设计

第一步:构造总体模型(Develop an Overall Model)

第二步:构造功能列表(Build a Feature List)

第三步:制定开发计划(Plan by Feature)

第四步:功能设计阶段(Design by Feature)

第五步:实现具体功能(Build by Feature)

10.5 练习与讨论

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值