系统需求说明书模版

《系统需求说明书模版》由会员分享，可在线阅读，更多相关《系统需求说明书模版（15页珍藏版）》请在金锄头文库上搜索。

1、系统需求说明书使用说明：本文档适用于系统需求定义。本文档主要用于说明系统要做什么，做成什么样子。侧重于系统功能、系统处理逻辑、人机交互和数据的定义。模板中以蓝色斜体显示的文本，用于向作者提供指导，在文档编辑完成后应该将其删除。文档正文应使用常规、黑色、五号字体，即系统设置的“正文”样式。当某一章/节没有内容时，必须注明N/A，同时标注理由。例如：本章/节内容无需考虑。特别说明：当某章/节内容参见其它文档时，不能注明N/A，而应该写明参见某文档的路径名称或章节等。文件状态： 草稿 正式发布 正在修改文件编号：SN_RT05当前版本：V1.5作 者：李伟佳完成日期：2014-2-20版本信息版本时

2、间状态简要描述部门更改人批准人V0.92013-3-12N创建产品设计理部刘桂军V1.02013-3-18N根据产品规划部建议，增加4.2章节。产品设计理部刘桂军V1.52014-2-20M文档格式修改质量控制部李伟佳陈军注：状态可以为N-新建、A-增加、M-更改、D-删除。目 录1.关于本文档41.1.内容说明41.2.适用范围41.3.术语51.4.参考文档51.5.沟通要求52.产品概述62.1.产品概述62.2.产品范围72.3.产品目标72.4.用户角色72.5.同类产品(选写)83.功能需求93.1.流程图93.1.1.未认证激活流程93.2.功能模块93.3.功能详情103.3.

3、1.需求编号：子功能103.4.集成类需求124.非功能需求124.1.技术约束类124.1.1.响应时间124.1.2.吞吐率124.2.产品营销需求134.2.1.主站曝光机制134.2.2.产品运营规范134.2.3.客户服务需求144.2.4.安全性需求144.3.其它需求151. 关于本文档1.1. 内容说明本文档用于描述XXXX产品的系统需求定义。包括各个需求的功能描述，处理逻辑规则，界面定义，与其它功能的关系，与其它系统的接口等各个方面的定义。是该系统唯一的全面需求定义文档。根据需求管理流程和要求，产品经理随系统功能变化进行及时的修订和更新，以确保本文档的全面性，准确性和实效性。

4、因此在阅读使用此文档时，请注意从项目的文档管理系统中获取最新版本。1.2. 适用范围一、 本文档由产品设计团队和用户体验团队共同完成，由产品经理负责。二、 本文档在产品设计团队编写完成后，由产品经理组织评审，评审过程遵守SN_QP01产品研发评审规范.docx。评审团队包括：业务代表（运营方）、产品经理上级领导、产品规划部门、用户体验设计团队、产品架构师、技术经理及核心开发人员、测试经理、产品设计管理部。三、 本文档在需求评审后，作为需求基线，由用户体验设计团队进行交互和视觉设计（内部项目可选），研发团队进行概要设计，测试团队准备测试方案。四、 用户体验设计评审后修订本文档一次，增加一个小版本

5、号。五、 项目周期内，在需求评审结束后，所有需求变更，请在JIRA上走需求变更流程。六、 未经过需求评审或需求变更的需求，交互设计团队和研发团队不能进入正式设计研发阶段。七、 关于需求管理、需求变更、本文档使用如果有问题，请咨询产品设计管理部。1.3. 术语词汇名称词汇含义备注【定义及说明与此系统有关的特殊名词（专门术语）或简写、各类编号、代码等等】1.4. 参考文档为了更好理解本文档，请阅读如下文档。编号文档说明及地址1XXXX产品定义说明书v1.pptx说明：是该产品的立项文档，定义了该产品的需求、产品设计和运营思路等基本内容。获取地址：2XXXX业务需求说明书v1.0.doc说明：描述了

6、业务功能描述、业务流程、业务实体和业务规则等。获取地址：1.5. 沟通要求本表记录需要跨部门沟通的事项，以保证该文档内容质量。如果有其它跨部门沟通项，请填写该表中，并记录沟通结果。序号角色沟通内容沟通结果1用户体验用户需求、用户群体特征等。是2产品运营团队沟通需求具体内容；4.2.2节，产品运营规范是3安全优化系统安全性不需要4客服讨论客服如何支持：客服需求协助评估诈欺/数据窜改风险：欺诈/数据窜改风险、不当使用风险预测客服成本、工作量否，待安排5技术总监EA团队讨论以确定方案的规模评估、推出计划进行技术可行性分析，提出关键问题的技术解决方案评估系统规模，数据量，所需资源等协助评估风险2. 产

7、品概述本章节详细描述产品的背景、内容和目标等进行详细定义，关于产品定义的其它内容请阅读本产品定义说明书。2.1. 产品概述对项目启动的背景和要做的内容进行简要的描述，包括产品的背景，产品的要做的内容等。例：（购物车2改版项目）购物车2改版的背景：现有购物车2存在着用户点击进入之后，对要填写的信息不明确，不清楚后续的操作步骤，中间的相关交互较为复杂，关键的信息点不明确，点击保存按钮不突出，显示出来的干扰信息较多等问题，基于这个，我们提出这次购物车优化项目。2.2. 产品范围通过环境图的方式描述本系统与其它业务系统之间的交互关系。系统范围图使用环境图方法：本系统数据流3数据流1外部系统1外部系统2

8、本系统数据流2用文字描述系统之间的接口关系；2.3. 产品目标对项目上线的目标做出相应的描述，包括项目上线后期望达到的目标明确下来。（也可以对项目的效果给出期望）例：（购物车2改版项目）对购物车2，整体目标有：尽量简化中间的交互效果，突出出来相应的关键信息，给用户以明确的引导流，整体是一个操作表单的界面，所以，尽量保持整体页面简洁明了。现有购物车2的流失率为30%，上线后，期望目标减少到13%。2.4. 用户角色定义使用本系统的用户角色，包括前台（匿名，注册用户），后台（不同角色，各自的权限或工作内容定义）。通过如下表格或用例图的方式把用户角色和下一节的功能串联起来。用户角色职责描述使用功能门

9、户小二管理某个特定品类的产品吧。l 词条管理l说明：下一章节“功能模块”中用到的用户角色名称必须与该章节定义的角色名称一致。该章节中定义的使用功能或用例必须与“功能模块”中的功能一致。2.5. 同类产品(选写)该板块主要为其他对标网站的截图与分析，对产品设计提出指导建议：- 京东商城2级页面，其结构类似于专区频道与列表页的结合体。其信息架构与其他频道页、首页结构基本保持统一。 - 该页面不只是商品的陈列，促销活动、排行等内容也占据大量面积。 - 左侧类目结构为全2级、2.5级展开式布局。 各分类2级页面大结构一致，在UI视觉、细节板块设计上有所不同，给用户差异化感受。3. 功能需求3.1. 流

10、程图主要为项目业务流程的梳理，帮助理清各个业务点的逻辑关系。可以是某个业务的系统处理流程，也可以是页面的跳转关系等。3.1.1. 未认证激活流程3.2. 功能模块使用功能列表，对所包括的功能总结，使读者能有个整体概念，在第4.2章节描述各功能模块的详细内容。需求编号是为了更好的进行需求变更和测试用例管理。需求编号请遵守SN_SRM_需求编号命名及管理规范.doc。需求编号主功能子功能功能描述优先级CPB_CTGL.01.O1词条管理词条管理门户小二可以增加新的产品吧词条。高优先级设定：为便于根据项目资源对需求进行裁剪设定优先级。 作为判断的一个依据, 建议以业务价值判定作为参考, 建议分成 高

11、、中、低三级，缺省为中级，具体定义为：1. 高- 必要的，该功能不能缺少，否则产品无法使用。2. 中- 有条件的，有些需求可以优化，如果缺少这些功能，依旧是可接受的。3. 低- 可选的，这意味着，有些功能可能暂时不值得去做，但做了可能会更好。3.3. 功能详情3.3.1. 需求编号：子功能一、 简要说明门户小二可以增加新的产品吧词条。二、 执行者 门户小二三、 界面原型建议产品经理使用Axure进行界面原型定义，对页面区块和页面元素进行说明。编号区块名称用途描述1通用页头页尾苏宁易购通用页头页尾2面包屑首页商品团购商品详情点击“首页”原窗口跳转至易购首页，点击“商品团购”，原窗口跳转至定金阶梯

12、团聚合页；345四、 前置条件 在词条管理上，点击“添加产品吧词条”。五、 后置条件 添加成功后，关闭当前层，刷新类目列表。六、 主流程 （建议以用户操作、系统反馈的方式进行描述。如果涉及到复杂的后台业务处理流程，可以使用单独小节，并结合流程图进行说明。）1. 门户小二点击“添加产品吧词条”2. 系统在当前页面弹出新词条层，按照输入数据说明内容填写表单；3. 门户小二点击“保存信息”4. 系统根据“输入数据说明”进行检查，符合系统要求后，将内容写入数据库，关闭当前层，刷新分类列表。七、 表单数据说明NO名称长度默认值必需约束说明1词条名称15个汉字无Y长度直接在输入框限制，词条需要做唯一性校验

13、2分类初始化一级分类Y小二先选择当前已经有的类目第一级大类3八、 业务规则 在产品吧第一期，所有产品吧属于一级分类九、 分支流程1. 如果词条名称不正确，系统提示“请输入不超过15个汉字长度的名称。”。十、 补充说明：3.4. 集成类需求请详细说明此产品的系统与其它系统的集成需求。(详细的功能应在功能详情中说明)。请使用业务集成接口清单编写本部分内容。拷贝文件内容到此，或插入该文件，或提供该文件链接。4. 非功能需求4.1. 技术约束类4.1.1. 响应时间4.1.2. 吞吐率请根据下表中非功能需求项进行定义。名称含义举例响应时间响应时间指完成一个交互的总时长，从客户端发起请求开始，到客户端接收完服务器响应结果结束。如果系统中含有多种类型的交互，可以考虑分类设置响应时间需求。订单流程页面响应时间应当小于10秒。吞吐率吞吐率指系统在单位时间内处理的交易总数系统应当满足100笔每秒的订单创建，同时200笔每秒的订单查询。终端用户可用性终端用户可用性指用户可以使用系统的时间。24*7，即一天24小时，一周7天可扩展性可扩展性指如果未来业务需求增长，系统架构能否通过最小代价改变支持增长的能力。最小代价改变如增加集群服务器数量等。该需求指方案是否需要考虑可扩展性的问题。系统需要具备良好的可扩