软件需求说明书模板.docx

1、软件需求说明书模板 研制令号日期 项目软 件 需 求 说 明 书（该文档仅供内部参考）负责单位： 研发部门名称 协作单位： 协作单位名称 （如有） 作 者： 研发人员签名 批 准： 总工程师签名 修改及签收情况记录： 版本号修改人修改日期修改批准人部门资料室签收研发人员签名研发部门主任签名部门资料员存档签名*股份有限公司修改记录文件编号版本号拟制人/修改人拟制/修改日期更改理由主要更改内容（写要点即可）注1：每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。注2：文件第一次归档时，“更改理由”、“主要更改内容”栏写“无”。术语说明：a) 需求：是指“被描述系统”“做什么”（功

2、能需求）及“做什么”时的水平（非功能需求，如性能需求、质量属性需求、外部接口需求、其它需求）。b) 软件需求：由软件实现的需求。包括功能需求、性能需求、质量属性需求、外部接口需求及其它需求。c) 软件需求说明书（software requirement specification，SRS）：是这样一类文档，它以特定的格式记载了软件必须实现的所有软件需求（又叫软件需求规格、软件需求规格说明），在必要时，也应描述软件肯定不做什么（何谓必要？在某些上下文语境中，如果不作这样的声明，可能会令读者发生误会）。SRS为后续的项目软件计划、概要设计、（软件）系统测试、用户文档等工作提供基础与约束。 编制SR

3、S时经常被问到以下问题：a) 实践中出现了不少这样的情况：明明要求写软件需求说明书，但结果写出了模块需求说明书。这实际上反映了这些实践未正确确定“被描述系统”。那么，如何确定“被描述系统”呢？1) 在编写SRS前，一定要明确“被描述系统”，该系统应是上游文档中已经明确划分出来的；同时应将“被描述系统”作为黑盒（特殊情况下可以是灰盒甚至是白盒，如网管软件，可以按终端、服务器）来描述。2) 对于纯软件项目，很显然，由于SRS的上游文档研制任务书没有对软件进行划分，因此，SRS中“被描述系统”应该是整个软件，而不是其中的某个模块。3) 对于软硬件大系统，一般通过系统设计活动，SRS的上游文档系统方案

4、已经对系统进行了划分，因此，SRS中“被描述系统”可以是划分出来的任何一个软件块。b) 应该编写几篇SRS？1) 对于软硬件大系统，SRS是根据系统方案、标准/协议/规范、研制规范、原始需求（其中可能直接含有功能需求、性能需求、质量属性需求、外部接口需求、其它需求）开发出来的。根据系统的复杂程度，可以编制一到多篇SRS。如果SRS的上游文档（系统方案）满足其编制要求，则可以为每个单板的软件部分（如果该单板存在软件的话）写一篇SRS。注意：在系统方案模板中，此处的单板软件被统称为“软件子系统”，该“子系统”（按业务按纵向划分）的概念比我们熟悉的诸如“OSS子系统”、“DBS子系统”更广泛，“OS

5、S子系统”、“DBS子系统”（横向即分层划分）等是通过软件概要设计设计出来的，并体现在软件总体设计方案中。2) 对于纯软件项目，SRS是根据研制任务书、标准/协议/规范、原始需求说明书开发出来的。一般说来，只写一篇SRS是比较合适的。c) SRS编写到什么程度才算完成？比较通行的原则是：1) 如果设计与开发人员需要SRS的作者额外的解释才能理解需求，并进而进行设计和实现，则在继续工作前，需求还需要进一步细化。2) 如果（软件）系统测试人员需要SRS的作者额外的解释才能理解需求，并进而编写（软件）系统测试规程/测试用例，则在继续工作前，需求还需要进一步细化。d) 在概要甚至详细设计前怎么能描述功

6、能需求的正常过程呢？1) 首先要明确，软件需求描述的是“被描述系统”（如整个软件或某个软件子系）对外提供的功能、性能、质量属性、外部接口等，可以将“被描述系统”看成一个黑盒（如果在需求描述的过程中，涉及到了“被描述系统”内部的组成，则可以认为该描述不满足要求。当然，也有些例外情况。如对于网管这种已经很成熟的软件，在描述需求时，可以按终端与服务器分别进行描述）。而概要设计是对“被描述系统”内部组成及其相互关系进行设计，此时，“被描述系统”是一个白盒。2) 功能需求的过程描述是对完成功能的操作/执行步骤（而不是具体的内部实现流程）进行描述，一方面为后续设计提供基本的处理流程，另一方面（更为重要）在

7、描述正常过程、可选过程及异常过程（后两个过程在以往的实践中经常需要到详设、甚至编码时才能部分确定）的过程，揭示各种数据项（详细定义于数据字典中）及业务规则（如数据合法性、一致性、匹配等）。3) 除了设计和实现上的限制及标准化相关需求外，SRS只描述软件“做什么”，不应该包括设计、构造、测试或工程管理的细节。而概要设计是讲“如何做”才能满足“做什么”。编制SRS时，应考虑以下情况：a) 在编制SRS前，应熟悉软件需求说明书评审检查单。在编制过程中应注意避免出现检查单中所列的常见问题。b) 如果不能保证与上游文档间的追踪关系，则SRS的编制就是失败的，同行评审将不能关闭（甚至可以将这个要求列入同行

8、评审的准入条件）。因此，对于SRS的作者来说，应将需求追踪放到足够重要的位置。作为检查的手段之一，在提交SRS进行同行评审前，作者应先进行需求追踪。c) 对于需求主要由协议/标准/规范规定的软件，在编制SRS时，为了准确、完整描述需求，同时为减少文档的规模，可以采用“引用”的方法（建议句式为“见”），但“引用”应完整，读者能方便、快速地找到目标内容。这就要求引用时应列出协议/标准/规范名称、篇/章节号（如果不是整节引用，还应列出“开始页号及行号、结束页号及行号”）。如果是不完全引用，应明确说明并指出异同。注意：此处未要求列出具体版本，“协议/标准/规范”的版本信息在“执行标准”中统一列出，这样

9、可避免同时引用一份“协议/标准/规范”的多个版本。这也意味着，一旦“协议/标准/规范”发生变更，所有的引用可能都得修改。本条要求同样适用于对文件的引用。d) 为了更好地使用需求追踪工具RequisitePro（以下简称RP）进行需求追踪，在描述需求时应注意图与表格的使用。1) 图可以是Word图（此处图是指插入的“对象”）、PaintBrush图、PowerPoint图、Visio图等，但应是“嵌入型“的，而不能是“浮于文字上方”等其它形式。同时，应尽可能将图插在需求描述的中间，这样当图发生变化时，就可以通过在图前或图后加减空格，使得RP知道需求发生了变化。2) 由于RP只能识别整表或一个一个

10、的单元格，因此，一条需求要么只占一个单元格，要么占满整表。编制本文档时，容易犯的错误有：a) 不顾文档上下游之间的关系，先编写设计方案，然后（有些项目拖得非常后）再编写本文档。这种做法是不对的，容易导致几个问题。一是在没有确定做什么（需求）的情况下就去描述怎么做（设计），极易导致返工。二是在需求文档中大段大段地描述如何设计与实现。三是在已有设计文档的情况下，写需求文档被认为是炒冷饭，因此不愿意再完整编写。b) 认为只有在详细设计时才可能把处理过程写清楚。甚至认为功能需求根本无需描述处理过程，因为那是详细设计要做的事。这种认识无疑是错误的。因为，用户是通过与软件（系统）交互来完成其任务的，如果设

11、计与实现的交互过程与用户要求或想象的不一致，则用户就会认为软件（系统）不好。因此，交互过程应最大限度地被满足，应该尽早在需求说明书中描述。另外，可选、异常及业务规则（如“只有经理级人员才可查看成本价”）都隐藏于交互过程中，在需求开发过程中，如果没有描述交互，则很可能遗漏可选、异常及业务规则。c) 在一段中描述若干条需求，或将若干需求合并在一条需求中描述（常见于“性能需求”的描述中）。这种写法比较难以阅读，进行需求追踪时捕获需求也不是很方便。d) 对于非功能需求（如性能、质量属性需求等），只定性描述（如系统要稳定、CPU占用率低）。这样的描述无法验证。应该定量描述，且还应描述对应的条件。本模板在

12、格式上有以下一系列约定：a) 用“”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或去掉“”后予以适当沿用。b) 本模板提供的示例，格式上都采用整行的“”框起来，同时还会给例子一个编号和名称，以方便阅读与引用。c) 为了方便模板使用者删除，对内的所有编写指导文字都使用蓝色，但本身保持黑色。同时，由于示例部分可能会被模板的使用者直接沿用，因此仍然使用黑色，（即“”、或者其它如表格中的例子用黑色）。但如果示例中又插入了一些指导说明文字，则这些文字必须用蓝色。d) 如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写“无”，而不要将该章节删除或不填写任何内容（即留白。

13、留白将使评审员或读者无法判断：是本章节内容无需填写还是因为疏忽而忘了填写？）。1 引言1.1 编写目的本文通过详细描述软件的功能需求、性能需求、质量属性需求、外部接口需求以及其它需求，为后续概要设计、软件（系统）测试、用户文档等工作提供基础与约束。1.2 预期的读者和阅读建议预期的读者和阅读建议参见表1.1。表1.1读者分类阅读重点及目的备注1.3 文档约定2 术语、定义和缩略语2.1 术语、定义本文使用的专用术语、定义见表2.1，通用术语、定义见 术语、定义和缩略语。表2.1术语/定义英文对应词含 义2.2 缩略语本文使用的专用缩略语见表2.2，通用缩略语见 术语、定义和缩略语。缩略语已按其

14、第1个字母顺序排列。表2.2缩略语英文原文中文含义3 综合描述3.1 背景=Example Begin=例 背景网管软件需要管理两种网元：一种是ANU，一种是ICSC。两种网元不同之处在于前者用的是A型机平台，后者用的是B型机平台。两者的操作方式差异很大：ANU的操作以字符人机命令为主；ICSC的操作命令基本上已实现图形化。对于用户来说，需要在一个网管软件上实现对这两种网元的统一处理。本文即描述了统一管理ANU和ICSC的网管软件的需求。图3.2描述了本网管软件的上下文图(Context diagram)。图3.2 上下文图本网管软件与外界的联系见图3.2的文字说明。=Example End=

15、3.2 功能概述3.3 运行环境运行环境见表3.1。表3.1名 称硬件(CPU/RAM/HD)操作系统及其版本其它软件环境3.4 用户类及其要求4 具体需求本章描述功能需求、性能需求、质量属性需求、外部接口需求及其它需求。我们规定：a) 功能需求编号的前缀为SR-F（F表示功能）；b) 性能需求编号的前缀为SR-P（P表示性能）；c) 质量属性需求编号的前缀为SR-Q（Q表示质量）；d) 外部接口需求编号的前缀为SR-I（I表示接口）；e) 其它需求编号的前缀为SR-M（M表示杂类）。需要说明的是，如果一个项目有多篇SRS，假定划分的粒度是子系统，则其编号前缀应改为：“SR-” + “子系统名

16、” + “-” + “需求类别（如F、P、Q、I、M）”，如SR-DB-F。如果需求是分组描述的，则还要在“需求类别”后再加上需求组，如SR-DB-F-G1。无论如何，应保证需求编号在项目中的唯一性。在编写本章时，还应注意以下问题：a) 如果项目被要求编写数据字典，则应在项目的早期（如项目论证阶段）就编写数据字典，以定义相关的数据元素和结构（如输入、输出、存储或数据表字段等，一般与功能、内外部接口等相关）的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围。需求描述中的输入项可以直接引用数据字典的数据项。数据字典应独立维护。b) 无论是需求编号还是需求内部描述的步骤号，都应手工编号，而不要使用编辑器的自动编号。因为如果采用自动编号，一旦增加或删除中间的某个编号，将会引起其后所有需求的RP记录的变更，并影响处理过程中的引用关系。c) 需求优先级的设置应基于上游文档中相关内容的优先级，一般应不比上游的低。d) 本文档中不得描述需求的实现版本信息。需求实现的版本信息应体现在两个地方：一是项目计划中；二是需求追踪工具RP中的需求属性：实现版本。在阅读以下内容时，如果结合软件需求说明书评审检查单，将能取得更加好的效果。好的单条需求的描述应具有以下特征。摘自软件需求第1.5节，Karl E. Wiegersa) 完整性。每一项需求都必须将所要实现的功能描述