IEEE软件工程规范需求工程过程中的信息项之软件需求规范文档

欢迎大家来到IT世界,在知识的湖畔探索吧!

Abstract

软件需求规范 (SRS) 详细定义了特定软件产品在特定环境中的功能和性能要求。SRS 可由供应商和采购方共同编写，适用于整个项目或作为更大系统的一部分。SRS 需要与系统需求规范 (SyRS) 保持一致并扩展其内容，明确需求的优先级和关键性。它定义了所有必需功能、条件和约束，并记录了验证方法。信息项的管理应遵循 ISO/IEC 12207 和 ISO/IEC 15288 标准，确保信息易于获取且逻辑有序。

#需求探索##需求分析##软件工程#

信息项指南

在需求工程的过程中，项目应当生成以下几种关键的信息文档：

• 利益相关者 [1]需求规范文档(StRS)
• 系统需求规范文档 [2] (SyRS)
• 软件需求规范文档 (SRS)（如果遵循 ISO/IEC 12207 标准）

需要注意的是：

1. 在实际操作中，针对上述每种类型的文档可能会产生多个具体的规范文件。例如，可以分别为整个系统及其各个组成元素创建独立的 SyRS 文档。
2. StRS、SyRS 和 SRS 这三种规范可能包含相似的信息点。这些信息点可以从不同的角度来描述同一产品的需求。为了便于理解和使用，本标准分别列出了这三类规范文档的典型内容结构。
3. 参考 ISO/IEC/IEEE 15289 标准可以获得关于如何识别和规划在整个系统及软件生命周期中需要产生的特定信息项的具体指导。

对于信息项的管理，应按照 ISO/IEC 12207:2008 (IEEE Std 12207-2008) 和 ISO/IEC 15288:2008 (IEEE Std 15288-2008) 中规定的信息管理过程以及 ISO/IEC 12207:2008 的文件管理过程来进行。需要注意的是，信息项并不强制要求以物理形式存在；只要确保相关信息能够方便获取，并且按照逻辑顺序组织即可。

示例: 在采用模型驱动开发 (MDD) 方法时，几乎所有系统信息都是通过建模工具进行维护的。在这种情况下，信息会根据其上下文关系存储于建模工具的数据库中。用户可以直接查看模型中的信息，或者将所需数据导出为报告或表格的形式以便进一步分析和处理。

1 需求信息项概述

本文档系列以大纲的形式提供了三种规范文档的典型内容结构，这是第三部分 SRS 部分。

2 软件需求规格说明文档(SRS)

2.1 简介

软件需求规范 (SRS) 是针对特定软件产品、程序或程序集在特定环境中执行特定功能的规范。SRS 可以由供应商 [3]的一个或多个代表、采购方的一个或多个代表或两者共同编写。

考虑 SRS 在整个项目计划中所起的作用很重要。该软件可能包含项目的基本所有功能,也可能是更大系统的一部分。在后一种情况下,通常会有一个需求规范, 其中将说明系统与其软件部分之间的接口,并将外部性能和功能要求放在软件部分上。

当然,SRS 应该同意并扩展这些系统要求。 SRS 指示需求的优先级 [4]和关键性。SRS 定义了它所适用的指定软件产品的所有必需功能,并记录了软件必须执行的条件和约束,以及针对需求的预期验证方法。

2.2 SRS示例大纲

2.2.1 软件需求规范 (SRS) 的具体要求条款

SRS 的具体要求条款 应以系统利益相关者一致同意的组织方式进行编排，即采用有助于理解需求的结构。不同的系统可能需要不同的组织方式，并没有一种通用的最佳方法。 下面展示了一个 SRS 的示例大纲。

1. 简介

• 1.1 目的：概述文档的目的和范围。
• 1.2 范围：定义软件的边界和覆盖范围。
• 1.3 产品概述1.3.1 产品视角：描述软件在整个系统中的位置和角色 [5]。1.3.2 产品功能：概述软件的主要功能。1.3.3 用户特征：描述目标用户的特点和需求。1.3.4 限制：列出影响软件设计和实现的任何限制条件。
• 1.4 定义：列出文档中使用的术语及其定义。

2. 参考文献

列出编写 SRS 时参考的所有文档、标准和其他资料。

3. 具体要求

• 3.1 对外接口：描述软件与其他系统或组件之间的接口。
• 3.2 功能：详细说明软件必须实现的功能。
• 3.3 可用性要求：描述软件的易用性和用户体验要求。
• 3.4 性能要求：定义软件在响应时间、吞吐量等方面的性能指标。
• 3.5 逻辑数据库要求：说明软件处理的数据类型、格式和数据流 [6]。
• 3.6 设计约束：列出对软件设计和实现的具体限制条件。
• 3.7 软件系统属性：描述软件系统的其他重要属性，如可扩展性、可维护性等。
• 3.8 支持信息：提供与软件相关的支持信息，如文档、培训材料等。

4. 验证

• 验证：与第 3 节中的各个小节相对应，详细说明如何验证每个需求是否得到满足。（注：此部分未包含在原始 IEEE 标准 830 中）

5. 附录

• 5.1 假设和依赖关系：列出所有假设条件和依赖关系。
• 5.2 首字母缩略词和缩写：提供文档中使用的所有首字母缩略词和缩写的完整列表。

注释 1: 验证（图 8 中的第 4 节）未包含在原始 IEEE 标准 830 中。

2.2.2 SRS 中需求的组织方法示例

以下是一些常见的 SRS 需求组织方法：

• 系统模式：某些系统的行为会根据操作模式有很大差异。例如，控制系统可能根据其模式（训练、正常或紧急）具有不同的功能集。
• 用户类别：某些系统为不同类别的用户提供不同的功能集。例如，电梯控制系统为乘客、维修人员和消防员提供不同的功能。
• 对象：对象是现实世界中的实体，在系统中具有对应物。例如，在患者监测系统中，对象包括患者、传感器、护士、房间、医生、药品等。与每个对象相关联的是一组属性（该对象的特性）和功能（由该对象执行）。这些功能也称为服务、方法或流程。
• 功能：功能是系统提供的外部所需服务，可能需要一系列输入才能产生所需结果。例如，在电话系统中，功能包括本地呼叫、呼叫转移和电话会议。每个功能通常以一系列刺激-响应对来描述。
• 刺激：一些系统可以通过用刺激来描述其功能，从而得到最好的组织。例如，自动飞机着陆系统的功能可以分为断电、风切变、滚动突然变化、垂直速度过大等部分。
• 响应：某些系统可以通过描述支持生成响应的所有功能来最好地组织起来。例如，人事系统的功能可以组织成与生成薪水相关的所有功能、与生成当前员工名单相关的所有功能等相对应的部分。
• 功能层次结构：当上述组织方案均无用时，可将整体功能组织成按通用输入、通用输出或通用内部数据访问组织的功能层次结构。数据流程图和数据字典 [7]可用于显示功能与数据之间的关系。

注释 2: 有许多符号、方法和自动化支持工具可用于帮助记录 SRS 需求。在大多数情况下，它们的实用性取决于组织。例如： – 按模式组织时，有限状态机或状态图可能有用； – 按对象组织时，面向对象分析可能有用； – 按特性组织时，刺激-响应序列可能有用； – 按功能层次组织时，数据流图和数据字典可能有用。

通过这种结构化的组织方式，SRS 能够清晰地传达软件的技术规格和需求，确保所有参与者都能理解和遵循项目的目标和要求。这不仅提高了项目的可管理性，还增强了采购方和技术团队之间的沟通效果。

本文同步发表在 软件需求探索的 https://srs.pub/specification/srs-information-item-srs.html

1. 涉众定义与解释. https://srs.pub/theory/stakeholder.html ↑
2. 信息项指南之系统需求规范文档. https://srs.pub/specification/srs-information-item-syrs.html ↑
3. 商业分析中的五十种分析方法和技巧之49-供应商评估. https://srs.pub/babok/gongyingshang-pinggu.html ↑
4. 商业分析中的五十种分析方法和技巧之33-优先级. https://srs.pub/babok/youxianji.html ↑
5. 商业分析中的五十种分析方法和技巧之39-角色与权限矩阵. https://srs.pub/babok/juese-yu-quanxian-juzhen.html ↑
6. 商业分析中的五十种分析方法和技巧之13-数据流图. https://srs.pub/babok/shujuliu-tu.html ↑
7. 商业分析中的五十种分析方法和技巧之12-数据字典. https://srs.pub/babok/shuju-zidian.html ↑