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