20080801项目管理规范六(软件需求规格说明书格式

软件需求规格说明书1引言1.1编写目的说明编写这份软件需求规格说明书的目的，指出软件需求规格说明所针对的不同读者，例如开发人员、项目经理、营销人员、用户、测试人员或文档的编写人员。1.2背景说明：a．待开发的软件系统的名称；b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；c．该软件系统同其他系统或其他机构的基本的相互来往关系。1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列举编写软件需求规格说明时所参考的资料或其它资源。如：a．本项目的经核准的计划任务书或合同、上级机关的批文；b．属于本项目的其他已发表的文件；c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。d．有关的用户界面风格指导、使用实例文档，或相关产品的软件需求规格说明等。列出这些文件资料的标题、文件编号、发表日期和出版单位，或资料来源，以方便读者查阅这些文献。2任务概述2.1目标叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。|2.2用户的特点列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束2.3假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。还可能包括你打算要用的商业组件或有关开发或运行环境的问题。此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。3需求规定3.1对功能的规定3.1.1功能划分概述产品所具有的主要功能。例如用列表的方法给出。很好地组织产品的功能，使每个读者都易于理解。用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图。3.1.2功能描述针对所有功能分别详细列出与该功能相关的详细需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作。用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。列举出各功能的所有操作规则，例如什么人在特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。一个业务规则的范例如下：“只有持有管理员密码的用户才能执行$100.00或更大额的退款操作。”3.2对性能的规定阐述对产品性能的需求，并解释它们的原理以帮助开发人员做出合理的设计选择。3.2.1精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。3.2.2时间特性要求说明对于该软件的时间特性要求，如对：a．响应时间；b．更新处理时间；c．数据的转换和传送时间；d．解题时间；等的要求。3.2.3灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：a．操作方式上的变化；b．运行环境的变化；c．同其他软件的接口的变化；d．精度和有效时限的变化；e．计划的变化或改进。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.3输人输出要求解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。3.4数据管理能力要求说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。3.5故障处理要求列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。3.6其他专门要求如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。4运行环境规定4.1设备列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：a．处理器型号及内存容量；b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；c．输入及输出设备的型号和数量，联机或脱机；d．数据通信设备的型号和数量；e．功能键及其他专用硬件4.2支持软件列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。4.3接口说明该软件同其他软件之间的接口、数据通信协议等。4.3.1用户界面陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。以下是可能要包括的一些特征：将要采用的图形用户界面（GUI）标准或产品系列的风格。屏幕布局或解决方案的限制。将出现在每个屏幕的标准按钮、功能或导航链接（例如一个帮助按钮）。快捷键。错误信息显示标准。4.3.2硬件接口描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。4.3.3软件接口描述该产品与其它外部组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的限制。4.3.4通信接口描述与产品所使用的通信功能相关的需求，包括电子邮件、Web浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。4.4控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。对于编写需求规格说明书的说明：1、软件需求规格说明，也称为功能规格说明、需求协议以及系统规格说明。它精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件。软件需求规格说明不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。2、软件需求规格说明作为产品需求的最终成果必须具有综合性：必须包括所有的需求。开发者和客户不能作任何假设。如果任何所期望的功能或非功能需求未写入软件需求规格说明那么它将不能作为协议的一部分并且不能在产品中出现。3、编写优秀的需求文档没有现成固定的方法，上述格式也根据具体情况进行调整，最好是根据经验进行。4、构造并编写软件需求规格说明，并使用户和其它读者能理解它牢记以下可读性的建议：•对节、小节和单个需求的号码编排必须一致。•在右边部分留下文本注释区。•允许不加限制地使用空格。•正确使用各种可视化强调标志（例如，黑体、下划线、斜体和其它不同字体）。•创建目录表和索引表有助于读者寻找所需的信息。•对所有图和表指定号码和标识号，并且可按号码进行查阅。•使用字处理程序中交叉引用的功能来查阅文档中其它项或位置，而不是通过页码或节号。5、编写软件需求规格说明的原则1）完整性每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。2）正确性每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。3）可行性每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。4）必要性每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是授权用来编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。5）划分优先级给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制。6）无二义性对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。7）可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。6．编写软件需求规格说明时应牢记的几点建议：•保持语句和段落的简短。•采用主动语态的表达方式。•编写具有正确的语法、拼写和标点的完整句子。•使用的术语与词汇表中所定义的应该一致。需求陈述应该具有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的化学药品容器清单。”为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的，应该明确真正含义并且在需求中阐明用户的意图。避免使用比较性的词汇，例如：提高、最大化、最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。含糊的语句表达将引起需求的不可验证。需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除不明确性为止。必须以相同的详细程度编写每个需求文档。不应该把多个需求集中在一个冗长的叙述段落中。务必记住，不要在需求说明中使用“和/或”，“等等”之类的连词。不应该出现需求冗余。虽然在不同的地方出现相同的需求可能会使文档更易读，但这也造成了维护上的困难。需求的多个实例都需要同时更新，以免造成需求各实例之间的不一致。在软件需求规格说明中交叉引用相关的各项，在进行更改时有助于保持它们之间的同步。让独立性强的需求在需求管理工具或数据库中只出现一次，这样可以缓和冗余问题。应考虑用最有效的方法表达每个需求。