3.5 软件需求规格说明书

软件需求规格说明书（software requirements specification）是具有一定法律效力的合同文档，并依据供需双方达成的共识，清楚地描述软件在什么情况下需要做什么以及不能做什么，通过定义系统的输入/输出、输入到输出之间的转换方式来描述系统的功能性需求，也描述经过干系人磋商达成共识的非功能性需求，一般参考需求定义模板完成，覆盖标准模板中定义的所有条目，并将需求作为后续的软件评估依据和变更的基准。

软件需求规格说明书需要遵守逻辑组织结构，比如参照IEEE的模板。典型的组织形式包括：按系统能够响应的各种外部环境情况来组织，比如飞机着陆管理系统中的环境条件（风速、燃料余量、跑道长度等）；按系统的功能特征来组织，比如电话系统的来电屏蔽、呼叫转移、电话会议等；按系统的响应方式来组织，比如工资管理系统中的请求/响应（工资条生成请求、成本计算、打印税单等）；按所管理的外部数据对象来组织，比如图书管理系统中按书籍类型来组织需求的撰写；按用户类型来组织，比如一个项目管理系统，按照经理人、管理人员来组织系统的需求；按软件的工作模式来组织，比如一个文档编辑器可以按照文档编辑时的页面布局分成分页模式、普通文档编辑模式、大纲模式等；按子系统的划分来组织，比如一个飞行器管理系统会包括命令管理子系统、数据处理子系统、通信子系统、设备管理子系统等。

软件需求规格说明书有以下几种风格：一是描述性的自然语言文本，其中最常见的是敏捷方式下的用户故事；二是从用例模型产生，因为可将用例模型与需求转化看成是可逆的过程，如果需求模型以用例的形式表示，可以逆向生成需求的完整集合，也可以在工具的支持下完成；三是从需求数据库中生成，商业需求数据库有内置的功能来生成经过筛选的需求规格说明，或者从产品线需求规格数据库中生成特定产品的需求规格说明；此外，还可以从混合模型中生成，比如特征模型和用例模型的混合，需要内嵌模板和工具。表3.2是生成不同风格软件需求规格说明书的方法总览。

还可以把用户手册作为软件需求规格说明书。撰写用户手册作为软件需求规格说明书是一种高性价比的方法，能够一箭双雕，对于和用户交互的系统是比较有效的，这样系统由交互驱动。好的用户手册描述了所有用例的所有场景，例如《人月神话》一书中就描述了将用户手册作为软件需求规格说明书的做法，另外据说苹果公司第一台计算机的编码工作开始之前就写好了用户手册。但是，用户手册并没有描述非功能性需求，也没有描述那些不和用户交互的功能性需求，比如函数计算、过滤器或翻译工具等。

常见的用户手册大纲包括介绍、开始、操作模式、高级特性、命令语法和系统选项几个部分，其中，介绍包括产品总览和基本原理、术语和基本特征、展示格式与报表格式的总结、手册的大纲；开始部分包括开始指令、帮助模式和样例运行；操作模式有命令行、对话框、报告几种模式。

软件需求规格说明书的用户有客户和终端用户、市场人员和销售、产品开发人员、测试人员、项目管理人员等。其中，客户和终端用户是需求的提供者，要保证其满足用户的需要；市场人员和销售根据客户要求定义有竞争力的产品特征，管理产品的发布；产品开发人员通过需求来了解系统要做什么并且开发、实现系统；测试人员参照需求进行系统验证，通过测试和用户征询的方式对系统质量进行评估；项目管理人员需要参照软件需求规格说明书来控制和度量项目的进展，对项目在不同国家和地区实施的要求，需要基于产品的核心部分补充本地运行所需的特性。

一个高质量的软件需求规格说明书是所有需求的集合，它描述了产品要提供的所有功能，也是软件系统解决方案商业合同的基础，并且是测试计划的参考基础，它是定义产品需求的度量标准，也是产品需求跟踪的先决条件，影响开发产品的项目计划。

高质量软件需求规格说明书的评价标准有正确性、无歧义、完整性、可测试性、可修改、可跟踪、易理解、一致性和有序性等，还包括项目或产品特定的其他特征。另外还需要保证需求规格说明的简洁性。一个需求描述是简洁的是指描述系统的一个独立特征，除了必需的信息外，没有包含其他信息，使用清晰、简单、可理解的词语表述，避免“应该”“可以”“可能”之类的用词。 pX3KS8PJXXAVm9togYcPy6sK621ZTOtKaEwHn84rVQ6VmxS6+gwNJY/dqCK4svcG