非功能需求和用例图

Question

我的软件提供了两个功能需求，我表示它们，就像图1中的A和Do B一样。同时，我的软件有一个非功能的需求，提供多种语言的接口.据我所知，非功能需求不应该被建模为用例，但是，我不确定如何表示它，因为与此同时，像用户所做的那样包含更改语言的能力似乎是很自然的。请帮我理解一下。

Answer 1

尽管可用性、可访问性、国际化和本地化以及文档需求倾向于非功能性需求，但可能存在支持这些目标的功能需求。如果系统支持通过用户操作、自动检测或其他方式更改其语言，则这是一项功能要求。它定义了系统针对出现在用户界面元素上的语言执行的特定行为。

由于系统更改其语言是一种功能需求，并且是关于系统的行为的，所以可以想象它会出现在用例图上。不过，理解用例是什么很重要。用例是对系统在特定条件下允许参与者完成目标的行为的描述。

并不是所有的功能需求都被捕获为用例。“登录”的概念就是一个很好的例子。演员的目标通常不是与系统进行身份验证。同样，我发现参与者不太可能使用您的系统来更改用户界面的语言。因此，我不认为“选择语言”的用例应该在用例图上，甚至不应该被建模为文本用户界面。

如果您使用用例来捕获系统的行为，我会考虑将其作为先决条件。执行这些步骤的先决条件可以是“用户将用户界面语言设置为他们的语言”或“系统以用户的语言显示用户界面元素”。由于文字描述也包含对所涉行为者的引用，因此可以使用有关行为者或角色的信息来确定系统需要支持哪些语言，并设计不同行为者能够以正确的语言看到系统的测试用例。

我还要留一个临别的想法，马丁·福勒：

用例以用例图的形式出现在UML中，但是这些图没有什么价值-用例的关键价值在于在UML中没有标准化的文本。所以当你用用例的时候，把你的精力放在课文上。

不要把太多的精力放在用例图上。如果您正在使用用例，请将更多的时间用于确定参与者、前后条件、场景和扩展等方面。这将帮助您设计、构建和测试系统，以确保其符合所理解的用例。

Answer 2

UML用例图具有“通过设计”的非常有限的语义。因此，为了使这些图有用，必须为每个用例提供描述(例如，以文本形式)。如何构造这种描述取决于您自己，如果需要的话，它还可以包括应用于系统的所有用例的部分。就像“改变语言的能力”这样的非功能性需求的自然存在。

Answer 3

用例对不同的人来说意味着不同的事情。但它并不等同于功能需求。否则，您将得到非常复杂的图，这些关系图几乎不会为需求的文本列表和功能分解增加任何价值。

用例表示与用户目标相对应的“提供的行为集”(用例的UML定义)：

用例是使用系统实现特定用户特定目标的所有方法。将所有用例集合放在一起，您将得到使用系统的所有有用方法，并说明它将提供的价值。 - Ivar Jacobson (用例的发明者和UML的共同发明者)，在用例2.0中

因此，原则上，您不应该绘制所有功能需求的图表，而应该只绘制最重要的需求。在某些情况下，您甚至可以将一些组合在一起:图表应该显示总体情况。

在图中的每个用例背后，都有一个描述。流行的格式有科克本模板，洛克伍德和康斯坦丁的“基本用例”，more 传统，常常受到Bittner & Spence的启发，甚至是简单的文本叙事)。在本说明中，您将找到剩余的功能需求，以及特定于用例的非功能需求。但是，您肯定还会在某个地方列出与所有用例相关的一般非功能需求。