我正在阅读使用Sparx Enterprise Architect生成的系统需求文档。所有要求都映射到特定的用例。
“高可用性”的一些非功能性要求映射到名为“提供高可用性”的用例,标记为<<non-functional>>
。对于所有这些都是相当新的并且努力决定用例是否有用是不可行的 - 因此问题。
如果答案是肯定的那么好 - 但如果没有,我有兴趣了解人们对这些要求应如何映射到用例(如果有的话)的意见。
答案 0 :(得分:10)
“高可用性”的一些非功能性要求是 映射到名为“提供高可用性”的用例,标记为 &LT;&GT;
俗话说,“如果你拥有的唯一工具是锤子,那么每个问题看起来都像钉子一样”。存在用例以识别系统为其用户提供的值。因此,它们的目的是描述功能性的东西:系统所做的事情。
所以我一般不建议以这种方式捕获非功能。但是:这并不是说在用例中无法捕获它们。在功能用例中非常有用,可以指定它们的非功能性需求。例如:
Use Case: Submit Order
{...functional description...}
Availability: 9-5 mon-fri
Volumes: 5000 peak per day
...
将非功能性需求直接与其支持的功能联系起来。这是有道理的 - 因为非功能没有功能没有目的或背景。
当然,您会发现许多用例共享相同的非功能。你不想复制,所以需要找到一种方法来分解。我更喜欢在单独的文件中这样做。
但是没有法律禁止捕获“用例”。虽然它违反了理论,但在实践中有理由这样做:例如:建模工具的局限性(无法将UCs链接到文档)和/或希望将所有内容保存在一个位置。
从根本上讲,它归结为理论和实践。从理论上讲,没有非功能性用例。在实践中,创建一个UC以保持非功能可能是有道理的。只要每个人都明白它真的只是一个方便的容器而不是一个真正的功能,我就不会对它有所了解。
第h