帮助决定用例图部分
我发现用例图中每个椭圆形/椭圆形元素的详细程度令人困惑。我觉得我应该将我看到的每个流程都做成椭圆形，但是当我查看示例时，他们并不总是这样做，而是在流程描述中详细说明了它们。我不明白如何将其分开。
例如，这是我要制定的要求：
- 用户应该能够根据安全权限为自己或其他用户创建和分配注释。
- 搜索可以按描述和主题进行搜索，然后仅显示匹配的注释。
- 需要能够向笔记添加附件。
我个人只创建了 2 个椭圆 ()。它们是（创建注释）和（搜索注释）。
我是否应该也有一个椭圆形（添加附件到注释），或者仅在流程描述中描述。
我是否应该在椭圆形中详细说明用户可以通过描述和主题进行搜索，或者是否再次在流程中进行描述。
我想您可以看到我对应该制作用例图的详细程度感到困惑。我无法完全区分它应该处于什么水平。
请帮忙。 谢谢
I am finding it confusing about how detailed each oval/elliptical element should be in a Use Case diagram. I feel like i should be making each process i see as an oval, but then when i look at examples, they don't always do that, and instead detail them in the flow description. I can't understand how to separate this.
For example, here is my requirement to map out:
- A user should be able to create and assign a Note to himself or another user, depending on security privileges.
- The search can search by description and subject and then display only those Notes that match.
- The ability to add attachments to a note is needed.
Personally i created only 2 ovals (). They are (Create Note) and (Search Note).
Should i also have an oval for (add attachment to note), or is that only described in the flow description.
Should i detail in the ovals that the user can search by description and subject, or is that again, described in the flow.
I guess you can see that i'm confused at how much detail i should make the Use Case diagram. I can't quite separate at what level it should be.
Please help.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
嗯，
作为一项规则，请保持用例图简单。它应该总体概述用户可以使用正在设计的系统做什么。详细信息通过书面用例捕获：文本故事，广泛用于发现和记录需求。实际上，书面用例比用例图更重要。
您的用例图中应该包含多少细节？不多...真正的问题是用例描述中应该包含多少详细信息？ （书面用例）...我对此没有“煮熟即可食用”的答案。但是 Kevin Bittner 写了一篇不错的文章：管理用例详细信息检查此链接< /a>
顺便说一句，不要在用例图上花费太多时间。关注实际用例（书面用例）而不是椭圆形用例。
Well,
As a rule keep your use case diagram simple. It should give generall overview of what a user can do with your system under design. Details are captured by written Use Cases: text stories, widely used to discover and record requirements. Actually, written use cases are more important than use case diagrams.
How much details should be in your use case diagram? Not much...The real question is how much details should be in Use Case Description? (written use cases)....I have no "cooked ready for eat" answer for this. But there is nice article by Kevin Bittner : Managing use-case detail Check this link
By the way, do not investigate too much time with Use Case Diagrams. Focus on real use cases(written ones) not the oval shape one.