需求说明编制指南全解
软件需求规格说明编写指南
密级：（软件项目名称）软件需求规格说明标识：版本：页数：拟制：SQA审核：审核：批准：拟制部门：年月日修改文档历史记录：日期版本说明修改人目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)2 引用文档 (1)3 需求 (1)3.1 要求的状态和方式 (1)3.2 CSCI能力需求 (4)3.2.X（CSCI能力） (4)3.3 CSCI外部接口需求 (5)3.3.1 接口标识和接口图 (5)3.3.X（接口的项目唯一的标识符） (5)3.4 CSCI内部接口需求 (8)3.5 CSCI内部数据需求 (9)3.6 适应性需求 (9)3.7 安全性需求 (9)3.8 保密性需求 (10)3.9 CSCI环境需求 (10)3.10 计算机资源需求 (10)3.10.1 计算机硬件需求 (10)3.10.2 计算机硬件资源使用需求 (11)3.10.3 计算机软件需求 (11)3.11 软件质量因素 (11)3.12 设计和实现约束 (12)3.13 人员需求 (12)3.14 培训需求 (12)3.15 后勤保障需求 (12)3.16 其它需求 (12)3.17 验收、交付和包装需求（修改有关内容） (12)3.18 需求的优先顺序和关键程度 (13)4 合格性规定 (13)5 需求可追踪性 (13)6 注释 (14)1 范围1.1 标识【本条应描述本文档所适用的系统和软件的完整标识，适用时，包括其标识号、名称、缩略名、版本号及发布号。
】示例：系统标识如下：a)已批准的标识号：b)产品名称：XXXXXXc)产品代号：XXXXXXd)版本号：XXXXXe)缩略名：1.2 系统概述【本条应概述本文档所适用的系统和软件的用途。
它还应描述系统与软件的一般特性；概述系统开发、运行和维护的历史；标识项目的需方、用户、开发方和保障机构；标识当前和计划的运行现场；列出其它有关文档。
需求规格说明书(仅用于学习的参考模板)
数字化绩效需求规格说明书1引言1.1编写目的项目需求说明书是系统生存周期中开发阶段的一个重要步骤。
是作为整个系统开发范围的指南，是系统开发人员描绘出正确的符合用户要求的系统的重点。
为了明确客户的基本需求，更好地完成对客户需求了解，并量化和明晰本系统的工作量和工作进度，特编写此需求规格说明书。
此说明书始终贯穿于整个项目开发的过程，并决定着开发的整体框架，也是系统实现功能的指引说明。
1.2术语定义2综合描述2.1系统的功能（1）XXXX管理系统XXXX管理系统是推进市直机关及县（市、区）绩效管理体系创新，是在自治区免费提供的基础云应用平台上扩展建设而成的，能全面实现各XXXX考评工作网络化在线管理，大幅度提高绩效考评工作效率：实现战略目标展示、XXXX考评指标设定、修改和查看管理功能；实现工作计划、工作纪实、总结、过程XXXX、亮灯预警等绩效过程管理功能；支持在线开展年度绩效考评；导（录）入外部考评结果和外部评价结果，实现考评成绩自动计算；实现绩效考评结果统计分析、方便快捷查询与展示功能，构建XXXX档案。
（2）XXXX管理系统XXXX管理系统主要包含实现对会议决定事项、领导批办事项、上级交办事项和重大工作事项等分类全过程XXXX管理，包括XXXX事项分解拟定、审核与下达、XXXX、反馈进度、跟踪预警、XXXX报告和统计汇总等全过程环节管理。
（3）XXXX管理系统XXXX管理系统满足在线开展部门互评、领导评价、公众评议等工作，在设计上要具备充分的灵活性，可自由设置打分选项、配置测评表内容、配置测评对象以及生成测评账号，要具有完善的评价管理功能，实时汇总、监控评价开展情况，收集各个测评主体对测评对象的意见建议等，建立一个学、高效、简便、可视化的考核评价工作平台，提高考核评价数据采集的实时性、便捷性和准确性。
（4）XXXXX小程序XXXXX是借助信息化的手段，提升核验执行效率与覆盖面。
手机移动XXXX（含察访核验）是以XXXX管理系统为基础，全新设计开发的应用系统，XXXX对XXXX 管理系统功能进行提炼和整合，充分发挥移动设备方便快捷、可拍照、GPS定位等优势，实现重大工作完成情况快捷填报、证明材料上传，充分利用手机GPS功能确保证明图片的真实性、实效性，避免了传统的现场核验工作量，提高了工作效率，节约了监督成本。
软件文档国家标准与写作要求
软件文档的编写原则
所有的章节都可以进一步细分或缩并，以适应实际需要。
程序的设计表现形式可以使用多种形式，如流程图、判定表、等其 他表现形式。
按规定：重量不超过30公斤的行李可免费托运。重量超过30公斤时， 对超运部分，头等舱国内乘客收4元/公斤；其它舱位国内乘客收6元 /公斤；外国乘客收费为国内乘客的2倍；残疾乘客的收费为正常乘 客的1/2。
（6）详细设计说明书
（7）数据库设计说明书
本指南不仅给出了这十四种文档的编制指导，同时，本指南也是这十四种文 档编写质量的检验准则。
2、软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南
软件需求说明编制指南为软件需求的实践提供了一个规 范化的方法，主要描述了软件需求说明（Software Requirements Specifications，简称SRS）所必须的内容 和质量。
软件需求标准适用范围
1. 指南适用对象 软件客户（Customers），以便精确地描述他们想获得什么样的产品。 软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。 2. 指南目的 对于任一单位和（或）个人，要实现下列目标： a. 要提出开发规范化的SRS提纲； b. 定义自己需要的具体的格式和内容； c.产生附加的局部使用条款，如SRS质量检查清单或者SRS作者手册等。
实例
4、软件文档管理指南
软件文档管理指南
软件文档管理指南是为那些对软件或基于软件的产品的开发负有职 责的管理者提供软件文档的管理指南。其目的在于协助管理者在他 们的机构中产生有效的文档。
（1）软件文档管理涉及策略、标准、规程、资源和计划，管理者必 须关注这些内容，以便有效地管理软件文档。 （2）软件文档管理期望应用于各种类型的软件，从简单的程序到复 杂的软件系统。并期望覆盖各种类型的软件文档，作用于软件生存 期的各个阶段。 （3）不论项目的大小，软件文档管理的原则是一致的。对于小项目， 可以不采用本标准中规定的有关细节。管理者可剪裁这些内容以满 足他们的特殊需要。 （4）软件文档管理是针对文档编制管理而提出的，不涉及软件文档 的内容和编排。
[计算机软件产品开发文件编制指南]GB8567-88
![[计算机软件产品开发文件编制指南]GB8567-88](https://img.taocdn.com/s3/m/f66c638e04a1b0717fd5ddf5.png)
引言1 目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。
一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。
为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。
这些文件连同计算机程序及数据一起，构成为计算机软件。
文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志；b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。
以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。
换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。
计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。
本指南规定软件文件的编制形式，并提供对这些规定的解释。
本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。
2 范围本指南是一份指导性文件。
本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。
这十四种文件是：可行性研究报告；项目开发计划；软件需求说明书；数据要求说明书；概要设计说明书；详细设计说明书；数据库设计说明书；用户手册；操作手册；模块开发卷宗；测试计划；测试分析报告；开发进度月报；项目开发总结报告。
本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。
设备用户需求说明URS编制管理规程
目的：建立设备用户需求说明(URS)编制管理规程，规范设备用户需求说明的编制，准确定义待购设备的预定用途，确保所购设备符合要求。
范围：适用于公司拟购置关键设备、仪器仪表等用户需求说明的编制管理。
职责：设备管理部负责本规程的起草、修订、审核，质量管理部负责本规程的审核，生产管理负责人、质量管理负责人负责本规程的审批。
规程：1用户需求说明(URS)定义：URS是使用方对厂房、设施、设备或其他系统提出的要求及期望，至少包含一系列接受标准或必须符合的条件。
2用户需求说明(URS)编制的意义：建立设备用户需求说明，有助于用户深入梳理自身需求，准确完整说明预定用途，更好的实现技术先进、经济合理、生产实用的设备购置目标。
是设备采购选型调研的基准，是供应商完成设计说明（DS, design specification）的重要输入条件，是用户进行设计审核（DR, design review）或设计确认（DQ, design qualification）的依据，也是后续确认，尤其是性能确认（PQ, performance qualification）的接受标准。
3URS编制原则3.1凡是直接影响产品质量的、关键的、主要的、特殊的复杂设备或仪器仪表都应该编写完整的URS文件，简单的设备仪器仪表URS可相对简化。
3.2与产品质量无影响设备可不编制URS：如三废”处理等项目；锅炉房、配电室、消防设施、通讯设施；工业蒸汽系统、厂区供电系统、消防报警系统；发电机、冷水机组等设备；简单的标准设备、工具、容器。
3.3简单设备、标准设备的URS编制，以URS相关编制内容为基准，可适当简化编制内容，达到URS编制目的即可。
3.4 URS文件的起草以需求部门为主导，设备、工程部门、QA等部门进行完善与补充。
使用部门、设备管理部、QA审核，生产管理负责人、质量管理负责人批准后生效。
3.5 URS起草前由需求部门组织工艺技术人员、设备操作人员、设备维护保养人员在完成《系统风险评估报告》的基础上，分清主次、抓住要点，深入透彻分析预定用途、功能要求，再清晰、准确、完整的起草URS。
方案类编制说明
方案类编制说明方案类编制是一类针对特定问题或任务制订的可行性解决方案，需要根据具体要求进行制定。
本文将介绍方案类编制的相关指南、步骤和要求。
指南制定目的制定方案的首要目的是明确问题或任务，并制定出符合要求的、可行的解决方案。
方案制定需要考虑实际情况和资源投入，达到最优解决方案。
基本原则在方案编制的过程中，需要遵循一些基本原则：1.充分调查和分析：在制定方案前，必须充分了解任务目标、现状和可行性，对可能的问题进行深入分析。
2.确保可行性：制定出的方案必须要具有实际可行性和可操作性。
方案要充分考虑资源有限性、技术条件、环境因素、风险预估等多方面因素。
3.经济效益：所制定的方案要符合经济效益，在可行性情况下，要选用经济性比较好、成本合理的方式解决问题。
4.可操作性：方案执行过程中要遵循操作性原则，确保对于各项任务的实现能够达到预期目标。
步骤和要求方案类编制包含以下步骤：1.问题确认：明确任务目标，准确理解需求。
2.调查分析：对所面临的问题，进行问题调查，数据采集和分析，制定对应解决方案。
3.解决方案设计：明确方案目标、方案基本构成、技术方案、资源需求和实施步骤等。
4.方案评估：对所制定的方案进行评估，考虑实际效果、涉及成本、资源消耗以及安全风险等。
5.方案推广：“推广”即方案的推广和宣传。
在方案执行过程中及时调整方案，确保方案实现目标。
方案编制需要遵循的要求：1.方案编制人员应具备适当的专业知识、技能和实践经验。
2.制定方案应遵循法律法规和相关规范要求。
3.方案编制人员需时刻保持清醒头脑，对方案进行评估、修正和优化。
4.经制定的方案必须属于实际可行的解决方案，并能够有效、高效地解决问题。
结论方案类编制是一项重要的工作，目的就是解决问题、实现目标，提高效率。
编制过程需包括调查分析、解决方案设计、方案评估和方案推广等步骤，需要一定的基础和经验。
只要严格按照要求实施，才能得到质量上乘、效益优良、符合管理标准的解决方案。
(完整word版)需求规格说明书模板全解
####项目需求规格说明书(模板)公司二〇一五年十月文档修改记录目录第一章引言 (1)1.1编写目的 (1)1.2文档范围 (1)1.3项目概要 (1)1.4术语和缩写 (1)1.5参考资料 (1)1.6文档编写格式 (2)第二章任务概述 (3)2.1目标 (3)2.2用户的特点 (3)2.3假定和约束 (3)第三章系统运行环境 (4)3.1系统架构 (4)3.2系统硬件和网络环境 (4)3.3系统运行平台 (4)3.4系统界面描述 (4)3.5接口 (4)第四章功能描述 (5)4.1对功能的规定 (5)4.2功能性需求分类 (5)4.2.1功能总图 (5)4.2.2功能描述表 (5)4.2.3功能详细描述 (5)4.3对非功能的需求 (5)4.3.1系统参数及系统精度 (5)4.3.2灵活性 (6)4.3.3时间管理特性 (6)4.3.4输人输出要求 (6)4.3.5数据管理能力要求 (6)4.4故障处理要求 (6)4.5其他非功能需求 (7)第一章引言1.1编写目的提示：说明编写这份需求说明书的目的。
需求说明书编写的目的是为了记录、整理用户对学生工作管理的业务流程和功能需求，描述用户对系统的期望和功能要求。
本文档尽量以自然语言来描述，以期用户和潜在读者能够快速理解，并方便与用户进行沟通。
1.2文档范围提示：需要描述清楚文档传播范围和读者对象。
1.3项目概要提示：描述系统相关信息。
a．待开发系统(或软件)的名称；b．本项目的任务提出者、开发者、用户及实现该系统的部门或单位；c．该项目系统同其他系统或其他机构的基本的相互来往关系。
1.4术语和缩写提示：列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.5参考资料提示：列出用得着的参考资料，如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料、包括所要用到的系统开发标准。
GB 9385-88需求说明编制指南
计算机软件需求说明编制指南GB 9385-88介绍1引言1．1目的和作用本指南为软件需求实践提供了一个规范化的方法。
本指南不提倡把软件需求说明Software Requirements Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。
本指南适用对象：软件客户（Customers），以便精确地描述他们想获得什么样的产品。
软件开发者（SuPPliers），以便准确地理解客户需要什么样的产品。
对于任一要实现下列目标的单位和（或）个人：a．要提出开发规范化的S RS提纲；b．定义自己需要的具体的格式和内容；c．产生附加的局部使用条款，如S RS质量检查清单或者S RS作者手册等。
S RS将完成下列目标：a．在软件产品完成目标方面为客户和开发者之间建'立共同协议创立一个基础。
对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否S符合他们的要求，或者怎样修改这种软件才能适合他们的要求；b．提高开发效率。
编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。
在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；c．为成本计价和编制计划进度提供基础。
SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。
SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；d．为确认和验证提供一个基准。
任何组织将更有效地编制他们的确认和验证计划。
作为开发合同的一部分，S RS还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为S RS。
因为这种文件几乎不包括详尽的需求说明，并且、通常是不完全的）；e．便于移植。
有了SRS就便于移植软件产品，以适应新的用户或新的机种。
客户也易于移植其软件到其他部问，而开发者同样也易于把软件移植到新的客户，f．作为不断提高的基础。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
计算机软件需求说明编制指南1 引言1.1 目的和作用本指南为软件需求实践提供了一个规范化的方法。
本指南不提倡把软件需求说明（Software Requirements Specifications，以下简称SRS）划分成等级，避免把它定义成更小的需求子集。
本指南适用对象：软件客户（Customers），以便精确地描述他们想获得什么样的产品。
软件开发者（Suppliers），以便准确地理解客户需要什么样的产品。
对于任一要实现下列目标的单位和（或）个人：a. 要提出开发规范化的SRS提纲；b. 定义自己需要的具体的格式和内容；c. 产生附加的局部使用条款，如SRS质量检查清单或者SRS作者手册等。
SRS将完成下列目标：a. 在软件产品完成目标方面为客户和开发者之间建立共同协议创立一个基础。
对要实现的软件功能做全面描述，帮助客户判断所规定的软件是否符合他们的要求，或者怎样修改这种软件才能适合他们的要求；b. 提高开发效率。
编制SRS的过程将使客户在设计开始之前周密地思考全部需求，从而减少事后重新设计、重新编码和重新测试的返工活动。
在SRS中对各种需求仔细地进行复查，还可以在开发早期发现若干遗漏、错误的理解和不一致性，以便及时加以纠正；c. 为成本计价和编制计划进度提供基础。
SRS提供的对被开发软件产品的描述，是计算机软件产品成本核算的基础，并且可以为各方的要价和付费提供依据。
SRS对软件的清晰描述，有助于估计所必须的资源，并用作编制进度的依据；d. 为确认和验证提供一个基准。
任何组织将更有效地编制他们的确认和验证计划。
作为开发合同的一部分，SRS还可以提供一个可以度量和遵循的基准（然而，反之则不成立，即任一有关软件的合同都不能作为SRS。
因为这种文件几乎不包括详尽的需求说明，并且通常不完全的）；e. 便于移植。
有了SRS就便于移值软件产品，以适应新的用户或新的机种。
客户也易于移植其软件到其他部门，而开发者同样也易于把软件移植到新的客户；f.作为不断提高的基础。
由于SRS所讨论的是软件产品，而不是开发这个产品的设计。
因此SRS是软件产品继续提高的基础。
虽然SRS也可能要改变，但是原来的SRS还是软件产品改进的可靠基础。
1.2 范围本指南适用于编写软件需求规格说明，它描述了一个SRS所必须的内容和质量，并且在第6章中提供了SRS大纲。
2 引用标准GB 8566 计算机软件开发规范GB 8567 计算机软件产品开发文件编制指南GB/T 11457 软件工程术语3 定义GB/T 11457所列术语和下列定义适用于本指南。
合同（contract）是由客户和开发者共同签署的具有法律约束力的文件。
其中包括产品的技术、组织、成本和进度计划要求等内容。
客户（customer）指个人或单位，他们为产品开发提供资金，通常（但有时也不必）还提出各种需求。
文件中的客户和开发者也可能是同一个组织的成员。
语言（language）是具有语法和语义的通信工具，包括一组表达式、惯例和传递信息的有关规则。
分割（partitioning）把一个整体分成若干部分。
开发者（supplier）指为客户生产某种软件产品的个人或集团。
在本指南中，客户和开发者可能是同一个组织的成员。
用户（user）指运行系统或者直接与系统发生交互作用的个人或集团。
用户和客户通常不是同一些人。
4 编写SRS的背景信息4.1 SRS的基本要求SRS是对要完成一定功能、性能的软件产品、程序或一组程序的说明。
对SRS的描述有两项基本要求：a. 必须描述一定的功能、性能；b. 必须用确定的方法叙述这些功能、性能。
4.2 SRS的环境必须认识到SRS在整个软件开发规范（见GB 8566）所规定的有关阶段都起作用。
正因为如此，SRS的起草者必须特别注意不要超出这种作用的范围。
这意味着要满足下列要求：a. SRS必须正确地定义所有的软件需求；b. 除了设计上的特殊限制之外，SRS中一般不描述任何设计、验证或项目管理细节。
4.3 SRS的特点4.3.1 无歧义性当且仅当它对每一个需求只有一种解释时，SRS者是无歧义的。
a. 要求最终产品的每一个特性用某一术语描述；b. 若某一术语在某一特殊的行文中使用时具有多种歧义，那么对该术语的每种含义作出解释并指出其适用场合。
需求通常是用自然语言编写的，使用自然语言的SRS起草者必须特别注意消除其需求的歧义性。
提倡使用形式化需求说明语言。
4.3.2 完整性如果一个SRS能满足下列要求，则该SRS就是完整的：a. 包括全部有意义的要求，无论是关系到功能的、性能的、设计约束的，还是关系到属性或外部接口方面的需求；b. 对所有可能出现的输入数据的响应予以定义，要对合法和非合法的输入值的响应做出规定；c. 要符合SRS要求。
如果个别章节不适用，则在SRS中要保留章节号；d. 填写SRS中的全部插图、表、图示标记和参照，并且定义全部术语和度量单位。
4.3.2.1 关于使用“待定”一词的规定任何一个使用“待定”的SRS都是不完全的。
a. 若万一遇到使用“待定”一词时，作如下处理：（1）对产生“待定”一词的条件进行描述，使得问题能被解决；（2）描述必须干什么事，以删除这个“待定”；b. 包含有“待定”一词的任何SRS的项目文件应该：（1）标识与此特定文件有关的版本号或叙述其专门的发布号；（2）拒绝任何仍标识为“待定”一词的SRS章节的许诺。
4.3.3 可验证性当且仅当SRS中描述的每一个需求都是可以验证的，该SRS才是可以验证的；当且仅当在某一性能价格比可取的有限处理过程，人或机器能通过该过程检查软件产品能否满足需求时，才称这个需求是可以验证的。
4.3.4 一致性当且仅当SRS中各个需求的描述是不矛盾时SRS才是一致的。
4.3.5 可修改性如果一个SRS的结构和风格在需求有必要改变时是易于实现的、完整性的、一致的，那么这个SRS就是可以修改的。
可修改性要求SRS具备以下条件：a. 具有一个有条不紊的易于使用的内容组织，具有目录表，索引和明确的交叉引用表；b. 没有冗余。
即同一需求不能在SRS中出现多次。
（1）冗余本身不是错误，但是容易发生错误。
冗余可增加SRS的可读性，但是在一个冗余文件被更新时容易出现问题。
例如：假设一个明确的需求在两个地方详细列出，后来发现这个需求需要改变，若只修改一个地方，于是SRS就变得不一致了。
（2）不管冗余是否必须，SRS一定要包含一个详细的交叉引用表，以便SRS具备可修改性。
4.3.6 可追踪性如果每一个需求的源流是清晰的，在进一步产生和改变文件编制时，可以方便地引证每一个需求，则该SRS就是可追踪的。
建议采用如下两种类型的追踪：a. 向后追踪（即向已开发过的前一阶段追踪）。
根据先前文件或本文件前面的每一个需求进行追踪。
b. 向前追踪（即是向由SRS派生的所有文件追踪）。
根据SRS中具有唯一的名字和参照号的每一个需求进行追踪。
当SRS中的一个需求表达另一个需求的一种指派或者是派生的，向前、向后的追踪都要提供。
例如：（1）从总的用户响应时间需求中分配给数据库操作响应时间；（2）识别带有一定功能和用户接口的需求的报告格式；（3）支持法律或行政上需要的某个软件产品（例如，计算税收）。
在这种情况下，要指出软件所支持的确切的法律或行政文件。
当软件产品进入运行和维护阶段时，SRS的向前可追踪性显得特别重要。
当编码和设计文件作修改时，重要的是要查清这些修改所影响的全部需求。
4.3.7 运行和维护阶段的可使用性SRS必须满足运行和维护阶段的需要，包括软件最终替换。
a. 维护常常是由与原来开发无联系的人来进行的。
局部的改变（修正）可以借助于好的代码注释来实现。
对于较大范围的改变。
设计和需求文件是必不可少的，这里隐含了两个作用：（1）如4.3.5 条指出，SRS必须是可修改的；（2）SRS中必须包括一个记录，它记录那些应用于各个成分的所有具体条文。
例如：它们的危急性（如故障可能危及完全或导致大量财政方面和社会方面的损失）；它们仅与暂时的需要相关（如支持一种可立即恢复原状的显示）；它们的来源（如某功能是由已存在的软件产品的全部拷贝复制而成）。
b. 要求在SRS中清楚地写明功能的来源和目的，因为对功能的来源和引入该功能的目的不清楚的话，通常不可能很好地完成软件的维护。
4.4 SRS的编制者软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。
这种协议要使用SRS的形式，应该由双方联合起草。
这是因为：a. 客户通常对软件设计和开发过程了解较少，而不能写出可用的SRS；b. 开发者通常对于客户的问题和意图了解较少，从而不可能写出一个令人满意的系统需求。
4.5 SRS的改进软件产品的开发过程中，在项目的开始阶段不可能详细说明某些细节，在开发过程中可能发现SRS的缺陷、缺点和错误之类的问题，所以可能要对SRS进行改进。
在SRS的改进中，应注意如下事项：4.5.1 尽管可以预见校正版本的开发以后不可避免，而对需求还必须尽可能完全、清楚地描述。
4.5.2 一旦最初识别出项目的变化，应引入一个正式的改变规程来标识、控制、追踪和报告项目的改变。
批准了的需求改变，用如下的方法编入SRS之中：a. 提供各种改变后的正确的、完全的审查记录；b. 允许对SRS当前的和被替代部分的审查。
4.6 SRS的编制工具编制SRS最显而易见的方法是用自然语言来描述。
尽管自然语言是丰富多彩的，但不易精确，用形式化的方法较好。
4.6.1 形式化说明方法在SRS中是否使用形式化方法要依据下列因素：a. 程序规模和复杂性；b. 客户合同中是否要求使用；c. SRS是否是一个合同工具或仅仅是一个内部文件；d. SRS文件是否成为设计文件的根据；e. 具有支持这种方法的计算机设备。
4.6.2 生产工具软件产品生产中有多种生产工具。
比如，计算机的字处理器就是非常有用的生产辅助工具。
一个SRS通常有若干作者。
可能经历若干版本，并且要进行多次重新组织内容。
故生产工具是必要的。
4.6.3 表达工具在SRS中有许多词汇，特别是许多名词和动词，专门涉及到系统的实体和许多活动，所以表达SRS需要若干工具。
比如：a. 可以验证实体或活动，无论在SRS中什么地方都是同一名字。
；b. 可以标识一个特殊的实体或动作在规格说明中的描述位置。
此外，可以使用若干种形式化方法，以便允许自动处理SRS内容，只要作某些限制就可以做到；用一些表格或图示法来显示需求。
用详细分层体系自动检查SRS的需求，这里每一个分层自身是完全的，但是也可以扩展为下一层，或是上一层的一个组成成分。
自动检查SRS具有在4.3条描述的部分或全部特点。
5 软件需求SRS中每一个软件需求是要求开发软件产品的某些基本功能和性能的一个陈述。