软件需求说明书-模板.doc

研制令号日期项目软件需求说明书(该文档仅供内部参考)负责单位:研发部门名称协作单位:协作单位名称(如有)作者:研发人员签名批准:总工程师签名修改及签收情况记录:版本号修改人修改日期修改批准人部门资料室签收研发人员签名研发部门主任签名部门资料员存档签名**********股份有限公司修改记录文件编号版本号拟制人/修改人拟制/修改日期更改理由主要更改内容(写要点即可)<>注1:每次更改归档文件(指归档到事业部或公司档案室的文件)时,需填写此表。注2:文件第一次归档时,“更改理由”、“主要更改内容”栏写“无”。<模板修改记录文件编号版本号拟制人/修改人拟制/修改日期更改理由主要更改内容(写要点即可)***2013-12-23初版>目录1 引言 编写目的 预期的读者和阅读建议 文档约定 72 术语、定义和缩略语 术语、定义 缩略语 83 综合描述 背景 功能概述 运行环境 用户类及其要求 114 具体需求 功能需求 <需求编号1+两个空格+需求名称1(usecase例)> <需求编号2+两个空格+需求名称2(IPO例)> 性能需求 <需求组1编号+两个空格+需求组1名称> <需求编号2+两个空格+需求名称2> 质量属性需求 可靠性 安全性 可维护性 可移植性 扩展性 可测试性 外部接口需求 其它需求 通用化、系列化、模块化需求 设计和实现上的限制 执行标准 国际化需求 杂类需求 425 需求追踪 436 验收准则 437 参考文献 44<术语说明:需求:是指“被描述系统”“做什么”(功能需求)及“做什么”时的水平(非功能需求,如性能需求、质量属性需求、外部接口需求、其它需求)。软件需求:由软件实现的需求。包括功能需求、性能需求、质量属性需求、外部接口需求及其它需求。软件需求说明书(softwarerequirementspecification,SRS):是这样一类文档,它以特定的格式记载了软件必须实现的所有软件需求(又叫软件需求规格、软件需求规格说明),在必要时,也应描述软件肯定不做什么(何谓必要?在某些上下文语境中,如果不作这样的声明,可能会令读者发生误会)。SRS为后续的项目软件计划、概要设计、(软件)系统测试、用户文档等工作提供基础与约束。编制SRS时经常被问到以下问题:实践中出现了不少这样的情况:明明要求写软件需求说明书,但结果写出了模块需求说明书。这实际上反映了这些实践未正确确定“被描述系统”。那么,如何确定“被描述系统”呢?在编写SRS前,一定要明确“被描述系统”,该系统应是上游文档中已经明确划分出来的;同时应将“被描述系统”作为黑盒(特殊情况下可以是灰盒甚至是白盒,如网管软件,可以按终端、服务器)来描述。对于纯软件项目,很显然,由于SRS的上游文档-研制任务书-没有对软件进行划分,因此,SRS中“被描述系统”应该是整个软件,而不是其中的某个模块。对于软硬件大系统,一般通过系统设计活动,SRS的上游文档-系统方案-已经对系统进行了划分,因此,SRS中“被描述系统”可以是划分出来的任何一个软件块。应该编写几篇SRS?对于软硬件大系统,SRS是根据系统方案、标准/协议/规范、研制规范、原始需求(其中可能直接含有功能需求、性能需求、质量属性需求、外部接口需求、其它需求)开发出来的。根据系统的复杂程度,可以编制一到多篇SRS。如果SRS的上游文档(系统方案)满足其编制要求,则可以为每个单板的软件部分(如果该单板存在软件的话)写一篇SRS。注意:在系统方案模板中,此处的单板软件被统称为“软件子系统”,该“子系统”(按业务按纵向划分)的概念比我们熟悉的诸如“OSS子系统”、“DBS子系统”更广泛,“OSS子系统”、“DBS子系统”(横向即分层划分)等是通过软件概要设计设计出来的,并体现在《软件总体设计方案》中。对于纯软件项目,SRS是根据研制任务书、标准/协议/规范、原始需求说明书开发出来的。一般说来,只写一篇SRS是比较合适的。SRS编写到什么程度才算完成?比较通行的原则是:如果设计与开发人员需要SRS的作者额外的解释才能理解需求,并进而进行设计和实现,则在继续工作前,需求还需要进一步细化。如果(软件)系统测试人员需要SRS的作者额外的解释才能理解需求,并进而编写(软件)系统测试规程/测试