功能，用例，要求(2)

功能要求

功能要求表达了系统行为. 更具体地说，功能需求描述了什么是输入和输出，以及如何在不同的时间将特定的输入转换为特定的输出. 可以有效运行的大多数软件应用程序都具有丰富的功能要求. 在指定这些要求时，重要的是权衡歧义性（“当您按下On按钮时，系统将打开”）和特异性之间的关系. 为设计者和实施者提供尽可能多的设计和实施选择也很重要. 如果我们过于具体，那么开发团队可能会过于严格. 如果过于宽松，开发团队将不知道系统应实现哪些功能.

有多种正确的方法来指定要求. 这些技术之一只是使用声明性方法，并记录了系统需要执行的每个详细事件.

例如，当“此处焊接”输入被激活时，系统通过每100毫秒读取一次光学编码器来数字化电极端的位置.

详细的用例

在许多系统中，通过改进先前定义的用例并开发其他用例，可以很容易地组织规范活动以完全改进系统. 借助这项技术，您可以将用例步骤细化为更详细的系统交互. 您还需要定义前置条件和后置条件（在用例前后说明系统假设），以及由于异常情况而需要的备份操作.

由于用例在语义上结构良好，因此它们提供了用于组织和捕获系统行为的结构. 以下是Smartbot的代表性用例.

非功能性要求

除了输入到输出之类的功能要求外，大多数系统还需要定义一组非功能性要求，这些要求着重于指定其他系统的“属性”，例如性能要求，吞吐量，可用性，可靠性和可支持性. 这些要求与输入和输出的功能要求一样重要. 通常，非功能性要求的表达是声明性的，例如: “系统故障之间的平均时间应为2000小时”，“系统维修的平均时间应为0.5小时”和“ Smartbot应该能够最多可存储和检索100条焊接路径.

设计约束

与定义系统行为不同，第三类需求通常对系统设计或我们用于构建系统的过程施加限制. 我们将设计约束定义为:

对系统设计的限制或对系统开发步骤的限制，这些限制不影响系统的外部行为，但必须加以实施以满足技术，业务或合同的要求.

典型的设计约束可以这样表达: “用Java编写焊机控制单元”. 通常，我们将合理的设计约束视为其他要求，尽管满足这些约束的测试可能需要不同的技术. 与功能和非功能需求一样，这些约束在系统设计和测试中起着不可或缺的作用.

分层结构要求

许多项目都受益于使用层次结构或父子结构来表达这些需求. 父子结构需求是父亲需求表达的特殊性的扩展. 父子要求为您提供了一种灵活的方式来增强和扩展规格，同时还可以组织提供的详细程度. 仅查看父级的需求，就很容易以用户易于理解的方式提供顶级规范. 同时，实施人员可以快速查看详细的“子需求”规范，以确保他们可以了解所有实施细节.

请注意，分层结构需求包括三种标准类型的需求-功能，非功能和设计约束. 这里仅定义了这些要求之间的详细关系.

除了定义用来描述我们用来说明系统需求的事物的术语外，我们现在将注意力转移到关键关系上，即可追溯性，这是这些问题之间可能存在的关系.

开发高质量软件的一个重要因素是在规范，体系结构，设计，实施和测试阶段能够理解或跟踪需求的能力. 历史数据表明，更改的影响经常被忽略，对系统的微小更改可能会导致严重的可靠性问题. 因此，当发生变化时跟踪关系并关联这些关系的能力已经形成了现代软件质量保证流程的许多关键线程，尤其是在关键任务活​​动中，例如安全关键系统（医疗和运输产品），以及失败. 在高级系统（交易）中，形成了一个密钥线程.

让我们看看我们如何定义需求可追溯性:

可追溯性关系是一种依赖关系，在这种依赖关系中，“被跟踪”到的实体（故障，用例和需求）在某种程度上取决于其“被跟踪”的实体.

例如，我们描述了如何创建一个或多个软件需求来支持视觉文档中的给定功能或用例. 因此，可以说这些软件需求可追溯到一个或多个功能.

影响分析和怀疑

此，因为它们提供了使用我们所谓的“怀疑”进行影响分析的能力. 当“追溯自”（独立）需求中出现更改时，可追溯性关系开始“怀疑”，因此必须检查“追溯至”（依赖需求）以确保其与源需求一致.

例如，如果我们使用可追溯性将要求与特定测试相关联，并且诸如“ Smartbot应该能够存储和检索多达100条焊接路径”之类的要求变为“ Smartbot应该能够存储和检索多达200条焊接路径”焊接路径”，那么从该要求追踪的测试是可疑的，因为旨在测试第一个要求的测试不太可能适合于测试第二个要求.

最后，改变是不可避免的. 对于有前途的项目，管理变更的过程至关重要. 无论其来源和来源是什么，所有变更（包括影响功能和需求的请求）都必须有序地引入和管理. 任何变更管理系统的关键要素都是变更请求本身.

我们将更改请求定义为:

正式要求对系统功能和/或要求进行修订或添加. 变更请求需要作为系统结构化和正式的声明输入到系统中，该声明是提议的变更以及有关变更的任何详细信息. 为了管理这些更改，重要的是每个更改在系统中都有自己的标识. 变更请求的简化形式可能是:

在大多数项目中，您会发现不乏更改！实际上，您的问题是有序地管理，集成和（根据需要）拒绝不必要的更改. 换句话说，您需要一个管理变更过程. 您的变更管理系统应用于捕获所有输入并将其提交给变更控制委员会（CCB）进行解决. CCB由代表项目关键利益相关者（客户，营销和项目管理）的3至5人组成. 它管理和控制系统更改，因此在帮助项目成功中扮演着关键角色.

在开始时，我们指出本文的目的是帮助该领域的从业者提高他们回答以下基本问题的能力:

“系统应实现什么行为？”

作为实现此目标的第一步，我们定义并描述了分析人员和负责描述问题域中其他问题的其他一些常用术语，以表达将施加于预期解决方案的要求（例如，利益相关者的需求，功能，用例，软件要求等）. 在此过程中，我们还阐述了有效需求管理的一些关键概念. 通过使用本文中提供的术语和方法，您可以更有效地了解用户需求，并与负责构建满足客户和用户需求的系统的开发人员，测试人员以及其他技术团队成员沟通建议的解决方案的需求.

标准建模语言是进一步定义和传达软件解决方案其他关键方面的一项重要技术. 统一建模语言（UML）是一种用于在软件密集型系统中可视化，指定和记录工件的语言，并提供了一种以语义上更精确的方式表达这些技术构造的方法. 本文的配套文章“使用UML建模需求工件”建立了更有效地执行需求管理任务所必需的UML构造和扩展.

[Leffingwell 1999] Leffingwell，Dean和Don Widrig. 管理软件需求: 统一的方法. 马萨诸塞州雷丁: Addison WesleyLongman，1999年.

[Weigers 1999] Weigers性能需求描述，卡尔. 软件需求，雷德蒙德·华盛顿: 微软出版社，1999年.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-244445-2.html