软件需求说明书模板.docx
《软件需求说明书模板.docx》由会员分享，可在线阅读，更多相关《软件需求说明书模板.docx（60页珍藏版）》请在冰豆网上搜索。
软件需求说明书模板
研制令号
日期
项目
软件需求说明书
（该文档仅供内部参考）
负责单位：
研发部门名称
协作单位：
协作单位名称（如有）
作者：
研发人员签名
批准：
总工程师签名
修改及签收情况记录：
版本号
修改人
修改日期
修改批准人
部门资料室签收
研发人员签名
研发部门主任签名
部门资料员存档签名
**********股份有限公司
修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
（写要点即可）
<
Vm.n
XXX
2006/10/24
XXX
XXXX>
注1：
每次更改归档文件（指归档到事业部或公司档案室的文件）时，需填写此表。
注2：
文件第一次归档时，“更改理由”、“主要更改内容”栏写“无”。
<
模板修改记录
文件编号
版本号
拟制人/
修改人
拟制/修改日期
更改理由
主要更改内容
（写要点即可）
V1.0
***
2013-12-23
初版
>
<术语说明：
a）需求：
是指“被描述系统”“做什么”（功能需求）及“做什么”时的水平（非功能需求，如性能需求、质量属性需求、外部接口需求、其它需求）。
b）软件需求：
由软件实现的需求。
包括功能需求、性能需求、质量属性需求、外部接口需求及其它需求。
c）软件需求说明书（softwarerequirementspecification，SRS）：
是这样一类文档，它以特定的格式记载了软件必须实现的所有软件需求（又叫软件需求规格、软件需求规格说明），在必要时，也应描述软件肯定不做什么（何谓必要？
在某些上下文语境中，如果不作这样的声明，可能会令读者发生误会）。
SRS为后续的项目软件计划、概要设计、（软件）系统测试、用户文档等工作提供基础与约束。
编制SRS时经常被问到以下问题：
a）实践中出现了不少这样的情况：
明明要求写软件需求说明书，但结果写出了模块需求说明书。
这实际上反映了这些实践未正确确定“被描述系统”。
那么，如何确定“被描述系统”呢？
1）在编写SRS前，一定要明确“被描述系统”，该系统应是上游文档中已经明确划分出来的；同时应将“被描述系统”作为黑盒（特殊情况下可以是灰盒甚至是白盒，如网管软件，可以按终端、服务器）来描述。
2）对于纯软件项目，很显然，由于SRS的上游文档－研制任务书－没有对软件进行划分，因此，SRS中“被描述系统”应该是整个软件，而不是其中的某个模块。
3）对于软硬件大系统，一般通过系统设计活动，SRS的上游文档－系统方案－已经对系统进行了划分，因此，SRS中“被描述系统”可以是划分出来的任何一个软件块。
b）应该编写几篇SRS？
1）对于软硬件大系统，SRS是根据系统方案、标准/协议/规范、研制规范、原始需求（其中可能直接含有功能需求、性能需求、质量属性需求、外部接口需求、其它需求）开发出来的。
根据系统的复杂程度，可以编制一到多篇SRS。
如果SRS的上游文档（系统方案）满足其编制要求，则可以为每个单板的软件部分（如果该单板存在软件的话）写一篇SRS。
注意：
在系统方案模板中，此处的单板软件被统称为“软件子系统”，该“子系统”（按业务按纵向划分）的概念比我们熟悉的诸如“OSS子系统”、“DBS子系统”更广泛，“OSS子系统”、“DBS子系统”（横向即分层划分）等是通过软件概要设计设计出来的，并体现在《软件总体设计方案》中。
2）对于纯软件项目，SRS是根据研制任务书、标准/协议/规范、原始需求说明书开发出来的。
一般说来，只写一篇SRS是比较合适的。
c）SRS编写到什么程度才算完成？
比较通行的原则是：
1）如果设计与开发人员需要SRS的作者额外的解释才能理解需求，并进而进行设计和实现，则在继续工作前，需求还需要进一步细化。
2）如果（软件）系统测试人员需要SRS的作者额外的解释才能理解需求，并进而编写（软件）系统测试规程/测试用例，则在继续工作前，需求还需要进一步细化。
d）在概要甚至详细设计前怎么能描述功能需求的正常过程呢？
1）首先要明确，软件需求描述的是“被描述系统”（如整个软件或某个软件子系）对外提供的功能、性能、质量属性、外部接口等，可以将“被描述系统”看成一个黑盒（如果在需求描述的过程中，涉及到了“被描述系统”内部的组成，则可以认为该描述不满足要求。
当然，也有些例外情况。
如对于网管这种已经很成熟的软件，在描述需求时，可以按终端与服务器分别进行描述）。
而概要设计是对“被描述系统”内部组成及其相互关系进行设计，此时，“被描述系统”是一个白盒。
2）功能需求的过程描述是对完成功能的操作/执行步骤（而不是具体的内部实现流程）进行描述，一方面为后续设计提供基本的处理流程，另一方面（更为重要）在描述正常过程、可选过程及异常过程（后两个过程在以往的实践中经常需要到详设、甚至编码时才能部分确定）的过程，揭示各种数据项（详细定义于数据字典中）及业务规则（如数据合法性、一致性、匹配等）。
3）除了设计和实现上的限制及标准化相关需求外，SRS只描述软件“做什么”，不应该包括设计、构造、测试或工程管理的细节。
而概要设计是讲“如何做”才能满足“做什么”。
编制SRS时，应考虑以下情况：
a）在编制SRS前，应熟悉软件需求说明书评审检查单。
在编制过程中应注意避免出现检查单中所列的常见问题。
b）如果不能保证与上游文档间的追踪关系，则SRS的编制就是失败的，同行评审将不能关闭（甚至可以将这个要求列入同行评审的准入条件）。
因此，对于SRS的作者来说，应将需求追踪放到足够重要的位置。
作为检查的手段之一，在提交SRS进行同行评审前，作者应先进行需求追踪。
c）对于需求主要由协议/标准/规范规定的软件，在编制SRS时，为了准确、完整描述需求，同时为减少文档的规模，可以采用“引用”的方法（建议句式为“……见……”），但“引用”应完整，读者能方便、快速地找到目标内容。
这就要求引用时应列出协议/标准/规范名称、篇/章节号（如果不是整节引用，还应列出“开始页号及行号、结束页号及行号”）。
如果是不完全引用，应明确说明并指出异同。
注意：
此处未要求列出具体版本，“协议/标准/规范”的版本信息在“执行标准”中统一列出，这样可避免同时引用一份“协议/标准/规范”的多个版本。
这也意味着，一旦“协议/标准/规范”发生变更，所有的引用可能都得修改。
本条要求同样适用于对文件的引用。
d）为了更好地使用需求追踪工具RequisitePro（以下简称RP）进行需求追踪，在描述需求时应注意图与表格的使用。
1）图可以是Word图（此处图是指插入的“对象”）、PaintBrush图、PowerPoint图、Visio图等，但应是“嵌入型“的，而不能是“浮于文字上方”等其它形式。
同时，应尽可能将图插在需求描述的中间，这样当图发生变化时，就可以通过在图前或图后加减空格，使得RP知道需求发生了变化。
2）由于RP只能识别整表或一个一个的单元格，因此，一条需求要么只占一个单元格，要么占满整表。
编制本文档时，容易犯的错误有：
a）不顾文档上下游之间的关系，先编写设计方案，然后（有些项目拖得非常后）再编写本文档。
这种做法是不对的，容易导致几个问题。
一是在没有确定做什么（需求）的情况下就去描述怎么做（设计），极易导致返工。
二是在需求文档中大段大段地描述如何设计与实现。
三是在已有设计文档的情况下，写需求文档被认为是炒冷饭，因此不愿意再完整编写。
b）认为只有在详细设计时才可能把处理过程写清楚。
甚至认为功能需求根本无需描述处理过程，因为那是详细设计要做的事。
这种认识无疑是错误的。
因为，用户是通过与软件（系统）交互来完成其任务的，如果设计与实现的交互过程与用户要求或想象的不一致，则用户就会认为软件（系统）不好。
因此，交互过程应最大限度地被满足，应该尽早在需求说明书中描述。
另外，可选、异常及业务规则（如“只有经理级人员才可查看成本价”）都隐藏于交互过程中，在需求开发过程中，如果没有描述交互，则很可能遗漏可选、异常及业务规则。
c）在一段中描述若干条需求，或将若干需求合并在一条需求中描述（常见于“性能需求”的描述中）。
这种写法比较难以阅读，进行需求追踪时捕获需求也不是很方便。
d）对于非功能需求（如性能、质量属性需求等），只定性描述（如系统要稳定、CPU占用率低）。
这样的描述无法验证。
应该定量描述，且还应描述对应的条件。
本模板在格式上有以下一系列约定：
a）用“<>”括起来的内容，是编写指导，在使用本模板编制的文档中应予以删除或去掉“<>”后予以适当沿用。
b）本模板提供的示例，格式上都采用整行的“<===ExampleBegin==…”和“====ExampleEnd==…==>”框起来，同时还会给例子一个编号和名称，以方便阅读与引用。
c）为了方便模板使用者删除，对<>内的所有编写指导文字都使用蓝色，但<>本身保持黑色。
同时，由于示例部分可能会被模板的使用者直接沿用，因此仍然使用黑色，（即“<===ExampleBegin==…”和“====ExampleEnd==…==>”、或者其它如表格中的例子用黑色）。
但如果示例中又插入了一些指导说明文字，则这些文字必须用蓝色。
d）如果某章节内容无需填写，而且本模板又没有特殊要求或说明，则在该章节下写“无”，而不要将该章节删除或不填写任何内容（即留白。
留白将使评审员或读者无法判断：
是本章节内容无需填写还是因为疏忽而忘了填写？
）。
1
引言
1.1编写目的
本文通过详细描述软件的功能需求、性能需求、质量属性需求、外部接口需求以及其它需求，为后续概要设计、软件（系统）测试、用户文档等工作提供基础与约束。
1.2预期的读者和阅读建议
预期的读者和阅读建议参见表1.1。
表1.1
读者分类
阅读重点及目的
备注
<项目经理
全文，并据此编制/修订项目（软件）开发计划等。
设计与开发工程师
需求的完整性、正确性、可行性、优先级、无二义性，为概要设计作准备。
市场工程师/客户代表
需求的必要性、优先级，并据此准备市场资料。
测试工程师
需求的可验证性，并据此准备（软件）系统测试方案。
文档工程师
全文，为编写用户文档作准备。
>
1.3文档约定
<本节描述编写文档时所采用的排版约定（如正文风格、重要符号），说明需求优先级的取值及其含义等。
应将每一类内容用一段或若干段进行描述，即应避免在一段中描述所有这些内容。
>
<===ExampleBegin====================================================
例文档约定
本文使用了如下的文档约定：
1）表头文字使用4级灰度背景；
2）插图一律使用MSVisio2003中文版绘制，并一律“嵌入”于需求描述正文中，而非“浮于文字上方”。
；
3）用同号、同体但加粗的文字来强调需要读者重视的内容。
4）采用用例（usecase）技术对功能需求进行描述。
另外，每个需求都有优先级属性。
优先级的可能取值为：
5、4、3、2、1，具体定义如下：
5：
是必须的，它规定了系统/软件的必备功能。
没有这些功能，系统/软件将不能完成用户的工作，从而也就无法达到市场的准入条件。
4：
是重要的，它规定了那些竞争对手已经实现且用户感觉很好的功能、本系统/软件区别于其它同类系统/软件的独特功能及其它一些功能。
只有完成这些功能，才能使本系统/软件有市场竞争力。
3：
是应该的，它规定了当前版本可以不做,但必须在未来版本中实现的功能。
此种需求对系统/软件的体系结构影响可能较大，因此必须在系统分析及设计时予以考虑。
2：
是可能的，它规定了那些有了会更好但没有也没有什么关系的功能，如一些提高效率的小工具。
1：
是备忘的，它规定了我们想象的但目前无法或无需实现的需求。
====ExampleEnd====================================================>
2术语、定义和缩略语
2.1术语、定义
本文使用的专用术语、定义见表2.1，通用术语、定义见<文件编号>《术语、定义和缩略语》。
表2.1
术语/定义
英文对应词
含义
<需求追踪记录
requirementtracerecord
表示需求之间及需求和其它工作产品元素之间相互关联关系的文档，可利用字处理工具、表格工具、数据库工具或专用需求管理工具建立和维护。
工作产品元素
workproductelement
工作产品的单元性的构成，如：
用例、需求、设计单元、函数、测试用例、用户手册章节等>
2.2缩略语
本文使用的专用缩略语见表2.2，通用缩略语见<文件编号>《术语、定义和缩略语》。
缩略语已按其第1个字母顺序排列。
<注意：
缩略语应按其第一个字母顺序排列>
表2.2
缩略语
英文原文
中文含义
messagesequencechart
消息序列图
SRS
softwarerequirementspecification
软件需求规格，又叫软件需求说明书>
3
综合描述
3.1背景
<说明：
一般说来，SRS中应有项目范围的描述，而项目范围一般通过项目视图并最终通过业务需求来体现。
我司不管哪种类型的项目，总要首先编写《研制任务书》，将业务需求、项目视图、范围写在《研制任务书》中是最合适的。
因此，SRS中不反映这部分内容。
>
<本节主要描述以下内容：
a）系统的背景和起源。
重点说明该系统是否是产品系列中的下一成员、是否是现有应用的替代品，或者是否是一个新型的、自含型产品。
对于在老版本之上升级的系统，则还应说明：
1）老版本出现的主要问题；
2）新版本需要增加或改进的主要内容。
此段内容可能来自于可行性研究报告等上游相关文档。
应该对相关内容进行概括而不是照抄，篇幅一般应控制在5个自然段之内。
b）本系统在整个系统或整个环境中的位置。
必须使用上下文图（contextdiagram）或高层用例图说明本系统（必须用文字及不同的颜色明确标识出来）与外界（可能包括整个系统外的实体）之间的联系，如图3.1。
上下文图能清晰地表达系统与外部环境的边界，及系统与外部环境的关系，帮助读者更好、更快地理解被描述的系统。
实践中经常犯的错误是：
1）不画图；
2）画了系统内部组成图或协议栈；
3）在上下文图中，还描述了外部系统之间关系。
图3.1“化学制品跟踪系统”上下文图
>
<===ExampleBegin====================================================
例背景
网管软件需要管理两种网元：
一种是ANU，一种是ICSC。
两种网元不同之处在于前者用的是A型机平台，后者用的是B型机平台。
两者的操作方式差异很大：
ANU的操作以字符人机命令为主；ICSC的操作命令基本上已实现图形化。
对于用户来说，需要在一个网管软件上实现对这两种网元的统一处理。
本文即描述了统一管理ANU和ICSC的网管软件的需求。
图3.2描述了本网管软件的上下文图（Contextdiagram）。
图3.2上下文图
本网管软件与外界的联系见图3.2的文字说明。
<如图中没有描述这种联系，则应在此处用文字单独、简要描述。
>
====ExampleEnd====================================================>
3.2功能概述
<本节概述软件所具有的主要功能（如果需要，也可描述性能等需求）。
由于其详细内容将在“具体需求”中描述，因此此处需要以较高的层次（如需求组）对需求进行概括性的总结，直接罗列“4.1功能需求”中的所有需求（如用一个表格）并不是一个好主意，因为这会引起内容冗余以致引起维护问题，还会增大文档篇幅。
可以使用图形表示主要的需求组以及它们之间的关系。
为什么要这样做呢？
因为一般的软件需求说明书的规模都较大，上百页甚至数百页的规模都比较常见，如果在文档的开头没有对软件完成的主要功能进行介绍的话，读者只有在通读完所有内容后才能知道软件是干什么的，这就会影响读者的阅读情绪并进而影响阅读效果。
本节示例中的规划大师PlanMaster（V2）共有上百个比较重要的功能，但在进行功能概述时只在功能组这一级罗列（只有8行），任何具体功能都可归结到这8个功能组中，因此满足了覆盖具体需求的要求。
同样，用户需求也未游离于这8个功能组之外，因此也覆盖了其上游文档《系统需求论证说明》（规划大师是纯软件项目）。
>
<应注意避免本节易犯的三个主要错误：
a）写得过于详细，而后面的“具体需求”则写的不完整（如“输入”、“处理”不是写“略”就是写“无”）。
b）不能覆盖“4.1功能需求”中的内容。
c）不能与上游文档如《系统方案》中描述的软件功能相对应（对于软硬件大系统）。
>
<===ExampleBegin====================================================
例功能概述
本软件具备以下主要功能：
a）工程及设计管理；
b）用于移动通讯领域的地理信息系统；
c）数据管理（如设计参数、天线、传播模型、测试数据、基站小区等）；
d）网络规划与分析（如基站小区规划、频率规划、覆盖干扰分析、话务分析等）；
e）网络模拟（如小区选择、重选、切换等模拟）；
f）网络优化（如话务均衡、手机测试数据的统计分析、OMC-R性能测量数据的统计分析等）；
g）视图管理（提供各种相关数据、分析结果的显示等功能）；
h）实用及辅助工具（提供报告生成、两点间信息查看等功能）。
====ExampleEnd====================================================>
3.3运行环境
<本节描述软件的运行环境，包括硬件环境、操作系统及其版本，还有其它的软件组件或与其共存的应用程序。
如果有版本配合要求、补丁要求，则应明确列出（如使用Windows98，则Office可以使用97及其以上版本，如使用Windows2000，则应打上SP2，且Office只能使用2000版本且应打上SP1）。
如不存在某项，则填写“无”，不要留白。
如果对开发环境有要求，可以写在“4.5.2.设计与实现的限制”一节中。
>
运行环境见表3.1。
表3.1
名称
硬件（CPU/RAM/HD）
操作系统及其版本
其它软件环境
<
MMSP
PIII700/1G/18G
WindowsNT4Server
Oracle8i
DBServer
SPARC/1G/18G
SUNSolarisX
Oracle8i
BillServer
SPARC/1G/18G
SUNSolarisX
Oracle8i>
3.4用户类及其要求
<本节描述本软件的不同用户类并描述他们相关的特征。
应根据用户使用软件的频度、应用领域和计算机系统知识、需要完成的任务、地理上的布局以及访问优先级等对用户进行分组。
不同的用户类其需求是不同的，某些用户类的需求可能更加重要，需要优先考虑。
本节内容对后续的设计会产生一定的约束与限制。
每一个用户类都有自己的一系列功能和非功能需求。
如：
一个没有经验或偶尔使用电脑的用户关心软件是否简单易用，因此，菜单、提示符和向导是很重要的。
然而，对于那些一天使用几小时软件的用户，他们更关心软件的易用性和高效性，所以他们喜欢使用快捷键、宏以及脚本功能（scriptingfacility）。
有一些受软件影响的人并不一定是软件的直接使用者，而是通过报表或其它应用程序访问本软件的数据和服务。
这些非直接的或次级（secondary）的用户也有自己的需求，可以将这些人加入“附加的用户类”。
用户类不一定都指人，其它应用程序或系统接口所用的硬件组件也可看成是附加用户类的成员。
以这种方式来看待应用程序接口，可以帮助确定软件中那些与外部应用程序或组件有关的需求。
在项目中，要尽早为项目确定并描述出不同的用户类，这样，就能从每一个重要的用户类代表中获取不同的需求。
>
<===ExampleBegin====================================================
例用户类及其要求
本软件的用户分两类。
一类为普通用户，一类为系统管理员。
普通用户为电信运营商的操作维护人员，一般具备计算机操作和unix、Windows操作系统的基础知识；熟悉SDH、WDM和数据传输系统基本原理。
系统管理员负责管理本软件。
一般具备网络维护及管理、数据库维护及管理方面的知识，对中间件技术（如CORBA）也应该有一定的了解。
====ExampleEnd====================================================>
4
具体需求
<本章描述功能需求、性能需求、质量属性需求、外部接口需求及其它需求。
我们规定：
a）功能需求编号的前缀为SR-F（F表示功能）；
b）性能需求编号的前缀为SR-P（P表示性能）；
c）质量属性需求编号的前缀为SR-Q（Q表示质量）；
d）外部接口需求编号的前缀为SR-I（I表示接口）；
e）其它需求编号的前缀为SR-M（M表示杂类）。
需要说明的是，如果一个项目有多篇SRS，假定划分的粒度是子系统，则其编号前缀应改为：
“SR-”+“子系统名”+“-”+“需求类别（如F、P、Q、I、M）”，如SR-DB-F。
如果需求是分组描述的，则还要在“需求类别”后再加上需求组，如SR-DB-F-G1。
无论如何，应保证需求编号在项目中的唯一性。
在编写本章时，还应注意以下问题：
a）如果项目被要求编写数据字典，则应在项目的早期（如项目论证阶段）就编写数据字典，以定义相关的数据元素和结构（如输入、输出、存储或数据表字段等，一般与功能、内外部接口等相关）的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围。
需求描述中的输入项可以直接引用数据字典的数据项。
数据字典应独立维护。
b）无论是需求编号还是需求内部描述的步骤号，都应手工编号，而不要使用编辑器的自动编号。
因为如果采用自动编号，一旦增加或删除中间的某个编号，将会引起其后所有需求的RP记录的变更，并影响处理过程中的引用关系。
c）需求优先级的设置应基于上游文档中相关内容的优先级，一般应不比上游的低。
d）本文档中不得描述需求的实现版本信息。
需求实现的版本信息应体现在两个地方：
一是项目计划中；二是需求追踪工具RP中的需求属性：
实现版本。
在阅读以下内容时，如果结合《软件需求说明书评审检查单》，将能取得更加好的效果。
好的单条需求的描述应具有以下特征。
摘自《软件需求》第1.5节，KarlE.Wiegers
a）完整性。
每一项需求都必须将所要实现的功能描述
升级会员 