产品文档规范.docx

产品文档规范.docx

《产品文档规范.docx》由会员分享，可在线阅读，更多相关《产品文档规范.docx（26页珍藏版）》请在冰豆网上搜索。

XXX产品需求文档（模板说明）

说明：

本文档为产品需求文档的模板说明，编写产品需求文档时，需要按照模板说明的要求来进行。

 说明的部分，文档中用‘红色文字及示例’表述。

路径：

设置好文档管理的路径，文档管理更有条理，也便于文档使用人员轻易找到需要的文档。

1、文档需要按照如下方式设置保存路径：

 系统-模块-子模块-文档

    如：

财务平台-凭证管理-凭证审核-凭证审核产品需求文档

如果路径中没有对应的模块或子模块，需要先创建空间，然后再在对应路径下编写文档。

2、需求文档标题，按照系统功能模块名称填写

   如：

凭证审核产品需求文档

3、文档编写每次需要将本次修改的内容用黄色底纹标记，待上线后去掉黄色底纹。

开发及测试人员以黄色底纹标记的范围为准判断本次需要上线的内容。

建议文档都按照表格形式编写，这样格式容易固定。

·一、版本修订记录

·二、用户需求

·三、产品范围

·四、名词解释

·五、主流程图

·六、功能清单

·七、非功能需求

根据文档的核心标题，生成目录，便于链接浏览

一、版本修订记录

版本号

时间

修订模块

修订内容

修订人

版本修订记录：

记录每次修订文档的相关信息，留存变更历史记录。

1、按修订时间倒序填写，修订时间为修改的日期。

2、版本号从V1.0开始，每次增加0.1个版本，按十进制递增。

3、修订模板最好能填写本次修订涉及的最细的子模板，如无法判断，也要填写到模块层级。

如：

版本号

时间

修订模块

修订内容

修订人

V1.1

2018.2.1

凭证管理-凭证审核

凭证审核增加凭证调整功能，对于审核前有误的凭证可以人工调整

周

V1.0

2018.1.31

凭证管理-凭证审核

凭证管理新建凭证审核模块，对财务平台生成的凭证需要人工审核

周

二、用户需求

   1.需求描述

版本号

提出时间

确认时间

需求描述

提出人

用户需求：

简括列示需求用户提出的原始需求，需求是产品的来源。

1、需求描述建议与修订记录的版本号对应，每个版本修订的内容记录下原始需求描述，即用户的业务需求。

2、提出时间和确认时间可能需求很早就提了，但是一直没做，按需求列表上的记录。

如：

版本号

提出时间

确认时间

需求描述

提出人

V1.1

2018.2.1

2018.2.1

凭证审核时发现有的凭证生成的不正确，现在线下无法修改，只能事后线下调整，需要提供在凭证审核前发现问题可以直接在线调整凭证

俞

V1.0

2018.1.31

2018.1.31

现在都是人手工线下审核凭证，工作量大，效率低，还易出错，需要财务平台提供凭证审核功能，可以线上审核凭证

俞

    2. 原始记录

版本号

原始记录

原始记录：

需求从提出到实现，经历不同人不同时段，原始记录留底，便于核对需求与功能一致性。

1、可将对应需求提出时的附件、聊天记录、链接、图片、文字等原始记录上传在文档中。

2、按照修订版本对应上传。

如：

版本号

原始记录

V1.1

V1.0

三、产品范围

1.功能点

版本号

版本功能序号

功能

功能点：

用户提出了自己的用户需求，产品人员需要从产品的角度转化为产品（功能）需求。

1、按照版本号填写，将本版本对应用户需求，按系统功能列示，需要列示到细化的小功能点上。

如：

版本号

版本功能序号

功能

V1.1

1

凭证调整

V1.0

2

凭证审核单据跟踪

V1.0

1

凭证审核

   2.评审记录

版本号

版本评审次数

评审时间

评审人员

评审意见

评审记录：

记录每一版对应的评审情况，留底用。

1、按照版本号填写，将本版本对应的评审情况列示在表格上，需要列示评审的意见和产品的答复，如一个版本有多次

评审，每次评审都要记录。

 如：

版本号

版本评审次数

评审时间

评审人员及意见

V1.1

该版本第一次评审

2018.2.1

开发：

徐李认为文档满足开发需求。

测试：

张认为文档满足测试需求。

用户：

俞认为文档满足用户需求。

其他：

周无意见。

V1.0

该版本第二次评审

2018.1.31

开发：

徐李认为文档满足开发需求。

测试：

张认为文档满足测试需求。

用户：

俞认为文档满足用户需求。

其他：

周无意见。

V1.0

该版本第一次评审

2018.1.30

开发：

徐李认为流程图不够详细，需要补充，产品同意补充；认为审核查单单据详情多余，需要去掉，产品不同意去掉。

测试：

张无意见。

用户：

俞认为审核列表需要增加导出功能。

产品同意补充。

其他：

周无意见。

四、名词解释

名词

释义

举例

名词解释：

产品文档中经常会有一些业务或技术专业名词，非行业人员可能比较难以理解，需要对这些名词进行解释，便于更好熟悉业务，理解文档。

1、文档编写人员需要判断哪些名词需要列示，一般行业专有名词需要列示。

2、有时多个产品文档都会有某个名词，名词需要统一释义，建议都以最早编写的文档的名词释义为准，避免不同地方不同解释。

 如：

名词

释义

举例

原始凭证

原始凭证又称单据，是在经济业务发生或完成时取得或填制的，用以记录或证明经济业务的发生或完成情况的文字凭据。

它不仅能用来记录经济业务发生或完成情况，还可以明确经济责任，是进行会计核算工作的原始资料和重要依据，是会计资料中最具有法律效力的一种文件。

增值税发票、火车票等

会计科目

说白一点，会计科目就是将经济业务发生后，你要计入的账户的名字而已

管理费用-差旅费

五、主流程图

1、主流程图包括业务流程图和状态流程图。

编制图示时，补充简要的文字说明。

文档阅读人员通过图示能直观理解业务，进而更好的熟悉功能逻辑。

2、业务流程图需要记录业务关系、作业顺序、信息流向。

一般满足该3条特征的需要编制业务流程图，按照业务的实际处理步骤和过程讲清楚业务处理的来龙去脉，此处只要记录业务的主要流程，如果主流程下还有分支及明细流程，在后续明细功能中要单独补充子流程。

根据业务流程是否需要多角色分段可划分为 流程图、泳道图、分阶段的泳道图。

3、状态流程图主要是业务操作或事件等带来的状态变化，一般需要落到具体的单据上，而不同状态又表明了不同的业务含义。

状态图的作用是让人清楚业务的实现需要经历的状态序列，以及引起状态转移的事件，和因状态转移而伴随的动作。

通常，对于操作类的或需要状态判断的需要补充状态流程图。

如：

主流程图

1、凭证接口按规则对接收的单据生成凭证。

生成后传递到待审核凭证列表中；

2、财务人员登录系统，进入凭证审核列表，如果凭证有误可以凭证调整功能调整凭证，检查无误后，可以勾选单据进行审核；

3、审核完成后，凭证按系统定时任务传递给金蝶系统，传递成功则流程结束；传递失败可退回该凭证，重新调整及审核，审核后可重新传递，或者不退回该凭证，直接挂起，不再传递。

4、总账接口部分见总账接口产品需求文档描述。

状态流程图

状态变化见图示，其中总账接口部分见总账接口产品需求文档描述

六、功能清单

列示每个版本对应的详细功能点，每个功能对应的流程、原型及逻辑。

   1. XX功能

1、需要与上文中“三、产品范围”中的功能点相对应，此处需要按每个明细功能描述。

如：

 1. 凭证审核功能

      1.1凭证审核子流程图

1、上文中“五、主流程图”中已编制了相应的业务流程，此处对在主业务流程中，但需要进一步详细描述的，或者未在主流程中体现的功能编制子流程图，子流程图相对来说越细越好。

如果主流程已说明的比较详细或简单的业务，此处可不列示流程图。

 如：

     1.2凭证审核原型逻辑

原型页面

逻辑

1、原型交互逻辑

2、业务逻辑

1、对于涉及页面的功能，需要列示功能的原型及逻辑，原型需要分页面列示每个页面及其逻辑。

页面的绘制必须符合UI规范，绘制的控件必须全部是UI人员发出来的控件库，对于控件库中没有的，需要先让UI人员补充控件添加到标准控件库。

UI规范此处不再单独说明，详见UI规范文档。

通常：

原型中，需要参考的规范有：

    1）所有页面顶部为面包屑页面路径显示，提醒用户当前所在页面。

如凭证管理>凭证审核>凭证审核列表

   2）熟悉并运用Web平台的各种标准控件

   3）交互说明+动效（也可在表格右侧单独用文字描述）

   4）容易误操作的按钮尽量可以明确区分（如按钮不同颜色）

   5）易用性原则，程序可以实现的，尽量不要用户手工操作，如导出、导入等。

   6）命名：

页面命名尽量与功能靠拢并且一般是名词（如凭证列表）或者是动词+名词（凭证审核）；操作命名一般按动词（如，删除）；状态：

操作类的单据尽量状态保持一致（如新建、待审核、已审核、审核拒绝）

   7）页面尽量不要太长，滚动优于翻页。

但是向导性及分步骤的，一般翻页更优，每个页面是一个工作流程，上一步完成才进入下一步

   8）对于子页面，需要有明确的返回上页的按钮。

2、如果是业务逻辑等不涉及页面的，可以没有原型，但需要把业务逻辑描述清楚。

3、通常页面逻辑描述包括：

交互逻辑、业务逻辑

   1）交互说明+动效（如果没有在原型上描述的，需要在原型右侧表格补充），

   2）重点注意操作提示。

如预先信息提示、交互进行中需要提供操作相关的提示、结果信息提示

预先信息提示

表单提交类

如：

修改密码时，点击密码框准备输入，密码框旁边提示密码的要求（长度、组合等）

谨慎类操作

如：

扣除金币的操作需要预先提示扣除金币数目，以及当前金币是否足够。

差异化规则

如：

当一个功能的规则与用户习惯的规则具有一定的差异或比较复杂时，需要给出提示。

或者给出帮助链接

交互进行中操作提示

操作确认提示

如：

确认删除

操作错误提示

如评论字数为0或超过限制字数，搜索框未输入内容时提交

结果信息提示

查询类结果

任何信息列表、查询结果，当对应信息无结果的时候需要给出有无结果状态提示。

保存类结果

如设置个人资料。

提交保存后需要给出提示。

成功绿色、失败红色、普通灰色。

附加类结果

一个表单是对其他数据进行附加的，如评论等。

提交成功后应直接跳转到操作产生的结果展示部分。

   3）各种弹窗。

确认框、操作框、通知框、提示框等

   4）容错性原则，通常需要考虑到页面避免用户误操作，但无法控制的需要考虑正向、逆向过程，如新建的单据可以撤销

   5）通常对于列表，需要考虑排序、汇总、筛选

   6）所有页面字段，需要考虑默认值、是否可操作、必输、输入长度

   7）业务逻辑主要包括：

      功能逻辑：

详细讲解该功能的逻辑。

      交互逻辑：

对页面之间的相互跳转进行说明。

      视觉逻辑：

对颜色，对图标的要求。

      业务逻辑：

讲一下该功能对应着什么业务。

      技术逻辑：

有些逻辑可能用技术语言描述更清楚一点，以及对技术有特殊的要求。

   7）数据字典，建议分栏从上到下，从左到右的顺序描述，包括字段编码（可以研发定义）、字段名称（需要与页面字段一致）、类型、长度、是否必输、是否可输、取值来源、输入方式、含义、默认值、业务逻辑。

通常，新页面需要数据字典进行描述，如果是链接的其他