在产品的整个研发流程中，需求分析结束后，就能明确产品需求了，而这时要做的是把这些产品需求表达出来，从表达效果来看，原型是最好呈现形式，开发通过原型了解需求如何呈现，测试了解验证的依据。

一份完善的产品原型需求文档能够体现了一名产品人员的责任心、专业性、严谨的工作态度。
本文针对中后台产品整理了一份原型需求文档模版，文档分为 5 部分，对每个版本需要注意的点做了延展说明。

原型需求文档框架

一、文档概述

1.需求说明

包含：文档名称、主要参与人员、编写目的、项目背景、名词定义，如下图：

需求说明

注意规则：
文档名称命名方式一般为： 产品名+版本号。
产品名根据项目定义，下面主要说明一下版本号的基本规则。
版本号命名方式：主版本号 . 次版本号 . 修订号 . 开发提测版本号
1）主版本号：产品方向改变，或者大规模API不兼容，或者架构不兼容升级。
2）次版本号：保持相对兼容性，增加主要功能特性，影响范围极小的API不兼容修改。
3）修订号：如果某个版本有打补丁包（如线上版本修复BUG、小需求补充，逻辑设计类错误，则新建版本号 1.1.2）。
4）开发提测版本号：1.1.0.1、1.1.0.2、1.1.0.x（x与内部提测次数一致）
5）产品正式对外发布后，以前三位做为对外发布的版本号。

2.需求列表

详细整理出每个需求任务，以及产品预计的迭代周期时间计划。

需求列表

3.修订历史

修订历史

二、产品总览

产品总览：产品整体功能的框架，包含:功能结构图、信息结构图、业务流程图，可以用 Xmind、百度脑图、ProcessOn、Draw 等软件制作。
如下：

功能结构图

信息结构图

业务流程图

三、全局说明

1.交互说明

中后台中一般整理说明，功能各组件中共性的交互方式、交互机制，总结说明，这边不做详细说明。
例如：

• 操作后如何提示，提示的位置？是否以 Message 出现在页面中上方还是右上方，出现的时长是否有统一要求或特殊要求。
• 表单的校验交互，是光标在输中就进行校验，还是光标离开输入框后再进行校验。

2.权限说明

有账号密码的系统，都会涉及权限管控，一般根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源。

权限管理，通常采用 RBAC （Role-Based Access Control）模式。
权限系统由三大部分构成：用户管理、角色管理、权限管理
用户：谁？当前访问管理系统的是什么人？如:小明
角色：是什么身份？如：CEO、总监、经理、员工。
权限：可以看到哪些内容，执行哪些操作？数据权限：允许看到哪些功能菜单、信息字段等；功能权限：增删改查操作。

RBAC权限管理模式

原型文档权限说明示例

四、功能模块原型

原型作为与开发沟通最好的载体，产品的原型设计实现一般区分整体和局部，整体上更多考虑信息架构的设计，如功能结构、导航、菜单、布局排版等方面。局部上更多考虑是功能的交互设计，如按钮点击、操作反馈、页面切换、模块信息的展示。确定好以上内容后，原型基本设计完成，之后，需要将功能设计思路、逻辑规则标记在原型中。

1.功能模块设计：按照页面结构和信息结构绘制原型，确定每个页面的布局和元素的位置，交互方式等。

2.需求标注：确定好整体页面功能后，可以把功能细节、规则用文字的形式标注在原型周围。
可以使用原型标注表格，将每个页面功能点打记号，如123，在标注整理到表格中，重点说明出异常边界和文案提示，区分全局说明和局部说明，尽可能将标注写的精简、明确、全面，整理一份 Check List 多审视几遍，避免与开发沟通时遗漏，影响沟通效率 ，自查清单可查看文章 中后台产品功能自查清单。

功能模块原型示例

五、非功能性需求

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

1.性能需求

响应时间平均响应时间参考值(秒)、峰值响应时间参考值（秒）
例如：

• 登录时间 ≤5 秒
• 页面间跳转时间 ≤3 秒
• 精确查询（包括请求服务）响应时间 ≤1 秒
• 模糊查询响应时间 ≤5 秒
  在 95％ 的情况下，一般时段响应时间不超过 1.5 秒，高峰时段不超过 4 秒。

吞吐量 并发量单位时间内成功地传送数据的数量。这一块与系统并发相关，根据业务量估计，我们的系统需要支持多少并发。
例如：估计用户数为 1 万人，每天登录用户数为 3000 左右，网络的带宽为 100M 带宽，系统可以同时满足 10,000 个用户请求，并为 25,000 个并发用户提供浏览功能。

资源利用率 指企业投入服务器这类资源，所发挥的资源利用百分比。
例如：CPU 占用率 <=50%；内存占用率 <=50%。

准确性、有效性
与能否得到正确或者相符的结果或者效果有关的软件属性。

性能需求

2.系统需求

运行环境约束：用户对软件系统运行环境，兼容性、应用服务器软件及其版本要求。
例如：系统应支持 iOS，Android , Windows 操作系统;
系统应支持 Oracle, DB2 数据库系统。

3.运营需求

运营侧对功能进行数据统计，对相关功能数据埋点等。

运营需求

4.安全需求

一般分为程序安全、系统安全、数据安全。

程序安全是指开发的程序是否是安全的，程序上有没有安全的漏洞，例如：Web 开发中服务器代码没有对输入的参数进行验证，从而导致客户端机器人轻易的获取数据。

系统安全指的是系统整体的安全，能经受来自互联网的一般性恶意攻击。如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等。例如：安全的粒度，未经授权的用户是否可以轻易的访问非法的数据等。

数据安全是对数据的保护，保护数据不被非法/越权访问和篡改，要确保数据的机密性和完整性，严格权限访问控制，用户在经过身份认证后，只能访问其权限范围内的数据，只能进行其权限范围内的操作。业务数据需要在存储时进行加密，确保不可破解。