软件需求规格

软件开发过程的需求阶段的生产是软件需求规范(SRS) (也称为需求文档)。该报告为软件工程活动奠定了基础，并且在提出和分析整个需求时正在构建。 SRS是一份正式报告，可作为软件的表示形式，使客户能够查看它是否符合他们的要求。而且，它包括用户对系统的要求以及系统要求的详细规格。

SRS是针对特定软件产品，程序或在特定环境中执行特定功能的一组应用程序的规范。根据谁编写它，它有几个目标。首先，SRS可以由系统的客户端编写。其次，SRS可以由系统开发人员编写。这两种方法创建了完全不同的情况，并为文档建立了不同的目的。第一种情况，SRS，用于定义用户的需求和期望。第二种情况SRS是出于各种目的而编写的，并且充当客户和开发人员之间的合同文件。

好的SRS的特征

以下是一个好的SRS文档的功能：

1.正确性：用户审核用于提供SRS中规定的要求的准确性。如果SRS涵盖了系统真正期望的所有需求，那么它就是完美的。

2.完整性： SRS在且仅当包含以下元素时才是完整的：

(1)。所有基本要求，无论是与功能，性能，设计，约束，属性或外部接口有关。

(2)。定义他们对所有可用情况类别中输入数据的所有可实现类的软件响应。

注意：必须指定对有效值和无效值的响应。

(3)。 SRS中所有图形，表格和图表的完整标签和参考，以及所有术语和度量单位的定义。

3.一致性：当且仅当在冲突中没有描述单个需求的子集时，SRS才是一致的。 SRS中可能存在三种冲突类型：

(1)。现实世界对象的指定特征可能会发生冲突。例如，

(a)输出报告的格式可以以一项要求描述为表格，而以另一要求描述为文本。

(b)一种情况可以规定所有指示灯应为绿色，而另一种情况则规定所有指示灯应为蓝色。

(2)。这两个指定的动作之间可能存在合理或暂时的冲突。例如，

(a)一个要求可以确定程序将添加两个输入，而另一个要求可以确定程序将它们相乘。

(b)一个条件可以说明“ A”必须始终跟随“ B”，而另一个条件则要求“ A和B”同时出现。

(3)。两个或多个需求可以定义相同的现实世界对象，但对该对象使用不同的术语。例如，程序对用户输入的请求可以在一个需求中称为“提示”，而在另一个需求中称为“提示”。使用标准术语和描述可促进一致性。

4.明确：当每个固定需求只有一个解释时，SRS就是明确的。这表明每个元素都有唯一的解释。如果存在一种具有多种定义的方法，则需求报告应确定SRS中的含义，以便其清晰易懂。

5.重要性和稳定性排名：如果SRS中的每个需求都有一个标识符来指示该特定需求的重要性或稳定性，则对SRS进行重要性和稳定性排名。

通常，所有要求并非同等重要。有些先决条件可能是必不可少的，尤其是对于生命攸关的应用程序，而另一些则可能是理想的。应该标识每个元素，以使这些差异清晰明了。对需求进行排名的另一种方法是将项目的类别区分为必需，有条件和可选。

6.可修改性：应该使SRS尽可能具有可修改性，并且应该能够在一定程度上快速获得对系统的更改。修改应该被完美地索引和交叉引用。

7.可验证性：当可以使用经济高效的系统验证指定要求以检查最终软件是否满足这些要求时，SRS是正确的。借助审核对要求进行验证。

8.可追溯性：如果每个需求的来源都很明确，并且便于在将来的开发或增强文档中引用每个条件，则SRS是可追溯的。

有两种类型的可跟踪性：

1.向后可追溯性：这取决于每个要求在早期文档中明确引用其来源。

2.前向可追踪性：这取决于SRS中的每个元素具有唯一的名称或参考号。

当软件产品进入操作和维护阶段时，SRS的可追溯性尤为重要。在修改代码和设计文档时，有必要能够确定这些修改可能涉及的整套要求。

9.设计独立性：应该有一个选项可以从最终系统的多种设计选择中进行选择。更具体地说，SRS不应包含任何实施细节。

10.可测试性： SRS的编写方法应易于从报告中生成测试用例和测试计划。

11.客户可以理解的：最终用户可能是其明确领域的专家，但可能没有接受计算机科学方面的培训。因此，应尽可能避免形式符号和符号的目的。语言应保持简洁明了。

12.正确的抽象级别：如果为需求阶段编写了SRS，则应明确说明细节。而对于可行性研究，可以使用较少的分析。因此，抽象级别会根据SRS的目标进行修改。

好的SRS文档的属性

好的SRS文档的基本属性如下：

简明扼要： SRS报告应简明扼要，同时要明确，一致和完整。详细和不相关的描述会降低可读性，还会增加错误的可能性。

结构化：应该结构良好。结构良好的文档易于理解和修改。实际上，SRS文档经过了多次修订以适应用户要求。通常，用户需求会在一段时间内发生变化。因此，为了使对SRS文档的修改变得容易，使报告的结构合理至关重要。

黑匣子视图：它仅应定义系统应执行的操作，并且不要说明如何执行这些操作。这意味着SRS文档应定义系统的外部行为，而不讨论实现问题。 SRS报告应将要开发的系统视为黑匣子，并应定义系统的外部可见行为。因此，SRS报告也称为系统的黑匣子规范。

概念完整性：应该显示概念完整性，以便读者只能理解它。对不良事件的响应：它应该表征对不良事件的可接受响应。这些被称为系统对异常情况的响应。

可验证： SRS文档中记录的系统所有要求均应正确。这意味着应该可以确定实施中是否满足要求。