<公司名称><项目名称>软件需求规格说明书版本 <1.0> [注：以下提供的模板用于 Rational Unified Process。
其中包括用方括号括起来并以蓝色斜体（样式=InfoBlue）显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。
按此样式输入的段落将被自动设置为普通样式（样式=Body Text）。
][要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择 File>Properties，然后将Title、Subject 和 Company 等字段替换为此文档的相应信息。
关闭该对话框后，通过选择Edit>Select All（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。
对于页眉和页脚，这一操作必须单独进行。
按 Alt-F9，将在显示字段名称和字段内容之间切换。
有关字段处理的详细信息，请参见 Word 帮助。
]修订历史记录目录1.简介51.1目的51.2范围51.3定义、首字母缩写词和缩略语51.4参考资料52.总体概述62.1项目背景62.2关键问题说明62.3项目建设目标62.4项目范围62.5现行业务调查62.5.1职能结构图62.5.2相关岗位职责72.6用户的特点72.7限制与约束73.功能需求83.1功能需求概述83.1.1新系统功能清单83.2功能需求描述83.2.1功能模块1（如：报警中心。
角色桌面作为功能模块进行描述，在功能模块之前描述）83.2.2功能模块2 104.接口需求114.1与XXX系统接口114.1.1XXX系统情况114.1.2接口方案描述114.2与YYY系统接口115.非功能性需求125.1可用性需求125.2性能需求125.3可靠性需求125.4可移植性需求125.5安全性需求126.运行需求136.1网络环境136.2硬件配置136.3软件环境131.简介[软件构架文档的简介应提供整个软件构架文档的概述。
它应包括此软件构架文档的目的、范围、定义、首字母缩写词、缩略语、参考资料和概述。
]本《软件需求规格说明书》是乙方在调研甲方实际业务需求的基础上分析整理后形成的，建立在双方对需求的共同理解基础之上。
《软件需求规格说明书》经双方确认后形成软件需求基线，成为项目后续系列工作开展的基础，不得随意更改。
如果需求发生变化，甲乙双方将按照“需求变更控制规程”执行。
甲乙双方均明白需求的变更将可能导致双方重新协商成本、资源和进度等。
1.1目的【说明：规定系统的边界和目标，描述系统的功能性需求和非功能性需求。
】定义总体要求，作为用户和软件开发人员之间相互了解的基础；提供性能要求、初步设计和对用户影响的信息，作为开发人员进行设计和实施的基础；作为总体验证和确认的依据。
此需求规格说明书主要为明确软件需求、安排项目规划与进度、组织软件开发与测试而撰写本文档。
本文档主要描述了软件的功能需求，可供双方项目参与人员进行参考。
具体编写的目的:作为项目工期及项目费用的一个参考。
在整个项目开发过程中，是双方在功能需求方面上的一个制约，一经确定，任一方不得随意更改。
作为软件开发人员的一个开发标准，供项目经理、设计人员、开发人员参考。
作为委托开发方对本开发软件进行验收的一个标准。
1.2范围[简要说明此软件构架文档适用的范围和影响的范围。
]1.3定义、首字母缩写词和缩略语【说明：列出本文件中用到的专门术语的定义和缩写词的原词组，并给予解释，以便于所有读者达成共识。
】1.4参考资料【说明：列出本文档的所有参考文献，包括计划任务书、合同、批文、引用到的文件、资料及软件开发标准等。
用书名号扩起来】2.总体概述2.1项目背景【说明：概述项目产生的背景情况，如客户的概况、业务的概况、原有系统的概况等。
】2.2关键问题说明【说明：提供一段说明，总结此项目正在解决的问题，如管理上不可控、流程不顺畅、业务处理效率不高2.3项目建设目标【说明：概述客户希望通过项目达到的管理提升、业务改进、效率提高等方面的目标，这是项目的愿景文件，一般不应该超过5条。
】2.4项目范围【说明：阐述本项目“适用的领域”和“不适用的领域”，本项目“应当包含的内容”和“不包含的内容”。
】2.5现行业务调查2.5.1职能结构图【说明：详细说明项目涉及的部门组织结构，目标客户的工作环境。
该项目或具体子系统相关的业务部门、技术部门、管理部门。
职能结构图用VISIO的“组织结构图”编辑，下面是个例图】2.5.2相关岗位职责2.6用户的特点用户基本定位在在校大学生和工薪阶层.2.7限制与约束本网站只对手机这一产品进行网上销售数量有限,对其他产品一律不在本站进行营销活动。
3.功能需求3.1功能需求概述3.1.1新系统功能清单【说明：功能代码、功能模块、功能名称、功能描述、重要程度。
功能代码的编码规则：用数字代码表示，前两位代表子系统，后两位代表功能模块，再后两位表示功能名称，以此类推。
例如：010101，其中前两位01代表智能报警中心子系统，中间两位01代表报警中心模块，最后两位01代表具体功能名称。
权限控制：描述不同权限得角色，是否对该功能模块可见。
优先级是根据需求“轻重缓急”的分级表述，划分为“高、中、低”三级。
系统特性描述：用精炼的语言描述该功能实现的主要功能。
3.2功能需求描述【说明：对于每一类功能需要具体描述，功能代码需对应 3.1.1 新系统功能清单】3.2.1功能模块1（如：报警中心。
角色桌面作为功能模块进行描述，在功能模块之前描述）●本功能的模块图（功能模块选填）●本桌面的界面原型图（角色桌面选填）3.2.1.1功能项11（如：待签收报警信息。
流程信息作为功能项进行描述）【说明：需求编号、功能项、功能页面、功能描述、对应表单、权限控制需求编号：对应上述功能模块中定义的功能项代码；功能项：用简单精炼的词语描述该功能项的名称；功能页面：描述该功能项中包含哪些功能页面；功能描述：用简单精炼得语言描述该功能项、该页面实现的功能：对应表单：填写该功能页面对应7.2表证清单中的表单编号，根据该表单，确定页面设置、打印等功能实现；权限控制：描述不同权限得角色，是否对该功能模块可见。
备注：该部分未描述清楚部分在此说明；】3.2.1.1.1流程图需在工作流绘制流程图，此处为工作流绘制流程图截图。
3.2.1.1.2流程图说明环节编号：描述该环节在工作流中的环节编号。
环节名称：描述该环节的环节名称。
处理实体：描述该环节的处理实体，例如：XX岗位、XX人、XX环节。
跳转条件：描述该环节是否存在跳转、返回、分支等情况。
跳转需要描述跳转到哪一环节，返回需描述返回到哪一环节，分支环节需要描述根据什么条件进行分支及分支后续环节。
备注：该部分未描述清楚部分在此说明；】3.2.1.1.3功能页面●界面原型图【说明：用dreamweaver进行绘制。
】字段名称：字段的中文名称。
字段类型：字段的类型，例如varchar，number等等。
字段长度：描述字段的最大长度。
是否必填项：描述该字段是否需要设置必填属性。
编码规范：描述字段引用的编码规范，如果是国标、部标的编码规范，需填写该标准的代码，如果是自定义的编码规范，需填写该规范的代码（代码详见下文中编码规范中定义的规范代码）；是否设为查询条件：针对查询页面，说明该字段是否需要设为查询条件字段；引用说明：描述该字段是否从前一环节引用过来或者通过数据复用引用过来，以及在该环节是否可以编辑；约束条件：描述对该字段约束条件。
例如身份证号需要进行长度和规则校验，日期型字段需要进行校验，如结束时间不能早于开始时间，根据某些字段控制其他字段的显示等。
权限控制：描述不同权限得角色，是否对该字段可见。
备注：该部分未描述清楚部分在此说明；】按钮/链接名称：按钮/链接的中文名称。
实现功能：描述该按钮/链接实现的功能。
约束条件：描述对该按钮/链接的约束条件。
例如：保存之后才可以出现“传递”按钮等。
权限控制：描述不同权限得角色，是否对该按钮/链接可见。
备注：该部分未描述清楚部分在此说明；】3.2.1.2功能项123.2.2功能模块24.接口需求4.1与XXX系统接口4.1.1XXX系统情况4.1.2接口方案描述【说明：本节描述接口的详细方案，接口用途阐明接口实现的业务需求，如实现数据共享、消息传递等；接口提供方包括我方、其他接口提供厂商；实现方式包括通过中间表、WEB SERVICE、JMS等等；接口实现说明是指需要描述调用该接口涉及到的调用说明文档，相关的各种包、代码和函数等详细信息。
场景是指系统之间实际发生信息传递的情况，比如说调用全国违法人员请求服务，紧接着将场景对应的消息格式详细描述出来，其中编码规范填写规范参考3.2.1.1中编码规范的填写说明】4.2与YYY系统接口5.非功能性需求5.1可用性需求【说明：指客户在界面风格、易用性、易学习性等方面的要求。
】5.2性能需求【说明：指客户在系统响应时间、最大允许的并发客户数等方面的要求。
】5.3可靠性需求【说明：指客户在平均无故障运行时间、故障恢复时间等方面的要求。
】5.4可移植性需求【说明：指客户在系统软硬件平台的可移植性方面的要求。
】5.5安全性需求【说明：指客户在系统的身份认证、权限防护、传输安全等方面的要求。
】6.运行需求6.1网络环境在整个网络环境中，要有两台防火墙及路由器，同时至少包括五台服务器：WebServer服务器、手机电话接入服务器、客户认证服务器、多渠道处理服务器、Web管理服务器。
同时还包括各服务器上运行的系统软件和应用软件：如Windows2000、UNIX、WebSphere、JDK、数据库等等。
6.2硬件配置6.3软件环境。