![](https://img.haomeiwen.com/i1815913/5aa9539951cec48c.png)
10.1 典型用户和典型场景
-
1-定义典型用户
我们开发一个软件之前要先思考分析我们的用户在哪里,用户长什么样子,有什么需求。所以,我们要先仔细斟酌软件的典型用户有哪些。
可以给用户准备统一的模板:例如,包括年龄、收入、教育、偏好等等。当我们要做一个购物网站时,就会有很多角色:商户、买家、浏览者、广告、管理员等等。
典型用户——网管阿毛
-
2-从用户到场景
分析出典型用户之后,开始思考该用户使用软件的详细过程——场景/故事/Story。那么,场景怎么写?
商户上货场景
-
3-从场景到任务
例如,用户登录场景:
- UI层。子任务为:界面设计,货物资料处理,文件上传处理,编辑控件等。
- 逻辑层。子任务为:用户输入字段合法性处理,上传图像逻辑和缩略图处理,资料保存逻辑等。
- 数据库。子任务为:资料读取的存储过程,图像的索引建立和维护等。
- 4-场景/故事/Story的模板
场景 / 故事 / Story
版权信息 / 版本信息 / 维护人信息 / 版本记录
1.背景
(1)典型用户
(2)用户的需求/迫切需要解决的问题
(3)假设
2.场景
关于这个场景的文字描述。
要列出这故事中出彩的地方,软件的哪些功能让用户特别满意?逻辑和界面设计要注意哪些因素?第一次使用的用户和多次使用的用户在体验上有何区别对待?
3.其他资料
10.2 用例(Use Case)
用例有这样一些基本元素:
标题:描述这个用例要达到的目标
角色(Actor):和软件系统交互的角色,例如用户,其他实体,甚至时间(在描述一些和时间相关的场景时有用)
主要成功场景(Main Success Scenario):一系列步骤描述角色是怎样和系统交互,从而达到目标的。
步骤(Step):描述每一步的交互(例如一套正常的ATM取款流程)
扩展场景(Extension):描述一些扩展的交互,例如一些意外情况(例如取款时账户余额不足)。
用例的原则:
- 通过讲简单的故事来传递信息
- 保持对全系统的理解
- 关注用户的价值
- 逐步构建整个系统,一次完成一个用例
- 增量开发,逐步构建整个系统。
- 适应团队不断变化的需求。
局限性:
- 故事/人物/场景非常适合交互式的系统,但是对于其他类型的需求(算法,速度,扩展性,安全性,以及和系统技术相关的需求)则不适用。
- 故事的粒度没有统一的标准,和每个具体项目有关。初学者比较难以掌控。
- 如果软件的关键在于用户体验的细节,那么如何把这些UI的细节嵌入每个故事中,并仍然保持故事的简明性?这是一个难题。有些团队把目前的技术扩展为Use Case Storyboard,当一个简明的故事加上很多附加说明和图画的时候,这事实上就成为了我们下面要提到的功能说明书(Functional Specification),以及下一章要提到的各种帮助建模的图形工具。
10.3 规格说明书
10.3.1 软件功能说明书(Functional Spec)
一些概念:
功能说明书——描述软件产品的功能、输入、输出、界面、功能的边界问题、功能的效率(对用户而言)、国际化、本地化、异常情况等
谁来写Spec——项目的PM,或者是有一定经验的开发或测试人员
谁来实现Spec——开发人员、UX/UI设计人员
谁来验证Spec——测试人员、QA质量保障人员
怎么写好一份Spec:
第一,定义好相关的概念。
第二,规范好一些假设(Assumptions)。
第三,避免一些误解,界定一些边界条件。
第四,描述主流的用户/软件交互步骤。
第五,一些好的功能还会有副作用。
第六,服务质量的说明。
把Spec写的生动:
- 用活生生的人物和故事描述用户是怎样用软件的。
- KISS(Keep It Simple, Stupid)——保持简单、直接的描述。涉及UI的部分可以直接上图,也可以画表格,不要写长篇累牍的文字。
- 如果是技术文档,最好把示例代码写上,单元测试也写好,让程序保证Spec的正确性,也让读者能够验证Spec的正确性。
- 把边界条件规定清楚,理工科思维的工程师们看到这里大脑就兴奋起来了——他们想找出你Spec的破绽!
记录所有的改动:
- 记录版本修订的时间和负责人——这样出了问题好去找人。
- 在Spec中要说明如何验证关于功能的描述,从Spec的描述中就能知道单元测试该怎么写,最好把测试用例也链接上。
- 把Spec和测试用例、项目任务等放在一起(例如放到TFS上),相互链接。
- 变化是一定会发生的,与其在Spec中有意忽略这一点,不如主动挑明哪些部分是容易发生变化的,提前做好预案。说明哪些部分如果发生改变,会有何种连锁反应。
- 在做任何改动的时候,一定要事先参考Spec
10.3.2 软件技术说明书(Technical Spec)设计文档(Design Doc)
设计文档应该说明工程师的设计是如何体现下列原则:
抽象(Abstraction)
内聚/耦合/模块化(Cohesion, Coupling,Modularization)
信息隐藏和封装(Information Hiding, Encap-sulation)
界面和实现的分离(Separation of Interface and Implementation)
如何处理错误情况(Error Handling)
程序模块对于运行环境、相关模块、输入输出参数有什么假设?这些假设和相关的人员验证过么?
应对变化的灵活性(Adapt to Change)
对大量数据的处理能力(Scalability)
10.4 功能驱动的设计(Feature Driven Design,FDD)
把用户的需求变成团队成员可以直接操作的开发工作,然后源源不断地实现这些需求:
第一步:构造总体模型(Develop an Overall Model)
第二步:构造功能列表(Build a Feature List) <action><result><object>
第三步:制定开发计划(Plan by Feature)
第四步:功能设计阶段(Design by Feature)
第五步:实现具体功能(Build by Feature)
The End
游戏用户有哪些类型?
1)重度发烧 (hard core) 玩家,根据游戏安排日程
2)中度发烧玩家,根据日常生活计划安排游戏时间
3)休闲玩家,只在刚好有空的时候,才考虑以游戏作为消遣
你的游戏是针对哪一种类型的用户的?
网友评论