功能，用例，要求

理性软件白皮书

Dean Leffingwell

2004年11月3日发布

作为BU时代（在UML之前）的面向对象技术的追随者和支持者，我必须承认，当时业界思想领袖传播的各种方法和表示形式对我来说具有魔力. 在使用UML的两到四年之前，您可以走进一个由OO拥护者拥挤的房间，并提出以下问题:

我认为这种面向对象技术很有希望，但是请告诉我，既然对象共享行为和数据，那么您如何称呼对象为履行其行为义务而做什么呢？

您可能会得到以下答案:

如果这还不足以使您感到困惑，请不要问您如何以图形方式表示我们所谓的对象和类. （这是一个矩形，一个云等）尽管这看起来很愚蠢，但现实是，由于术语和符号的原因，我们的某些软件工程领导者最显着的共识（继承，关系，封装）与它之间的细微差别无法共享，或者至少变得混乱. 换句话说，面向对象的工程科学和获得的利益都无法继续向前发展，因为还没有发明语言来描述科学. 当然，在这些作者，方法学家和独立思想家之间达成共识不是一件容易的事，但是最终UML出现了，软件工程科学又向前迈了一大步.

尽管需求管理方法可能不像UML之前的OO方法所形成的Barbita那样糟糕，但它也遇到了相同的问题-特别是模棱两可，前后不一致以及对常用词的过度使用非常受欢迎. 这些词汇表（包括诸如“用例”，“功能”和“需求”之类的基本概念）是“每个人都能理解”的日常词汇表，但是在给定上下文中的每个人都有自己的含义. 结果是沟通不畅. 这种情况仅发生在共识是成功标准的地区. Booch [Booch 1994]引用了Stepp的声明:

科学中的一个普遍问题是为观察到的物体和情况构造有意义的分类. 这种分类可以促进人们对观测的理解以及科学理论的后续发展.

为了促进需求的“科学理论”，我们必须面对术语问题.

本文的目的是通过定义和描述一些用于说明系统软件需求的最常用术语和概念来初步讨论软件工程的原理. 为此，我们希望为所有利益相关者（用户，经理，开发人员等）达成共识提供基础. 当然，如果我们能更有效地进行沟通并取得共识，那么就有可能更快地开发和交付更高质量的系统.

本文的重点不是需求管理的原理-在这方面，作者在推荐的阅读材料中推荐了许多参考书目. 本文的目的仅是帮助该领域的从业人员提高对系统正确行为的基本了解.

在开始描述特定术语之前，我们必须首先意识到我们需要以两种完全不同的方式来定义术语: 问题和解决方案. 我们分别称它们为问题域和解决方案域.

如果我们在问题范围内进行“低空滑行”，我们将在现实生活中发现许多东西. 例如，当“滑行”经过人力资源部门时，您将看到员工，负责支付薪水的人员以及薪水支票. 当通过重型设备工厂“滑行”时，我们将看到焊工，焊接控制器，焊接机器人和电极. 在“滑行”万维网上时，我们将看到路由器和服务器的集群，以及使用浏览器，电话和调制解调器的用户. 换句话说，在任何问题领域中，我们都可以轻松识别出我们看到并触摸的事物（实体）. 有时，我们甚至可以看到这些事物之间的关系. 例如，Web用户和浏览器之间存在的关系. 我们可能还会看到从一件事到另一件事的信息: “焊工似乎正在制定焊接机器人“大脑”中的工作顺序.

如果我们是敏锐的观察者，我们可能会发现亟待解决的问题: “由于无法安排正确的工作顺序而使工人感到沮丧”或“请注意，员工输入薪水数据与接收工资之间存在不愉快之处检查时间延迟！”. 有些问题似乎在寻求解决方案. 也许我们可以构建一个系统（更好的可编程控制器，更有效的薪资处理）来帮助那些贫穷的用户解决这些问题.

根据用户和利益相关者的需求

但是，在构建新系统之前，我们需要确保我们了解问题域中用户的实际需求. 如果没有，我们可能会发现焊工只能皱眉，因为他的脚痛得像玉米一样. 结果，他和他的经理都不会对购买我们最新的“ SmartBot”自动焊接控制单元感兴趣. 我们还注意到，当我们尝试出售SmartBot时，经理是购买决策的关键利益相关者. 我们不记得在“滑行”中见过她. （也许当时她在吸烟室，这是我们相机的盲点）. 换句话说，并非所有利益相关者都是用户，如果我们想有机会出售SmartBot，我们必须了解两个社区（利益相关者和用户）的需求. 为了简单起见，我们将所有这些需求称为利益相关者需求，但是我们必须不断提醒潜在的用户，我们的系统有时代表非常重要的利益相关者类型.

我们将利益相关者的需求定义为:

反映业务，个人或运营问题（或机会），必须解决这些问题以使用户确信他们考虑，购买或使用新系统的选择是正确的.

因此，利益相关者的需求成为与问题域相关的问题的一种表达. 这些利益相关者的需求并未给出解决方案，但是从最初的角度来看，让我们了解需要实施哪些可行的解决方案. 例如，如果我们遇到在重型设备制造工厂中管理焊工的经理，我们可能会发现，焊接大量重复的焊件会浪费大量的制造时间和成本. 另外，焊工似乎不喜欢这些特定的工作，因为它们总是有被烧伤的危险. 更糟糕的是，工作的物理方面（重复，难以想象的体力劳动和视力伤害等）构身安全问题和长期健康风险.

充分理解这些问题之后，我们可以开始定义一些利益相关者的需求:

了解了系统的这些不同方面之后，主观上，我们会将这些发现“堆积”在一个称为利益相关者需求的小堆中.

幸运的是，“滑行”到问题域并不需要很长时间，而且（通常）我们在问题域中发现的并不是很复杂. 当我们完成“滑行”并开始构建我们已经观察到的问题以及所需的解决方案时，我们就开始理解这些问题. 是的，我们已经开始了最困难的部分: 构建问题的解决方案. 我们考虑活动集（系统定义，设计等），为解决问题而发现和构建的“事物”（计算机，机器人手臂等），以及在解决方案域的处理部分中创建的工件（例如源代码，用例和测试）.

在解决方案领域，我们必须成功执行许多步骤和活动，才能定义，构建并最终部署成功的问题解决方案. 其中包括:

1）了解用户需求

2）定义系统

3）管理范围并管理更改

4）完善系统的定义

5）建立正确的系统

简而言之，以上步骤定义了需求管理的简化过程. 本文无意详细介绍这些步骤；我们将为您推荐一些参考读物，包括教科书“ Managing Software Requirements”，[Leffingwell，1999]. 本文与该参考书一致，此处提供的大多数定义均来自该参考书.

例如，在参考书[Leffingwell，1999]中，我们将发现需求管理的定义如下:

获取，组织和记录系统需求的系统方法，以及在客户和项目团队之间就系统需求的变化建立并保持共识的过程.

让我们继续找到并定义其他更多的需求管理术语，以描述将要构建的系统.

当我们开始考虑已发现问题的解决方案时，自然会匆忙写下系统的特征. 功能在系统开发中扮演着有趣的角色. 它们似乎介于用户真正需要的表达方式与系统满足这些需求的详细方式之间. 这样，它们提供了一种方便的结构，用于以抽象的方式描述系统，或者根据需要提供“简写方法”. 因为有许多可能的解决方案需要解决，所以这些功能在某种意义上提供了特定系统解决方案的初始范围. 他们描述了系统打算做什么和不打算做什么.

我们将功能定义为

系统提供的满足一个或多个利益相关者需求的服务.

我们可以使用用户熟悉的术语轻松地用自然语言表达特征. 例如:

由于特征源自利益相关者的需求，因此我们将它们安排在金字塔的下一层，即低于需求. 同时，我们也从问题域（需求）转移到解决方案域的第一级（功能）.

要注意的一件事是，功能不仅仅是对利益相关者需求的改进（添加了更多详细信息）. 相反，它们是对用户提供的问题的直接响应，并且为我们提供了问题的顶级解决方案.

通常，我们应该能够通过定义25到50个表征系统行为的特征来描述系统. 如果发现手边有50多个功能，则可能是因为您无法抽象系统的真实特征，或者系统太大而无法理解，因此您需要考虑将其分成较小的部分.

特征是用自然语言描述的，因此任何阅读此列表的涉众都可以立即获得对系统行为的基本了解. 功能列表将缺少详细级别的细节. 不要紧. 我们只是在试图传达目的，并且由于许多利益相关者都是非技术人员，因此太多的细节可能会使他们感到困惑甚至干扰理解. 举例来说，我们的SmartBot自动焊接机器人的某些功能列表可能包括:

当我们进一步考虑系统如何完成用户任务时，我们可能会发现使用用例技术来进一步描述系统行为很有用. 该技术在许多书籍中得到了很好的发展[Jacobson 1992]，并且还是行业标准统一建模语言的组成技术[Booch 1999].

从技术上讲，用例:

描述了系统执行的一系列为用户带来价值的动作.

换句话说，用例描述了一系列帮助用户实现期望的用户和系统交互. 换句话说，用例描述了用户和系统如何协同工作以实现所确定的特征.

用例还介绍了参与者的结构. 参与者只是当时使用该系统的用户的标签. 在UML中，简单的椭圆用来表示用例，而参与者则由带有名称的线图表示. 因此，您可以使用一个简单的图来说明两者，如下所示.

用例技术为参与者如何实现用例指定了一个简单的分步过程. 例如，“步骤和重复”的用例可能如下所示:

步骤1: 焊工按下步骤并重复按钮以开始序列.

步骤2: 焊接系统为驱动马达供电，以便可以手动控制机械臂.

第3步: 焊工握住扳机，将机械臂移动到焊接位置，然后按下“在此处焊接”按钮以焊接每条待焊接的线.

用例技术提供了许多其他有用的构造，例如前后描述，替代流程等. 稍后，我们将在详细讨论用例时讨论它们. 但就目前而言，我们只需要知道用例提供了一种很好的方式来描述如何实现系统功能.

出于规划目的，可能需要用例以外的方法来描述如何实现特定功能. 每个功能可能只有少数几个用例（可能是3到10）. 在描述用例时，我们详细介绍了系统的行为. 随着其他功能的获得，用例变得更加详细.

在许多开发尝试中，问题声明，关键利益相关者，用户需求，系统功能列表以及示例用例都可以在称为愿景文档的文档中找到. 它还具有许多其他名称，例如项目章程（Project Charter），产品需求文档（Product Requirements Document），市场需求文档（Marketing Requirements Document）等. 无论名称如何，Vision文档都强调总体意图和目的. 表示正在构建的系统，因此是过时功能和说明性用例的自然容器. 换句话说，愿景文档捕获了系统的完整形式，并使用利益相关者的需求，功能和用例来传达意图.

但是，我们不能简单地将这些功能和初始用例转移给开发团队，并期望他们快速开发出真正满足利益相关者需求的系统. 我们可能需要更清楚地了解系统功能，并且可能涉及各种新的涉众，包括开发人员，测试人员等. 这是解决系统定义的下一层（软件需求）的需要.

软件要求在软件定义过程中提供了更高级别的特异性. 在这个级别上，我们必须指定足够的要求和用例，以便开发人员可以编写代码，而测试人员可以测试代码是否满足要求. 图形化地，软件需求为我们的金字塔奠定了基础.

软件要求是什么？尽管过去几年中有很多定义，但我们发现需求工程创始人Dorfman和Thayer [Dorfmann 1990]提供的定义最合适:

使用此定义，开发团队可以制定一组更具体的要求，以完善或完善先前讨论的功能列表. 每个需求都是特定的特征，反之亦然. 注意此方法的简单性. 我们提供了功能列表，然后通过编写一组可满足这些功能的要求来对其进行完善. 我们没有写任何其他要求. 这样避免了坐在椅子上凝视天花板，“弥补了系统的某些需求”的诱惑.

此过程简单明了，但并不容易. 需要审查每个功能，然后编写要求以支持该功能. 不可避免地性能需求描述，编写功能要求会导致您向已检查的功能添加新要求或修改功能.

当然，您知道编写要求并不容易，并且可能需要指定大量要求. 我们发现考虑三种或几种类型的软件需求（功能需求，非功能需求和设计约束）很有帮助.

我们发现，这三个需求对于我们考虑需求和期望需求可以完成的任务非常有帮助. 让我们看一下这些不同类型的需求，以及如何使用它们来定义所需系统的各个方面.

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