简述需求文档的构成

1、简述需求档的构成需求的表达：能图讲的就别字。UML因其简单、统的特 点，且能表达软件设计中的动态和静态信息，前已成为可视化建模语的业标准。UML统建模语建了套采图解需求的标准法，它来解析和呈现业务需求，就能事半功倍接下来详细说下需求档中图说到的事。流程图呈现业务流程先简单讲讲画流程图的需要知道的基本元素组成流程图的元素流程图的基本元素.png开始/结束 Begin/End于描述个流程的开始和结束。活动Action是描述个业务流程中最基本的步骤，来描述对象的个动作，如次点击、次选择。判断Judge于描述业务流程中需要根据条件进判断的步骤，如系统根据数值系统会提供有不同信息。流程/其他流程Subf

2、low不便将流程的细节展出来，就可以先它来表。连接线Connection line于连接活动，并指明下步，更重要的是，在连接线上，还可以填写些额外的信息。“在超市购物完后结账时的流程”举个冈：基本步骤.png不出来了，接下来简单介绍可以到的泳道图。结合泳道区分流程中的在描述流程中活动的时候，可以使泳道来区分即“谁做的什么事情”。如图：泳道区分.png实体关系图产品经理在了解业务的流程后，为了便于后续的产品设计作，还需要关注业务中的数据关系，接下来简单讲下可以到的实体关系图。E-R图为实体-联系图，提供了表E-R图为实体-联系图，提供了表实体型、属性和联系的法，来描述现实世界的概念模型。实体关系

3、图表在信息系统中概念模型的数据存储。实体关系图，称做ER图，来描述实体间的数据关系。ER图.png以上ER图（只画了部分实体关系，像账单等实体省略掉了）表：个营业员可以为多个顾客执结账流程个顾客可以购买多种物品B端产品经理经常会设计配置后台等产品，户在配置后台进创建、删除、编辑、搜索等操作就是对数据的CRUD（增删改查）， 理清了这些数据属性，我们可以试着从数据度进需求的探索，即对需求进查漏补缺。举个冈-账单实体：创建：顾客结账，收营员扫描完该顾客的所有物品时，成份账单。修改：收营员在扫描错误物品时，会有编辑的需求。删除：对于收营员或顾客来说，好像没有删除的需求。查询：当超市的会计对某份账单有

4、疑问时，可能会有搜索的需求。数据流图范围，还能跟开发更好地沟通。完整的数据流图难度较，般不做要求，有兴趣的可以去了解数据流图。需求档的内容结构：需求名称背景标/收益功能需求功能需求需求名称概括性地描述这是件什么样的事情以及要实现的标，这可能是产品的名称也可能是项的名称。背景背景主要是说明为什么要做这个需求，通常是说明现状及现状带来的问题。标/收益讲清楚做了这个需求后预计达到的标或是收益，如能赚多少钱、能节省多少等等需求范围在这可以把需求以列表的式概括性展出来，可以让团队成员概知道这些需求包含哪些内容，便于后续评估作量。功能需求业务概念这需要放上实体关系图，以及每个实体的属性，有助于理清业务概念，也可以帮助开发拿到需求后设计数据结构。流程展这需要放上流程图和数据流图，于描述业务流程和数据扭转。需求描述这是档的核部分，在这个阶段描述需求时，建议不要描述界相关的内容，避免增加档的复杂性，以下是对个需求/例的描述。内容描述名称例的名称叫什么，如：结账谁在系统中使这个功能前置条件例的前提条件，或者系统正处于什么状态需求描述对需求内容的描述，可以是操作成功的正向流程，也可以是操作失败的逆向流程。后置条件操作这个例后，信息是否改变。备注可以填写些备忘或需要注明的信息功能需求除了功能性