1、 研制令号日期项目软 件 需 求 说 明 书（该文档仅供内部参考）负责单位： 研发部门名称 协作单位： 协作单位名称 （如有） 作 者： 研发人员签名 批 准： 总工程师签名 修改及签收情况记录：版本号 修改人 修改日期 修改批准人 部门资料室签收研发人员签名研发部门主任签名部门资料员存档签名*股份有限公司软件需求说明书 Vm.n第 1 页 共 46 页修改记录文件编号 版本号 拟制人/修改人 拟制/修改日 期 更改理由 主要更改内容（写要点即可）注 1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。注 2：文件第一次归档时， “更改理由” 、 “主要更改内容”栏写“无”
2、 。软件需求说明书 Vm.n第 2 页 共 46 页目 录1 引言 .71.1 编写目的 .71.2 预期的读者和阅读建议 .71.3 文档约定 .72 术语、定义和缩略语 .82.1 术语、定义 .82.2 缩略语 .83 综合描述 .93.1 背景 .93.2 功能概述 .103.3 运行环境 .113.4 用户类及其要求 .114 具体需求 .134.1 功能需求 .184.1.1 .194.1.2 .254.2 性能需求 .284.2.1 .284.2.2 .294.3 质量属性需求 .294.3.1 可靠性 .314.3.2 安全性 .324.3.3 可维护性 .334.3.4 可移
3、植性 .344.3.5 扩展性 .344.3.6 可测试性 .354.4 外部接口需求 .364.5 其它需求 .364.5.1 通用化、系列化、模块化需求 .364.5.2 设计和实现上的限制 .374.5.3 执行标准 .394.5.4 国际化需求 .414.5.5 杂类需求 .425 需求追踪 .436 验收准则 .437 参考文献 .44软件需求说明书 Vm.n第 3 页 共 46 页软件需求说明书 Vm.n第 4 页 共 46 页设计和实现，则在继续工作前，需求还需要进一步细化。2) 如果（软件）系统测试人员需要 SRS 的作者额外的解释才能理解需求，并进而编写（软件）系统测试规程/
4、测试用例，则在继续工作前，需求还需要进一步细化。d) 在概要甚至详细设计前怎么能描述功能需求的正常过程呢？1) 首先要明确，软件需求描述的是“被描述系统” （如整个软件或某个软件子系）对外提供的功能、性能、质量属性、外部接口等，可以将“被描述系统”看成一个黑盒（如果在需求描述的过程中，涉及到了“被描述系统”内部的组成，则可以认为该描述不满足要求。当然，也有些例外情况。如对于网管这种已经很成熟的软件，在描述需求时，可以按终端与服务器分别进行描述） 。而概要设计是对“被描述系统”内部组成及其相互关系进行设计，此时， “被描述系统”是一个白盒。2) 功能需求的过程描述是对完成功能的操作/执行步骤（而
5、不是具体的内部实现流程）进行描述，一方面为后续设计提供基本的处理流程，另一方面（更为重要）在描述正常过程、可选过程及异常过程（后两个过程在以往的实践中经常需要到详设、甚至编码时才能部分确定）的过程，揭示各种数据项（详细定义于数据字典中）及业务规则（如数据合法性、一致性、匹配等） 。3) 除了设计和实现上的限制及标准化相关需求外，SRS 只描述软件“做什么” ，不应该包括设计、构造、测试或工程管理的细节。而概要设计是讲“如何做”才能满足“做什么” 。编制 SRS 时，应考虑以下情况：a) 在编制 SRS 前，应熟悉软件需求说明书评审检查单。在编制过程中应注意避免出现检查单中所列的常见问题。b)
6、如果不能保证与上游文档间的追踪关系，则 SRS 的编制就是失败的，同行评审将不能关闭（甚至可以将这个要求列入同行评审的准入条件） 。因此，对于 SRS 的作者来说，应将需求追踪放到足够重要的位置。作为检查的手段之一，在提交SRS 进行同行评审前，作者应先进行需求追踪。c) 对于需求主要由协议/标准 /规范规定的软件，在编制 SRS 时，为了准确、完整描述需求，同时为减少文档的规模，可以采用“引用”的方法（建议句式为“见” ） ，但“引用”应完整，读者能方便、快速地找到目标内容。这就要求引用时应列出协议/标准/规范名称、篇/章节号（如果不是整节引用，还应列出“开始页号及行号、结束页号及行号” ）
7、 。如果是不完全引用，应明确说明并指出异同。注意：此处未要求列出具体版本， “协议/标准/ 规范”的版本信息在 “执行标准”中统一列出，这样可避免同时引用一份“协议/标准/ 规范 ”的多个版本。这也意味着，一旦“协议/标准/规范”发生变更，所有的引用可能都得修改。本条要求同样适用于对文件的引用。d) 为了更好地使用需求追踪工具 RequisitePro（以下简称 RP）进行需求追踪，在描软件需求说明书 Vm.n第 5 页 共 46 页述需求时应注意图与表格的使用。1) 图可以是 Word 图（此处图是指插入的 “对象” ） 、PaintBrush 图、PowerPoint 图、Visio 图等
8、，但应是 “嵌入型“的，而不能是 “浮于文字上方”等其它形式。同时，应尽可能将图插在需求描述的中间，这样当图发生变化时，就可以通过在图前或图后加减空格，使得 RP 知道需求发生了变化。2) 由于 RP 只能识别整表或一个一个的单元格，因此，一条需求要么只占一个单元格，要么占满整表。编制本文档时，容易犯的错误有：a) 不顾文档上下游之间的关系，先编写设计方案，然后（有些项目拖得非常后）再编写本文档。这种做法是不对的，容易导致几个问题。一是在没有确定做什么（需求）的情况下就去描述怎么做（设计） ，极易导致返工。二是在需求文档中大段大段地描述如何设计与实现。三是在已有设计文档的情况下，写需求文档被认
9、为是炒冷饭，因此不愿意再完整编写。b) 认为只有在详细设计时才可能把处理过程写清楚。甚至认为功能需求根本无需描述处理过程，因为那是详细设计要做的事。这种认识无疑是错误的。因为，用户是通过与软件（系统）交互来完成其任务的，如果设计与实现的交互过程与用户要求或想象的不一致，则用户就会认为软件（系统）不好。因此，交互过程应最大限度地被满足，应该尽早在需求说明书中描述。另外，可选、异常及业务规则（如“只有经理级人员才可查看成本价” ）都隐藏于交互过程中，在需求开发过程中，如果没有描述交互，则很可能遗漏可选、异常及业务规则。c) 在一段中描述若干条需求，或将若干需求合并在一条需求中描述（常见于“性能需求
10、”的描述中） 。这种写法比较难以阅读，进行需求追踪时捕获需求也不是很方便。d) 对于非功能需求（如性能、质量属性需求等） ，只定性描述（如系统要稳定、CPU占用率低） 。这样的描述无法验证。应该定量描述，且还应描述对应的条件。本模板在格式上有以下一系列约定：a) 用“”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或去掉“”后予以适当沿用。b) 本模板提供的示例，格式上都采用整行的“”框起来，同时还会给例子一个编号和名称，以方便阅读与引用。c) 为了方便模板使用者删除，对本身保持黑色。同时，由于示例部分可能会被模板的使用者直接沿用，因此仍然使用黑色，（即“”、或者其它如表格中的例
11、子用黑色）。但如果示例中又插入了一些指导说明文字，则这软件需求说明书 Vm.n第 6 页 共 46 页些文字必须用蓝色。d) 如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写“无” ，而不要将该章节删除或不填写任何内容（即留白。留白将使评审员或读者无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？） 。软件需求说明书 Vm.n第 7 页 共 46 页1 引言1.1 编写目的本文通过详细描述软件的功能需求、性能需求、质量属性需求、外部接口需求以及其它需求，为后续概要设计、软件（系统）测试、用户文档等工作提供基础与约束。1.2 预期的读者和阅读建议预期的读者和阅读建议参见
12、表 1.1。表 1.1读者分类 阅读重点及目的 备注1.3 文档约定软件需求说明书 Vm.n第 8 页 共 46 页2：是可能的，它规定了那些有了会更好但没有也没有什么关系的功能，如一些提高效率的小工具。1：是备忘的，它规定了我们想象的但目前无法或无需实现的需求。=Example End=2 术语、定义和缩略语2.1 术语、定义本文使用的专用术语、定义见表 2.1，通用术语、定义见 术语、定义和缩略语 。表 2.1术语/定义 英文对应词 含 义2.2 缩略语本文使用的专用缩略语见表 2.2，通用缩略语见 术语、定义和缩略语 。缩略语已按其第 1 个字母顺序排列。表 2.2缩略语 英文原文 中文
13、含义软件需求说明书 Vm.n第 9 页 共 46 页3 综合描述3.1 背景本节主要描述以下内容：a) 系统的背景和起源。重点说明该系统是否是产品系列中的下一成员、是否是现有应用的替代品，或者是否是一个新型的、自含型产品。对于在老版本之上升级的系统，则还应说明：1) 老版本出现的主要问题；2) 新版本需要增加或改进的主要内容。此段内容可能来自于可行性研究报告等上游相关文档。应该对相关内容进行概括而不是照抄，篇幅一般应控制在 5 个自然段之内。b) 本系统在整个系统或整个环境中的位置。必须使用上下文图(context diagram) 或高层用例图说明本系统（必须用文字及不同的颜色明确标识出来）与外界（可能包括整个系统外的实体）之间的联系，如图 3.1。上下文图能清晰地表达系统与外部环境的边界，及系统与外部环境的关系，帮助读者更好、更快地理解被描述的系统。实践中经常犯的错误是： 1) 不画图；2) 画了系统内部组成图或协议栈；3) 在上下文图中，还描述了外部系统之间关系。
