- 1、本文档共5页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
B 端产品设计指南
3.确定需求细节
完善用例
本阶段的任务是对用例的细节进行填充。上一阶段的用户故事已经说明业务
怎么执行,但缺少表达如何“实现”的机制。例如房产交易后对合同归档,有一部
分合同可以由业务员直接归档,有一部分则需要经过部门经理审核后才能归档。
另外归档需要什么前置条件,归档后会引发这项业务发生什么样的变化,这些都
是本阶段需要考虑的问题。
因此在完善用例阶段,我们需要做的事情主要有:
(1)将用例与需求相对应;
(2)表述用例的事件流;
(3)补充用例的前置条件与后置条件;
(4 )确定用例的规则与约束条件;
用例与需求相对应
以用例作为需求的最小单位,是按照业务流的角度将需求分类管理的方法。
在这个阶段,首先我们要做的事情是将用户调研阶段获取到的用户原始需求整理
到相应的用例中,以此建立用户原始需求与软件需求 之间的映射。
(用例)
在具体操作时,我们可以用以下表格管理需求追踪。前三列描述了用户原始
需求的编号、描述与提出者,接下来两列则是相应的用例编号及用例名称。这些
用户的原始需求来源于用户调研、用户提供的需求说明以及在使用系统过程中获
得的反馈。
有这样一张表,我们对用户的需求管理更显得张弛有度,同时也更容易发现
需求冲突的地方。
表述事件流
对于用例而言,最常见的事件流包括 3 种:
基本事件流 :是对用例的预期路径的描述。是大部分时间遇到的场景,也是符合
用户预期与业务初衷的核心路径;
拓展事件流 :也称为分支事件流,主要用来描述用户的不同选择 以及对异常情况
的表示 ;
子事件流:用于对事件流中多次重复 的部分进行概括,类似代码 中的“循环结构 ” ;
在买房这个例子 中,按预定路线双方完成交易就是基本事件流,双方对价钱 的商
议过程就是子事件流,而买卖双方的交易过程穿插着比较多 的交易情况 ,属于拓
展事件流。
补充前置条件与后置条件
所谓 前置条件是指在用例启动 时,参与者与系统应处于什么状态 。这个状态
是系统能够检测并且 是有意义 的。而后置条件是指在用例结束时,系统应处于什
么状态 。同样这个状态 也是系统能检测 到并且有意义 的。通过以下例子加深理解 :
客户有购 房意向 :这不是一个前置条件,因为这是系统无法检测 的;
客户登录系统查看房源 图片 :这也不是一个好 的前置条件,虽然系统可以检测 ,
但是这个事情所表现出来的意义不大,对我们来说没有帮助 ;
审核通过,完成合同 :这是一个好 的后置条件,系统可以检测并且事件对流程有
影响 ;
一般来说,前置条件通 常是一种状态 ,后置条件可能是一种状态 ,也可能是
一种后续行为。并非所有的用例都存在前置条件与后置条件。
规则与设计约束
规则是在实现阶段应该考虑的东西 ,而约束是对技术手段起限制作用的各种
条件。在这个阶段补充规则与设计约束是我们对用例整理的最后一件事情。
从 需求的角度来看 ,用例涉及的规则大致可以分为:业务规则与数据规则两
类。
业务规则 :它 是指和业务逻辑 、业务流程相关 的规则。例如业务系统中,一个业
务员接触 了买方之后系统不会把这个客户再分给别 的业务员;业务员释放 了某个
客户之后,其他业务员可以联 系这个客户等等 ;
数据规则 :它 是和业务属性相关 的规则。例如业务员给客户发送 的营销短信最大
长度是 200 个汉字 ;业务员的当月有效业绩是当月 已付款 的所有订单的总金额
合计等等 ;
而用例的约束则 比较简单,通 常指 的是性 能指标等非功 能要求,或是软硬件、
用户使用环境 以及技术选择 的限制。这些限制也并非每个用例都会有,但关键业
务活动 的设计约束比较要充分考虑才不会发生因规划产生的设计缺陷 。
需求整理与分析
需求分析是需求工程中最重要的活动之一。需求分析并不是在分析系统如何
实现用户的需求,而是选择一种业务导向 的指 引将零散 的需求串联起来,形成一
个体系完整、 内容清晰 的框架 ,为下一阶段的产品设计工作做准备 。
在这个阶段,我们要做两件事情:整理需求并消除 需求间的矛盾 。
( )整理需求
1
文档评论(0)