你是否经历过这样的场景？刚入行的小白，想让自己变得更专业总是绞尽脑汁的想如何让我的PRD在团队人面前眼前一亮，如何让研发觉得产品除了写PPT还有点干货，如何让你的团队快速的清楚理解你所描述的业务场景......
产品需求文档PRD最常用到的图表系列文章会带你了解PRD中常用的图表、使用方法和使用技巧，在思考业务和撰写文档时更有逻辑性。
PRD的构成
作为产品经理，日常工作中不可避免的需要撰写PRD，PRD因为公司和部门的不同而存在差异。在工作中，常常存在一句话的需求，而这种一句话的需求只在说出那句话的那个时刻有意义，后面将给团队各个角色带来无尽的痛苦，包括产品经理自己。举个例子，一句话的需求【做一个按照文章标题查询下发量、分享量的前端查询页面】，那么接下来交互会来问，是否要推荐文章标题？研发会问除了文章是否需要时间维度？下发量和分享量的具体定义是什么？测试会问有正常流程是什么？有异常边界场景么？
面对此场景，产品经理改如何改善从而脱离无穷无尽的沟通？那就是PRD，通过撰写PRD，帮助自己思考业务也帮助团队更好的理解业务。下面将介绍简单的PRD构成元素。产品背景介绍：介绍当前行业情况，产品/功能概况和局限性
-概述和目标：产品/功能的整体概括描述，并明确目标，概述ROI
-阅读对象：PRD适用的阅读对象
-术语解释：PRD中出现的术语或这缩写的解释说明
-用户分析和使用场景:产品功能适用的用户说明和典型使用场景
-产品结构：概述产品结构，一般使用功能结构图、业务结构图和信息结构图
-功能性需求：描述功能需求，一般采用系统用户用例导图和详细用例说明
-非功能性需求：易用性、操作系统、扩展性、性能、数据统计等需求
UML
在介绍用户用例前，先简单看下UML（Unified Modeling Language），UML是一种建模语言。包含基本词汇（元模型）和语法（视图）。UML主要作用是：
-统一：统一既是使用一套标准用于描述软件的整个过程。打个比方，UML统一的意义类似于普通话的作用，大家虽然操着不同的方言，但是在软件过程中我们统一都是用普通话。
-表达与交流：UML是可视化的，用可视化更便于在团队内表达和交流。
-思考：UML通过从现实世界到业务模型的设计过程，不断的激发思考。
-迭代：UML用于记录迭代和演化。
UML中常用于需求分析的常用视图如下：
用例使用场景和基本构成
通过罗列应用场景（用户如何使用系统，系统能为用户提供什么），描述系统的功能性需求。
用户用例的基本组成如下：
用例图实例：
用例使用技巧和常见错误
1.用例用于描述功能性需求
需要从业务参与者和用例视角对业务进行建模，描述业务为达成某个目标而需要的功能用例说明。用例简单地的理解就是参与者的使用场景，可为参与者提供的功能和服务，而不是实现的方法和步骤。例如，如果从实现者视角容易犯的错误是容易将具体实现的过程抽象成用户用例，经常会出现接口、调度、算法等用例，而这些对于参与者来说都是黑盒。
2.用例参与者
用例中的参与者虽然使用一个人形表示，但是参与者是多元化的。可以是使用的人、系统、模块等等。例如，A系统需要使用B系统用例，那A系统可以是B系统的一个参与者。
3.用例是独立的、完备的需求或功能
独立的和完备的是描述用例的粒度，单个用例是独立的并且完备的。用例的粒度把控往往比较难，如果过大，单个用例就过于空洞，且无法很好的复用，描述用例时又过于复杂。用例过小，用例导图过于复杂，无法突出核心用例，且容易将用例画成实现步骤。所以在画用例时保证用例场景的独立和完备即可。
4.最大程度的可复用性
为了保障产品的快速迭代和稳定性，用例尽量保持最大程度的可复用性，避免重复和冗余。在进行产品需求迭代时，反复推敲用例，复用用例。
推荐绘图工具
绘图工具不拘一格，根据个人使用习惯选择，从整体的功能丰富度推荐：StarUML、visio；ProcessOn轻便，但是功能相对比较简单；Visual paradigm功能丰富，操作不是很简便
网友评论