【问题标题】:Is there such a thing as a "Non-Functional Use Case"?是否存在“非功能用例”之类的东西?
【发布时间】:2013-09-21 22:52:37
【问题描述】:

我正在阅读使用 Sparx Enterprise Architect 生成的系统需求文档。所有需求都映射到特定的用例。

“高可用性”的一些非功能性需求映射到名为“提供高可用性”的用例,标记为<<non-functional>>。我对所有这一切都相当陌生,并且正在努力确定用例不起作用是否有意义 - 因此是这个问题。

如果答案是肯定的,那就太好了 - 但如果不是,我很想知道人们对这些需求应该如何映射到用例(如果有的话)的看法。

【问题讨论】:

  • 我投票结束这个问题,因为它与编程无关

标签: uml high-availability use-case requirements


【解决方案1】:

“高可用性”的一些非功能性要求是 映射到名为“提供高可用性”的用例,标记为 .

俗话说,“如果你只有一把锤子,那么每个问题看起来都像钉子”。存在用例来识别系统为其用户提供的价值。因此,它们旨在描述功能性事物:系统所做的事情。

所以我通常不建议以这种方式捕获非功能性。但是:这并不是说它们不能在用例中被捕获。 功能用例中指定它们的非功能性需求可能非常有用。例如:

Use Case: Submit Order
{...functional description...}

Availability: 9-5 mon-fri
Volumes: 5000 peak per day
...

这将非功能性需求直接与它支持的功能联系起来。这是有道理的——因为非功能性没有功能就没有目的或上下文。

当然,您会发现许多用例共享相同的非功能性。你不想重复,所以需要找到一种方法来分解。我更喜欢在单独的文档中这样做。

但是没有法律禁止在“用例”中进行捕获。虽然它违反了理论,但有理由在实践中这样做:例如建模工具的局限性(无法将 UC 链接到文档)和/或希望将所有内容保存在一个位置。

从根本上说,它归结为理论和实践。理论上,不存在非功能用例。在实践中,创建一个 UC 来保存非功能性可能是有意义的。只要每个人都明白它实际上只是一个方便的容器,而不是一个真正的功能,我就不会为此烦恼。

第一次。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-09-14
    • 2010-09-24
    • 1970-01-01
    • 2012-01-10
    • 2015-03-15
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多