在以下示例中什么算作功能需求，什么不算？

Question

[对于我的作业，我必须编写一款名为Downfall（see Wikipedia）的游戏的功能要求。我们必须制作这个游戏，但不能有两个面，但要有n个（任意数量）面。

在示例解决方案（另一个游戏）中，老师编写了功能需求，然后编写了它们属于的用例。

[我创建了一个用例图，其中以玩家为演员，并以ChooseDial，RotateDial和EndTurn作为用例：

我不了解以下内容：玩家人数有功能要求吗？桌子的两侧是否有功能要求？游戏的目标（从上到下获取硬币）是否有功能要求？是规则，例如硬币必须达到功能要求的最低点吗？

如果是，它们可以属于什么用例？我的用例图错了吗？

我不知道将这些功能需求放在哪里，因为我觉得它们在我的所有用例中都没有。

Answer 1

需求管理（RM）确实很棘手。像电路板必须有两个侧面这样的需求似乎更多地参与了设计，而不是用例。在这种情况下，您可以将其与边界而不是单个用例联系起来。这将表明它是一些“全局”要求（类似于非功能性要求）。通常，在项目中，您开始时会在用户故事中混合一些或多或少奇怪的需求。业务分析师（BA）必须对这些信息进行梳理，并提出合理的用例（综合增加的价值）。然后，系统架构师（与BA一起）将通过需求和用例来提出（业务）类模型。

有大量描述RM的书籍和程序。也有很多研讨会。我认为，如果您掌握了上面的简洁想法，就可以开始了。这是一场马拉松比赛...

Answer 2

关于要求

首先，让我们处理需求问题：

• A functional requirement讲述了软件应该做什么。与目标，游戏玩法或游戏规则相关的所有内容都是功能需求。
• A non functional requirement讲述了软件的外观，例如准确性，性能，易用性，易于维护性。您的叙述没有这样的要求。

关于用例

用例驱动的软件开发方法始于用例中捕获的高级用户目标。就个人而言，我只看到一个这样的目标：

非常罕见的用法：用例的multiplicity on the actor side。这表示用例的一个实例涉及2个或更多玩家实例。当然，这仅对整个游戏有意义，而不对单个动作有意义（就像您在图表中一样）。

在您的图中，您显示了3个用例：

• EndTurn是用户可以自由决定选择的独立目标吗？不行这总是跟随玩家的动作。因此，这绝对不是用例。
• 您说RotateDialsextendsChooseDials。这意味着玩家可以ChooseDials但不能旋转。这是有效的方案吗？
• [另一方面，如果您说ChooseDialsincludesRotateDials，则后者总是会发生。但是，ChooseDial不只是选择一个表盘吗？那不应该叫PlayTurn吗？

我可以理解，出于学习目的，您希望在更详细的用例中分解Play game。通常，一旦玩家尝试达到其目标Play game，则可能包括Play turn的子目标。只要它是面向目标的并且不太详细，就可以。但是，请尝试avoid simple functional decomposition（对于更多的用户驱动而言无济于事）。而且，最重要的是，不要滥用用例图来尝试显示activities的序列。

需求可追溯性

用例未涵盖全部需求。它捕获了最重要的内容：系统的目的和用户目标。

写下需求时，然后由用例及其叙述指导，并追溯每个用例特定的需求，这很有用。

但是，当然也有一些一般要求。这些不是特定于特定用例的。有些甚至对于所有用例都是通用的。将这些标记为一般要求（例如用例*）。