系统需求说明书模版(互联网产品)

系统需求说明书

[使用说明：

本文档适用于系统需求定义。本文档主要用于说明系统要做什么，做成什么样子。侧重于系统功能、系统处理逻辑、人机交互和数据的定义。

模板中以蓝色斜体显示的文本，用于向作者提供指导，在文档编辑完成后应该将其删除。文档正文应使用常规、黑色、五号字体，即系统设置的“正文”样式。

当某一章/节没有内容时，必须注明N/A，同时标注理由。例如：本章/节内容无需考虑。特别说明：当某章/节内容参见其它文档时，不能注明N/A，而应该写明参见某文档的路径名称或章节等。]

文件状态：

[  ] 草稿

[√] 正式发布

[  ]

正在修改	文件编号：	SN_RT05
	当前版本：	V1.5
	作    者：	李伟佳
	完成日期：	2014-2-20

版本信息

版本	时间	状态	简要描述	部门	更改人	批准人
V0.9	2013-3-12	N	创建	产品设计理部	刘桂军
V1.0	2013-3-18	N	根据产品规划部建议，增加4.2章节。	产品设计理部	刘桂军
V1.5	2014-2-20	M	文档格式修改	质量控制部	李伟佳

注：状态可以为N-新建、A-增加、M-更改、D-删除。

1.关于本文档

1.1.内容说明

本文档用于描述XXXX产品的系统需求定义。包括各个需求的功能描述，处理逻辑规则，界面定义，与其它功能的关系，与其它系统的接口等各个方面的定义。是该系统唯一的全面需求定义文档。

根据需求管理流程和要求，产品经理随系统功能变化进行及时的修订和更新，以确保本文档的全面性，准确性和实效性。因此在阅读使用此文档时，请注意从项目的文档管理系统中获取最新版本。

1.2.适用范围

一、本文档由产品设计团队和用户体验团队共同完成，由产品经理负责。

二、本文档在产品设计团队编写完成后，由产品经理组织评审，评审过程遵守《SN_QP01产品研发评审规范.docx》。评审团队包括：业务代表（运营方）、产品经理上级领导、产品规划部门、用户体验设计团队、产品架构师、技术经理及核心开发人员、测试经理、产品设计管理部。

三、本文档在需求评审后，作为需求基线，由用户体验设计团队进行交互和视觉设计（内部项目可选），研发团队进行概要设计，测试团队准备测试方案。

四、用户体验设计评审后修订本文档一次，增加一个小版本号。

五、项目周期内，在需求评审结束后，所有需求变更，请在JIRA上走需求变更流程。

六、未经过需求评审或需求变更的需求，交互设计团队和研发团队不能进入正式设计研发阶段。

七、关于需求管理、需求变更、本文档使用如果有问题，请咨询产品设计管理部。

1.3.术语

词汇名称	词汇含义	备注

【定义及说明与此系统有关的特殊名词（专门术语）或简写、各类编号、代码等等】

1.4.参考文档

为了更好理解本文档，请阅读如下文档。

编号	文档	说明及地址
1	《XXXX产品定义说明书v1.pptx》	说明：是该产品的立项文档，定义了该产品的需求、产品设计和运营思路等基本内容。 获取地址：
2	《XXXX业务需求说明书v1.0.doc》	说明：描述了业务功能描述、业务流程、业务实体和业务规则等。 获取地址：

1.5.沟通要求

本表记录需要跨部门沟通的事项，以保证该文档内容质量。如果有其它跨部门沟通项，请填写该表中，并记录沟通结果。

序号	角色	沟通内容	沟通结果
1	用户体验	用户需求、用户群体特征等。	是
2	产品运营团队	沟通需求具体内容； 4.2.2节，产品运营规范	是
3	安全优化	系统安全性	不需要
4	客服	讨论客服如何支持：客服需求 协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不当使用风险 预测客服成本、工作量	否，待安排
5	技术总监 EA团队	讨论以确定方案的规模评估、推出计划 进行技术可行性分析，提出关键问题的技术解决方案 评估系统规模，数据量，所需资源等 协助评估风险

2.产品概述

本章节详细描述产品的背景、内容和目标等进行详细定义，关于产品定义的其它内容请阅读本产品定义说明书。

2.1.产品概述

对项目启动的背景和要做的内容进行简要的描述，包括产品的背景，产品的要做的内容等。

例：（购物车2改版项目）

购物车2改版的背景：现有购物车2存在着用户点击进入之后，对要填写的信息不明确，不清楚后续的操作步骤，中间的相关交互较为复杂，关键的信息点不明确，点击保存按钮不突出，显示出来的干扰信息较多等问题，基于这个，我们提出这次购物车优化项目。

2.2.产品范围

通过环境图的方式描述本系统与其它业务系统之间的交互关系。

系统范围图

使用环境图方法：本系统

数据流2

用文字描述系统之间的接口关系；

2.3.产品目标

对项目上线的目标做出相应的描述，包括项目上线后期望达到的目标明确下来。（也可以对项目的效果给出期望）

例：（购物车2改版项目）

对购物车2，整体目标有：尽量简化中间的交互效果，突出出来相应的关键信息，给用户以明确的引导流，整体是一个操作表单的界面，所以，尽量保持整体页面简洁明了。现有购物车2的流失率为30%，上线后，期望目标减少到13%。

2.4.用户角色

定义使用本系统的用户角色，包括前台（匿名，注册用户），后台（不同角色，各自的权限或工作内容定义）。通过如下表格或用例图的方式把用户角色和下一节的功能串联起来。

用户角色	职责描述	使用功能
门户小二	管理某个特定品类的产品吧。	●词条管理
		●

说明：下一章节“功能模块”中用到的用户角色名称必须与该章节定义的角色名称一致。该章节中定义的使用功能或用例必须与“功能模块”中的功能一致。

2.5.同类产品(选写)

该板块主要为其他对标网站的截图与分析，对产品设计提出指导建议：

-  京东商城2级页面，其结构类似于专区频道与列表页的结合体。其信息架构与其他频道页、首页结构基本保持统一。 

- 该页面不只是商品的陈列，促销活动、排行等内容也占据大量面积。 

-  左侧类目结构为全2级、2.5级展开式布局。 

  各分类2级页面大结构一致，在UI视觉、细节板块设计上有所不同，给用户差异化感受。

3.功能需求

3.1.流程图

主要为项目业务流程的梳理，帮助理清各个业务点的逻辑关系。可以是某个业务的系统处理流程，也可以是页面的跳转关系等。

未认证激活流程

3.2.功能模块

使用功能列表，对所包括的功能总结，使读者能有个整体概念，在第4.2章节描述各功能模块的详细内容。需求编号是为了更好的进行需求变更和测试用例管理。需求编号请遵守《SN_SRM_需求编号命名及管理规范.doc》。

需求编号	主功能	子功能	功能描述	优先级
CPB_CTGL.01.O1	词条管理	词条管理	门户小二可以增加新的产品吧词条。	高

优先级设定：为便于根据项目资源对需求进行裁剪设定优先级。 作为判断的一个依据, 建议以业务价值判定作为参考, 建议分成 高、中、低三级，缺省为中级，具体定义为：

1.高- 必要的，该功能不能缺少，否则产品无法使用。

2.中- 有条件的，有些需求可以优化，如果缺少这些功能，依旧是可接受的。

3.低- 可选的，这意味着，有些功能可能暂时不值得去做，但做了可能会更好。

3.3.功能详情

需求编号：子功能

一、简要说明

门户小二可以增加新的产品吧词条。

二、执行者

   门户小二

三、界面原型

建议产品经理使用Axure进行界面原型定义，对页面区块和页面元素进行说明。

编号	区块名称	用途描述
1	通用页头页尾	苏宁易购通用页头页尾
2	面包屑	首页>商品团购>商品详情 点击“首页”原窗口跳转至易购首页，点击“商品团购”，原窗口跳转至定金阶梯团聚合页；
3
4
5

四、前置条件

   在词条管理上，点击“添加产品吧词条”。

五、后置条件

    添加成功后，关闭当前层，刷新类目列表。

六、主流程 （建议以用户操作、系统反馈的方式进行描述。如果涉及到复杂的后台业务处理流程，可以使用单独小节，并结合流程图进行说明。）

1.门户小二点击“添加产品吧词条”

2.系统在当前页面弹出新词条层，按照输入数据说明内容填写表单；

3.门户小二点击“保存信息”

4.系统根据“输入数据说明”进行检查，符合系统要求后，将内容写入数据库，关闭当前层，刷新分类列表。

七、表单数据说明

NO	名称	长度	默认值	必需	约束说明
1	词条名称	15个汉字	无	Y	长度直接在输入框，词条需要做唯一性校验
2	分类		初始化一级分类	Y	小二先选择当前已经有的类目第一级大类
3

八、业务规则

  在产品吧第一期，所有产品吧属于一级分类

九、分支流程

1.如果词条名称不正确，系统提示“请输入不超过15个汉字长度的名称。”。

十、补充说明：

3.4.集成类需求

请详细说明此产品的系统与其它系统的集成需求。(详细的功能应在「功能详情」中说明)。请使用《业务集成接口清单》编写本部分内容。拷贝文件内容到此，或插入该文件，或提供该文件链接。

4.非功能需求

4.1.技术约束类

响应时间

吞吐率

请根据下表中非功能需求项进行定义。

名称	含义	举例
响应时间	响应时间指完成一个交互的总时长，从客户端发起请求开始，到客户端接收完服务器响应结果结束。如果系统中含有多种类型的交互，可以考虑分类设置响应时间需求。	订单流程页面响应时间应当小于10秒。
吞吐率	吞吐率指系统在单位时间内处理的交易总数	系统应当满足100笔每秒的订单创建，同时200笔每秒的订单查询。
终端用户可用性	终端用户可用性指用户可以使用系统的时间。	24*7，即一天24小时，一周7天
可扩展性	可扩展性指如果未来业务需求增长，系统架构能否通过最小代价改变支持增长的能力。最小代价改变如增加集群服务器数量等。该需求指方案是否需要考虑可扩展性的问题。	系统需要具备良好的可扩展性。
核心数据存储量	使用数据库系统必需。核心数据存储量指系统需要存储于数据库中的用户，库存，订单，价格的预估数量。	会员中心要在数据库中存储1亿会员信息
访问用户数	前台系统必需。访问用户数指单位时间内访问系统的用户总数。	系统应当支持每小时1百万的访问用户数。
静态资源存储需求	前台系统必需。静态资源存储需求之系统对于存储图片，HTML等文件存储量的预估存储需求	系统需要100GB空间存储商品详细介绍图片。
新域名需求	新前台系统外部必需。使用新的域名需要配置CDN，做为CDN配置的管理部门，优化管理部要求在新系统业务需求中明确是否需要使用新的域名。	游戏频道需要使用新的域名，建议使用game.suning.com

4.2.产品营销需求

主站曝光机制

配合产品功能模块上线，期望在苏宁易购网站上的推广机制，以下罗列本产品希望在全站推广的模块：（如：客户端产品）

曝光位置	原因	其他说明
首页导航增加客户端	新产品推广
购物车4增加客户端下载文字链接	用户购物关联性
我的易购增加订单页面增加客户端下载	操作关联性
机票频道首页增加客户端下载	产品属性关联性
登陆页面左侧广告替换为客户端上线广告	推广新频道

产品运营规范

描述该产品上线后运营怎么去使用它，哪些能做哪些不能做，比如只能做单品，价格要在多少范围，这个是和运营约束好的。

客户服务需求

描述该产品上线后是否需要呼叫中心人员提供服务，服务的内容是什么。可以单独定义针对客服人员的文档。

安全性需求

请依据下表进行系统安全性需求进行审查。

4.3.其它需求

描述其它在财务、法律等方面的需求。