PRD：「FITLIFE」小程序产品需求文档（用户端）

程序源代码和说明文档，源码前后30页，文档前后30页。

1）软件源代码和说明书的页眉必须标明软件名称、版本号和页码，应当与申请表中相应内容完全一致。

2）申请表中项目名称的全称要和软件说明书及软件代码文档项目名全称保持一致，包括带V或不带V（特别注意以“软件”结尾的项目，在申请表中的全称要写全“软件”）否则将不合格。

3）软件说明书和代码文档在排版时应尽量避免大段的空白，不能有水印。

4）申请材料的封皮要按照要求的格式准备，要有目录。除封皮外都，右上角一定要有页码。

5）源程序和文档应提交前、后各连续30页，不足60页的，应当全部提交。源程序每页不少于50行，最后一页应是程序的结束页，文档每页不少于30行，有图除外。

6）申请文件A4纸，纵向、单面打印，文字左向右排列，文档和源程序需黑白打印。 鉴别材料

(1)源程序按前、后各连续30页, 共60页源程序每页不少于50行(结束页除外),右上角标注页号1-60；

(2)文档(如:用户手册、设计说明书、使用说明书等任选一种)按前、后各连续30页,共60页每页不少于30行(结束页除外),右上角标注页号1-60

4 申请软件著作权登记,可以选择以下方式之一对鉴别材料作例外交存：

(1) 源程序前、后各连续的30页，其中的机密部分用黑色宽斜线覆盖，但覆盖部分不得超过交存源程序的50％；

(2) 源程序连续的前10页,加上源程序的任何部分的连续的50页；

(3) 目标程序前、后各连续的30页,和源程序的任何部分连续的20页

文档作例外交存的，参照前款规定处理。

5 申请人可申请将源程序、文档或者样品进行封存除申请人或者司法机关外,任何人不得启封

[注] 已办理软件著作权登记的,其著作权发生继承、受让、承受时，当事人应当出具软件著作权登记证书（复印件）,无须提交鉴别材料

6 其他软件权属证明文件

(1)软件权属证明委托开发：——合作开发：合同书或协议书；软件委托开发协议或合同书；下达任务开发：下达任务开发软件任务书；利用他人软件开发的软件许可证明

(2)继承、受让、承受软件著作权的申请人，提交以下证明文件

①“继承”专指原著作权人（自然人）发生死亡，而由合法的继承人（自然人）依法继承软件著作权的情况。继承人申请软件著作权登记时，提交合法的继承证明（经公证的遗嘱或者法院的判决等）；

②“受让”指通过自然人之间、自然人与法人或者其他组织之间、法人之间、法人或者其他组织之间转让后，取得软件著作权的情况。受让人申请软件著作权登记的，提交依法签订的著作权转让合同或者相关证明

③“承受”指法人或其他组织发生变更（如：改制）、终止（如：合并）,而由其他法人或者其他组织享有软件著作权的情况当法人或者其他组织以权利承受人申请登记的，提交的著作权承受证明：

著作权承受证明——法人或者其他组织的工商变更证明；国有法人或者其他组织的上级主管机构的行政批复

7、版本说明

申请登记软件 V10 以上的高版本或以其他符号作为版本号进行原创软件登记时,应提交版本说明

需求文档的编写内容包括很多的，但是需要根据该软件的规模和具体要求进行编写。 一份比较完整的详细需求分析应该包括：1 前言 2 摘要 3 系统详细需求分析 31 详细需求分析 311 详细功能需求分析 312 详细性能需求分析 313 详细信息需求分析 314 详细资源需求分析 315 详细组织需求分析 316 详细系统运行环境及限制条件需求分析 317 信息要求 318 性能要求 32 接口需求分析 321 系统接口需求分析 322 现有软、硬件资源接口需求分析 4 总体方案设计41 系统总体结构 411 系统组成、逻辑结构 412 应用系统结构 413 支撑系统结构 414 系统集成 415 系统工作流程

2 分系统详细界面划分 421 应用分系统与支撑分系统的详细界面划分 422 应用分系统之间的界面划分 5 应用分系统详细设计 51 XX分系统详细需求分析 511 功能详细需求分析 512 性能详细需求分析 513 信息详细需求分析 514 限制条件详细分析 52 XX分系统结构设计及子系统划分 53 XX分系统功能详细设计 54 分系统界面设计 541 外部界面设计 542 内部界面设计 543 用户界面设计 6 数据库系统设计 61 设计要求 62 信息模型设计 63 数据库设计 631 数据访问频度和流量 632 数据库选型 633 异构数据库的连接与数据传递方式

635 数据共享方式设计 636 数据安全性及保密设计 637 数据字典设计

8 信息编码设计 81 代码结构设计 82 代码编制 9 关键技术 91 关键技术的提出 92 关键技术的一般说明 93 关键技术的实现方案 10 系统配置 101 硬件配置 102 软件配置 11 限制 12 组织机构及人员配置 121 机构调整与确认 122 组织机构的任务和职责 123 人员配置方案 124 培训计划 13 工程实施计划 131 分期实施内容 132 进度计划 133 实施条件 134 测试与验收 14 投资预算 15 参考和引用资料

16 术语

这里还有很需要补充的，也有很多是可以不写的；因为一份需求文档不是谁能写的，呵呵，在实际的工作中

是那些负责人才能写这个的。如果是课设的话，只要在流程图 逻辑结构 或者是XX分系统的设计图上下点功夫就好了。说到格式 就是按上面的写 然自己弄一个目录 就像是我们平时翻书的时候看到的那种，这样好阅读。

         墨刀连接：>

产品需求文档分很多种，这里我只说一种让程序员看起来舒服的需求文档格式吧：

作为程序员，在需求文档当中，最关注的内容是哪几种呢？

1、流程：包括业务流程和基本流程；

2、数据：包括输入数据和展示数据；

3、事件流：特别是分支事件流和例外事件流，感觉很多需求文档中，缺少了这部分；

那么，文档的模板是怎么样的呢？

1、需求说明：主要阐述为什么要做这个需求；

2、业务流程：最好使用VISIO来绘制，画出整个业务的流程图，特别是其中所要涉及的判定，分支等，都要画出来，越详细越好；

3、基本流程：继续使用VISIO，画出基本流程即可，一般来说都是业务流程中的最主要部分，但是可以加入更多的细节；

4、分支事件流：VISIO，各种分支事件的详细流程，越详细越好；

5、例外事件流：这里要使用表格，示例如下：主要是系统判定和对应的提示；6、输入数据：用户可以输入数据的字段，已经相应的定义，包括是否必填，字段长度，录入方式，对应规则等；

7、显示数据：页面显示给用户的数据，对应的字段，取数规则，对应规则等;

8、补充说明；这个需求文档模板，更倾向于传统的软件模板，而不是网络上比较流行的AXURE文档。

以上就是关于PRD：「FITLIFE」小程序产品需求文档（用户端）全部的内容，包括:PRD：「FITLIFE」小程序产品需求文档（用户端）、功能需求怎么写、软件功能需求书,是否要求字体格式一致等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！