产品文档规范.docx

产品文档规范.docx

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

产品文档规范

产品文档规范

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

说明：

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

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

路径：

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

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

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

    如：

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

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

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

   如：

凭证审核产品需求文档

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

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

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

∙一、版本修订记录

∙二、用户需求

∙三、产品范围

∙四、名词解释

∙五、主流程图

∙六、功能清单

∙七、非功能需求

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

一、版本修订记录

版本号

时间

修订模块

修订内容

修订人

版本修订记录：

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

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

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

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

如：

版本号

时间

修订模块

修订内容

修订人

V1.1

2018.2.1

凭证管理-凭证审核

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

周

V1.0

2018.1.31

凭证管理-凭证审核

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

周

二、用户需求

   1.需求描述

版本号

提出时间

确认时间

需求描述

提出人

用户需求：

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

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

通常，新页面需要数据字典进行描述，如果是链接的其他功能的页面，需要说明是哪个页面，原型上需要显示链接的页面，可以不列示数据字典，比如，很多查询列表会有单据号，点击单据号可以查看原始单据，查看原始单据的页面是很多地方都用到的，原型上可补充该原始单据详情页面，逻辑说明中，需要说明该单据链接是查询哪个页面。

如：

     1.2凭证审核原型逻辑  

进入路径，菜单：

财务平台-凭证管理-凭证审核

1、头上按钮说明

1

重置

点击该按钮，清空凭证调整查询栏中的输入条件。

2

调整

必须且只能每次勾选一个单据，点击该按钮进入凭证调整功能页面。

如果没有勾选或者勾选多行单据，点击该按钮都弹出提示：

请选择一行单据进行凭证调整！

3

审核

至少勾选一行单据，点击该按钮，弹出提示框：

“系统将进行凭证审核，审核完成前请勿操作系统！

”点击确定，则系统将页面锁定，显示审核中小圆圈。

待审核完成，弹出提示框：

“审核完成！

”并解锁页面，同时将单据凭证状态更新为已审核。

2、凭证调整查询栏说明：

点击更多按钮，显示隐藏查询条件。

点击查询每页默认显示100条。

1

来源

值列表

系统代码定义中的凭证来源

默认显示全部

非必输

2

单据号

文本 

手工输入 

非必输

3

 类型

值列表

系统代码定义中的凭证类型

默认显示全部

非必输

4

科目

多选框

科目定义中的启用的科目

默认显示全部

非必输

点击更多按钮显示

5

部门

多选框

部门定义中启用的部门

默认显示全部

非必输

点击更多按钮显示

3、单据行说明：

从系统间接口已经接收的生成了预制凭证的单据信息

1

来源

30字符

不可输

从凭证接口接收的单据来源字段

2

单据号

30字符

不可输

从凭证接口接收的单据号字段

点击单据号，可进入02单据号详情页面

3

单据类型

30字符

不可输

从凭证接口接收的单据类型字段

4

单据金额

30字符

不可输

从凭证接口接收的单据金额字段

5

业务日期

30字符

不可输

从凭证接口接收的业务日期字段

6

币种

30字符

不可输

默认人民币

7

类型

30字符

不可输

从凭证接口接收的单据类型

8

凭证类型

30字符

不可输

从凭证接口接收的凭证类型

4、凭证明细行说明：

单据对应的凭证信息

1

行描述

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

2

期间

30字符

不可输

从凭证接口接收的单据生成的凭证行期间字段

3

科目

30字符

不可输

从凭证接口接收的单据生成的凭证行科目字段

4

科目名称

30字符

不可输

从凭证接口接收的单据生成的凭证行科目名称字段

5

部门

30字符

不可输

从凭证接口接收的单据生成的凭证行部门字段

6

部门名称

30字符

不可输

从凭证接口接收的单据生成的凭证行部门名称字段

7

渠道

30字符

不可输

从凭证接口接收的单据生成的凭证行渠道字段

8

渠道名称

30字符

不可输

从凭证接口接收的单据生成的凭证行渠道名称字段

9

方向

30字符

不可输

从凭证接口接收的单据生成的凭证行方向字段

10

金额

30字符

不可输

从凭证接口接收的单据生成的凭证行金额字段

进入路径，菜单：

财务平台-凭证管理-凭证审核功能点击单据行上的单据号

该页面只能查看，不能操作。

1、头上按钮说明

1

重返回

点击该按钮，返回到上一页面（凭证审核主页面）。

2、报销单头信息

1

单据号

30字符

不可输

从凭证接口接收的单据头单据号字段

2

单据类型

30字符

不可输

从凭证接口接收的单据头单据类型字段

3

报销日期

30字符

不可输

从凭证接口接收的单据报销日期字段

4

总金额

30字符

不可输

从凭证接口接收的单据头总金额字段

5

报销人

30字符

不可输

从凭证接口接收的单据头报销人字段

6

请付金额

30字符

不可输

从凭证接口接收的单据头请付金额字段

7

审核日期

30字符

不可输

从凭证接口接收的单据头审核日期字段

3、报销单行信息

1

行号

30字符

不可输

从凭证接口接收的单据对应的单据行的行号字段

2

行说明

30字符

不可输

从凭证接口接收的单据对应的单据行的行说明字段

3

报销类型

30字符

不可输

从凭证接口接收的单据对应的单据行的行报销类型字段

4

费用项目

30字符

不可输

从凭证接口接收的单据对应的单据行的行费用项目字段

5

渠道

30字符

不可输

从凭证接口接收的单据对应的单据行的行渠道名称字段

6

部门

30字符

不可输

从凭证接口接收的单据对应的单据行的行部门名称类型字段

7

金额

30字符

不可输

从凭证接口接收的单据对应的单据行的行金额字段

4、报销单核销借款行信息，如果该单据有核销

1

行号

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

2

借款单号

30字符

不可输

从凭证接口接收的单据生成的凭证行期间字段

3

借款金额

30字符

不可输

从凭证接口接收的单据生成的凭证行科目字段

4

借款人

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

5

已核销金额

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

6

剩余可核销金额

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

7

本次核销金额

30字符

不可输

从凭证接口接收的单据生成的凭证行描述字段

     1.3原型附件/地址

 原型地址/附件：

需要补充，便于其他人后续修订编辑。

   2.XXX功能

     2.1凭证审核子流程图

     2.2凭证审核原型逻辑

页面原型

逻辑

1、原型交互逻辑

2、业务逻辑

     2.3原型附件/地址

七、非功能需求

非功能性需求，指的是信息系统中保证性能、系统可靠性、可扩展性要求等方面相应的需求要素。

一般不会在用户的业务需求中进行明确的提出，需要分析人员（产品+技术）根据实际业务需要进行调研归纳。

一般包括性能要求、可靠性、可扩展性、易用性等。

虽然系统功能能满足用户需求，但还从产品角度在开发时考虑这些非功能需求。

1.性能

性能通常包括响应时间、用户数、处理量、存储量等等，需要落地具体的可衡量的标准上。

如：

   双11订单出库最少可以每秒出库1000单，最高可以达到2000单。

   2. 环境

环境通常指软件及硬件环境，需要实现负载均衡；日后若信息量较大，则系统可相应增加服务器实现扩展。

如：

   新系统上线需要提前准备服务器，搭建环境等等。

   3.合规

 产品对于行业法律法规道德等的约束。

如：

   医疗器械经营，相应的产品设计时，需要考虑到这一块。

  4.运营

通常商业产品设计时，需要运营人员推广，即需要对运营需求进行相应补充。

如：

   网站备案设计，推广文案编写等