软件工程英语翻译-Unit 2

A：软件需求

需求阶段的主要目标是形成一个准确获取客户需求并形成软件开发和确认基础的软件 需求规格说明书(Software Requirements Specification,SRS)。形成软件需求说明困难的主 要原因是来自需求参与的三方一一客户、最终用户和软件开发人员。需求文档必须能够让客 户和用户容易理解，并且能够让开发人员将其作为软件开发的基础来使用。由于在软件需求规格说明中涉及多方人员，存在着沟通上的分歧与隔阂，这使得需求规格说明的任务很难。

需求阶段有三个基本活动。第一个活动是问题或需求分析。该活动的目标是要理解诸如 问题的需求、其上下文以及如何适合于客户组织内部等各个方面的问题。第二个活动是需求 规格说明，在该活动期间，要对已理解的问题进行详细说明或撰写成文档，产生软件需求规 格说明书。第三个活动是需求确认，进行需求确认活动是为了确保软件需求规格说明书中指定的需求正是想要的(见图2-1)。

有三种主要方法用于需求分析。非结构化的方法依赖于分析师、客户和用户三者的互动 以提出所有需求(然后形成文档)。第二种方法是面向建模的方法，在这种方法中，在可用 信息的基础上创建问题模型。模型在确定需求理解是否正确以及确保所有需求是否都已确定 方面很有用。建模可以面向功能或面向对象。第三种方法是原型方法，在这种方法中，建原型来确保需求的正确性和完整性。

要完成目标，软件需求规格说明书必须具有完整性、 一致性、无二义性、可证实性和可 变更性等特性。 一份好的软件需求规格说明书应该详细说明软件需要支持的所有功能、系统性能、存在的设计约束和所有外部接口。

现在流行的用于详细说明功能规格的一种方法是用例方法。使用这种方法，系统的功能 通过用例来详细说明，每个用例都详细说明当一个用户为了完成某个目标而与系统交互时的 系统行为。每个用例既包含正常情况，也包含异常情况，因此可以提供系统行为的完整描述。 尽管用例是为规格说明而设定的，但由于其自然性和故事性，通过在不同的抽象级别上表达用例，用例也可以用于问题分析。

对于需求确认，最常用的办法是评审和检查需求。在需求检查中，评审小组中也应该包含一名客户代表，以确保获取了全部需求。

B

一旦你在需求收集阶段开发了一组初始的功能性需求，你将很好地理解系统的预期行为。 你将了解所需的功能、施加的约束以及将满足的业务目标。然而，传统的需求“细目清单的一个缺点是，它们是静态的，不关心需要由一个特性支持的不同业务流程。

例如，在我们虚构的在线图书馆系统中，管理归还的功能需要处理不同的情况，即借人提前归还图书和晚归还图书。尽管涉及到相同的功能，但它们是不同的情况，系统需要每个用例中处理单独的条件。因此，用例是揭示由于系统使用方式不同而产生的隐含功能一种有价值的方法。用例还为将用于测试系统的测试用例提供了一个很好的起点。

用例是系统需要完成的特定业务目标的定义。用例将通过描述存在于系统外部的各种外部参与者(或实体),以及它们在实现业务目标过程中与系统的具体交互来定义这个过程。

用例可以在抽象级别(称为业务用例)或在特定实现的级别(称为系统用例)上描述。下面将更详细地介绍每一种情况：

· 业务用例—一也被称为“抽象级用例”,这些用例是用一种与技术无关的方式编写 的，简单地引用被描述的高级业务流程(例如“书还回来”)和参与这个过程的各种 外部实体(也称为参与者。例如“借款人”、“图书管理员”,等等)。业务用例将定义业务需要执行的动作序列，以向外部实体提供有意义的、可观察的结果。

· 系统用例—一也称为“实现用例”,这些用例比业务用例的详细程度更低，指的是 将由系统的不同部分执行的特定过程。例如， 一个系统用例可能是“逾期归还图书”,并描述了各种参与者(借款人，图书馆员)与系统在执行端到端流程时的交互作用。

通常，你将从定义高级业务用例开始，随着定义系统需求，它们将被“深入”到一个多个低级系统用例中。

一个相关的工件是“业务场景”或用户故事。在试图完成对系统将如何执行指定业务流 程以满足规定要求的描述方面，它们与用例相似。但是，与用例不同的是，该用例是对流程(与相关参与者之间)执行的任务进行逐步枚举的场景，它的形式更为自由。

用户故事通常是描述用户将如何体验系统功能的叙述。顾名思义，它是一个“短篇故事”, 描述了它们执行的任务，它们看到的信息以及它们如何与系统交互。随着强调客户协作、户交互和简单性的敏捷方法的出现，用户故事变得越来越流行。

用例图是可以用来更清楚地说明由系统中的功能提供的用例集的图(见图2-2)。图包含

要使用系统的外部实体(也称为“参与者”)和用户将执行的离散用例(或目标)。

这些图通常以Uπ 建模语言表示(尽管确实存在其他形式),并且将帮助业务分析师传 达参与者与他们的业务目标之间的关系，以及系统的设计需要如何通过集成的业务流程来支持他们的不同目标。

除了描述不同参与者和目标的UML 用例图之外，你还可以使用过程流程图以图形方式枚举每个过程中将要发生的步骤(见图2-3)。

在最简单的形式中，它可以是从头到尾的线性流，但是在更复杂的用例中，你可能具有多个分支和决策点，在这种情况下，它成为完整的流程图。

用例经常被用作发现和表示功能以及系统需求的方法，因为它们定义了实现特定业务目 标所需的交互和任务。然而，它们通常不是定义非功能性需求(如技术需求或系统质量)的好 方法。需求跟踪矩阵用于确保完整性——即所有功能需求至少由一个业务用例覆盖，所有系统需求至少由一个系统用例覆盖。

由于你通常需要确保一个好的质量，保证程序有完整的需求测试覆盖率，用例为测试用例的设计提供了一个良好的起点，这些测试用例将用于测试系统是否满足指定的需求。

一旦完成了需求工程活动，并且业务分析师对需求定义感到满意，测试编写者便可以基 于系统用例创建测试用例。  这通常涉及添加更详细的前提条件和后置条件，以及编写同一 用例的不同测试用例“变体”以涵盖不同的测试用例。  其中一部分将涉及识别可能导致系统故障的关键异常情况，以及开发必要的测试数据以确保全面覆盖所有测试条件。