我试图为我的项目定义用例。问题是我不确定如何有效地定义用例，它看起来非常混乱。
例如我的用例如下。我觉得＆＃39;查看个人资料＆＃39;，＆＃39;查看俱乐部＆＃39; ＆＃39;查看工作坊＆＃39;有必要包括因为常识＆＃39;用户可以单击某个配置文件进行查看。那么我真的需要定义这样的用例吗？
答案 0 :(得分：2)
是的，合成用例很困难。通常人们会尝试使用大量的include / extend来描述功能部件，以显示正在考虑的系统。但实际上用例与功能无关。它们是附加值。因此，如果你坐下来思考哪些泡泡确实代表了附加价值，你会发现Request repair service，Make appointment和Manage club是真正的候选人，而其他大多数只是技术用具。 Manage <x>有点边缘。我最终在这里使用CRUD，这是4个用例，因为它们用于不同的上下文，通常是不同的actor。在综合用例时，只要问问自己：它是否会增加价值。仅当答案为是时，将其添加为用例。否则，您有一些技术操作序列甚至更简单的约束（例如Login）。
答案 1 :(得分：0)
您需要定义实现目标所需的所有案例。一般来说，如果在View Workshop＆＃39;中有重要的事情。将它写在纸上或传递给某人 - 你必须写它。
Ihsan Ramli，虽然你的问题是＆＃34;我不确定如何有效地做某事％＆＃34;并假设您无法将任务交给其他人 - 为什么不学习更多相关信息呢？您可以从几本广受推荐的书籍开始，例如Alistair Cockburn的Writing Effective Use Cases。句子喜欢＆＃34;因为......让用户点击某个个人资料来查看它＆＃34;由于用例代表了行为要求，并且与实现和设计脱节，因此立即点亮一个红色灯泡（但必要时可以并且应该参考它们）。
有关您的图表的一些评论：
