B端产品设计指南03确定需求细节.pdfVIP

B 端产品设计指南 3.确定需求细节 完善用例 本阶段的任务是对用例的细节进行填充。上一阶段的用户故事已经说明业务 怎么执行，但缺少表达如何“实现”的机制。例如房产交易后对合同归档，有一部 分合同可以由业务员直接归档，有一部分则需要经过部门经理审核后才能归档。 另外归档需要什么前置条件，归档后会引发这项业务发生什么样的变化，这些都 是本阶段需要考虑的问题。 因此在完善用例阶段，我们需要做的事情主要有： （1）将用例与需求相对应； （2）表述用例的事件流； （3）补充用例的前置条件与后置条件； （4 ）确定用例的规则与约束条件； 用例与需求相对应 以用例作为需求的最小单位，是按照业务流的角度将需求分类管理的方法。 在这个阶段，首先我们要做的事情是将用户调研阶段获取到的用户原始需求整理 到相应的用例中，以此建立用户原始需求与软件需求 之间的映射。 （用例） 在具体操作时，我们可以用以下表格管理需求追踪。前三列描述了用户原始 需求的编号、描述与提出者，接下来两列则是相应的用例编号及用例名称。这些 用户的原始需求来源于用户调研、用户提供的需求说明以及在使用系统过程中获 得的反馈。 有这样一张表，我们对用户的需求管理更显得张弛有度，同时也更容易发现 需求冲突的地方。 表述事件流 对于用例而言，最常见的事件流包括 3 种： 基本事件流 ：是对用例的预期路径的描述。是大部分时间遇到的场景，也是符合 用户预期与业务初衷的核心路径； 拓展事件流 ：也称为分支事件流，主要用来描述用户的不同选择 以及对异常情况 的表示 ； 子事件流：用于对事件流中多次重复 的部分进行概括，类似代码 中的“循环结构 ” ； 在买房这个例子 中，按预定路线双方完成交易就是基本事件流，双方对价钱 的商 议过程就是子事件流，而买卖双方的交易过程穿插着比较多 的交易情况 ，属于拓 展事件流。 补充前置条件与后置条件 所谓 前置条件是指在用例启动 时，参与者与系统应处于什么状态 。这个状态 是系统能够检测并且 是有意义 的。而后置条件是指在用例结束时，系统应处于什 么状态 。同样这个状态 也是系统能检测 到并且有意义 的。通过以下例子加深理解 ： 客户有购 房意向 ：这不是一个前置条件，因为这是系统无法检测 的； 客户登录系统查看房源 图片 ：这也不是一个好 的前置条件，虽然系统可以检测 ， 但是这个事情所表现出来的意义不大，对我们来说没有帮助 ； 审核通过，完成合同 ：这是一个好 的后置条件，系统可以检测并且事件对流程有 影响 ； 一般来说，前置条件通 常是一种状态 ，后置条件可能是一种状态 ，也可能是 一种后续行为。并非所有的用例都存在前置条件与后置条件。 规则与设计约束 规则是在实现阶段应该考虑的东西 ，而约束是对技术手段起限制作用的各种 条件。在这个阶段补充规则与设计约束是我们对用例整理的最后一件事情。 从 需求的角度来看 ，用例涉及的规则大致可以分为：业务规则与数据规则两 类。 业务规则 ：它 是指和业务逻辑 、业务流程相关 的规则。例如业务系统中，一个业 务员接触 了买方之后系统不会把这个客户再分给别 的业务员；业务员释放 了某个 客户之后，其他业务员可以联 系这个客户等等 ； 数据规则 ：它 是和业务属性相关 的规则。例如业务员给客户发送 的营销短信最大 长度是 200 个汉字 ；业务员的当月有效业绩是当月 已付款 的所有订单的总金额 合计等等 ； 而用例的约束则 比较简单，通 常指 的是性 能指标等非功 能要求，或是软硬件、 用户使用环境 以及技术选择 的限制。这些限制也并非每个用例都会有，但关键业 务活动 的设计约束比较要充分考虑才不会发生因规划产生的设计缺陷 。 需求整理与分析 需求分析是需求工程中最重要的活动之一。需求分析并不是在分析系统如何 实现用户的需求，而是选择一种业务导向 的指 引将零散 的需求串联起来，形成一 个体系完整、 内容清晰 的框架 ，为下一阶段的产品设计工作做准备 。 在这个阶段，我们要做两件事情：整理需求并消除 需求间的矛盾 。 （ ）整理需求 1