万字长文！超全面的B端产品设计指南
|
除了用户访谈和问卷调查以外，有机会到业务工作中实际现场观摩也是一种很好的需求获取手段，有助于产品经理对业务场景建立更加感性的认识。在对关键任务理解不清晰、很多东西用文字没办法表述时，现场观摩都是一种很好的方式。 到了这一步，我们已经收集到足够多的业务信息，供我们进行后续的需求分析工作了。 1. 确定需求细节完善用例 本阶段的任务是对用例的细节进行填充。上一阶段的用户故事已经说明业务怎么执行，但缺少表达如何「实现」的机制。例如房产交易后对合同归档，有一部分合同可以由业务员直接归档，有一部分则需要经过部门经理审核后才能归档。另外归档需要什么前置条件，归档后会引发这项业务发生什么样的变化，这些都是本阶段需要考虑的问题。
因此在完善用例阶段，我们需要做的事情主要有：
以用例作为需求的最小单位，是按照业务流的角度将需求分类管理的方法。在这个阶段，首先我们要做的事情是将用户调研阶段获取到的用户原始需求，整理到相应的用例中，以此建立用户原始需求与软件需求(用例)之间的映射。 在具体操作时，我们可以用以下表格管理需求追踪。前三列描述了用户原始需求的编号、描述与提出者，接下来两列则是相应的用例编号及用例名称。这些用户的原始需求来源于用户调研、用户提供的需求说明以及在使用系统过程中获得的反馈。
有这样一张表，我们对用户的需求管理更显得张弛有度，同时也更容易发现需求冲突的地方。 表述事件流 对于用例而言，最常见的事件流包括 3 种：
在买房这个例子中，按预定路线双方完成交易就是基本事件流，双方对价钱的商议过程就是子事件流，而买卖双方的交易过程穿插着比较多的交易情况，属于拓展事件流。 补充前置条件与后置条件 所谓前置条件是指在用例启动时，参与者与系统应处于什么状态。这个状态是系统能够检测并且是有意义的。而后置条件是指在用例结束时，系统应处于什么状态。同样这个状态也是系统能检测到并且有意义的。通过以下例子加深理解：
一般来说，前置条件通常是一种状态，后置条件可能是一种状态，也可能是一种后续行为。并非所有的用例都存在前置条件与后置条件。 规则与设计约束 规则是在实现阶段应该考虑的东西，而约束是对技术手段起限制作用的各种条件。在这个阶段补充规则与设计约束是我们对用例整理的最后一件事情。 从需求的角度来看，用例涉及的规则大致可以分为：业务规则与数据规则两类。
而用例的约束则比较简单，通常指的是性能指标等非功能要求，或是软硬件、用户使用环境以及技术选择的限制。这些限制也并非每个用例都会有，但关键业务活动的设计约束要充分考虑，才不会发生因规划产生的设计缺陷。 2. 需求整理与分析需求分析是需求工程中最重要的活动之一。需求分析并不是在分析系统如何实现用户的需求，而是选择一种业务导向的指引将零散的需求串联起来，形成一个体系完整、内容清晰的框架，为下一阶段的产品设计工作做准备。 在这个阶段，我们要做两件事情：整理需求并消除需求间的矛盾。 整理需求 将用户需求转化成系统需求后，我们要根据业务流向，整理每一个环节，每一种类型的需求。如下图所示：
这种结构是以业务流程为整理的主线索，也就是按「事」的角度进行分解。这种方法对于工作流系统以及信息管理系统来说都是非常适用的方法。 首先将我们的产品划分成不同的业务板块，在这个层面看哪些系统需求是针对业务事件，确保业务流程正常进行的;哪些系统需求是针对报表的要求，确保流转过程中的数据传递。 接下来再往更细颗粒的维度整理，梳理哪些系统需求是支持业务步骤的，基于这些业务步骤需要设计什么样的功能点。这样一来所有的系统需求都按照清晰的脉络，层层递进展现在我们面前。 消除需求间的矛盾 （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
