问题标签 [use-case]

假设作为系统一部分的调度程序负责每周向用户发送电子邮件。应该将“调度程序”视为参与者还是应该将其建模为用例？

选择演员的指南说：如果：它是与您的系统交互的真实人。如果“是”它是一个演员 Else：它是你可以在系统内改变的东西吗？如果“不”是演员

调度员不是人。你可以改变它的运作方式。但我的直觉告诉我，这可以是一个演员。一点帮助会很棒。

您使用什么工具来编写用例，为什么？

您是否使用通用文字处理器 (Word/OpenOffice)、Wiki、专用工具 (fe Visual Use Case ) 或其他工具？

您肯定熟悉 UML 类图和对象图及其关系。对象图用于对系统中的对象及其关系进行建模，对于基于类的面向对象编程语言，这意味着对不同类的具体对象进行建模。

在开展项目时，我必须创建用例（图表）和角色（如在用户体验设计中），我认为它们与类和对象具有相同的关系 - 实例（实例）。此外，统一流程（在某种程度上与 UML 耦合）中所理解的用例是具有一个主要场景（流）的场景集。所以具体的场景，例如在行为驱动开发中是一个用例的实例。

你认为这有意义吗？您是否喜欢 UML 中用于建模角色和用户场景的用户场景图，它可以用于生成用户接受测试，如在 BDD 中？

我正在编写产品需求规范。在本文档中，我必须描述用户与系统交互的方式非常高级。其中一些操作是对某些对象的“创建-读取-更新-删除”。

问题是，在为这些操作编写用例时，正确的做法是什么？我可以只编写一个名为“管理对象 x”的用例，然后将这些操作作为包含的用例吗？还是我必须为每个操作、每个对象创建一个用例？我看到最后一种方法的问题是我会写很多我觉得对理解问题没有真正贡献的页面。

最佳做法是什么？

我在乞求一个新项目（哦，我多么喜欢一个新项目的新鲜味道！）我们才刚刚开始设计它。简而言之：应用程序是一个 UI，使用户能够对执行流程进行建模（类似于 Visio 的拖放界面）。所以我们最关心的是可用性和特性，它们将帮助用户快速清晰地建模执行流程。

我们建立的方法广泛使用用例，以便在程序员和用户之间创建和谐的应用程序视图。这是一个商业问题，真的：我更喜欢使用带有用户故事而不是用户案例的敏捷方法，但我们需要定义一个明确的范围来向我们的客户销售产品。

但是，用例有许多缺陷，其中大部分与它们包含技术细节（如 UI 等）这一事实有关，如这里所示。但是，由于我们不能使用用户故事和完全交互的设计，我决定妥协：我将使用基本用例来隐藏这些细节。

现在我有另一个问题：对 UI 交互有一个清晰的描述是必不可少的（不是双关语），那么，我应该如何记录它？换句话说，我如何通过使用 UI 交互对其至关重要的基本用例来指定应用程序？

我可以看到一些替代方案：

• 放弃使用用例，因为它们不能正确地代表问题
• 不要在用例中包含接口描述，而是创建另一个文档（故事板）并链接到基本用例
• 在基本用例中包含 UI 交互描述，因为从用户和应用程序本身的角度来看，它们是业务规则的一部分

我想设计我的程序

替代文字 http://img405.imageshack.us/img405/331/helpq.jpg

用例之间的关系呢？

这是我的用例对吗？

我对使用用例图作为收集用户需求的工具很感兴趣。但是，它将针对新功能，而不是从头开始开发系统。此外，系统只有少量的用户交互——大多数参与者都是外部系统。

我想知道人们使用这种收集需求的方法的经验。您的客户对这一变化有何反应，是否积极？它对任何人都不起作用吗？

谢谢，

我正在为一个新系统制作一个用例图。我想知道什么时候应该将系统作为参与者包含在用例图中？

谢谢。

用例和 SRS 有什么区别？

如果参与者参与通用用例，他是否参与专门用例？我认为不，考虑到多态性的类比，父对象指针可以指向子对象，反之亦然。

我知道反过来是正确的（如果参与者参与专门的用例，他也参与通用用例）。