“用例”场景是否适用于网站设计？

Question

我知道某些网站是应用程序，但并非所有网站都是应用程序（尽管可能只是一个小册子查看网站）

是否有适合使用的小册子类型网站的深度虚拟用例。

当涉及到面向企业前端的网站时，我遭遇功能失明，尽管对于实际的数据库驱动的应用程序（例如采购订单系统），我感觉在我的元素中。

是否有任何资源可以帮助我以与使用无偿数据库驱动的应用程序相同的方式查看“宣传册”网站。

Answer 1

这是非常有用的线程。我一直在与小册子网站的使用案例作斗争，尽管完全支持UML的使用......我经常感到被困在UX代理商输出和＆amp;试图确保整个需求规范在一起，特别是当代理商不使用UML时。

有几个用例适用于视图菜单/视图手册页之外 - 网站功能，如打印页面，搜索网站等，有时会接受cookie来查看特定内容 - 但在经典宣传册上并不多。 （所有这些都与用户旅程/人物角色紧密相关，而无需重述用户体验的可交付成果）

然而，一旦使用系统（例如CMS）来创建网站内容 - 那么我认为用例得到了适当的用途（根据上面的评论），因为系统中不仅（通常）有几个参与者，而且每种内容类型的不同情况，因此您可以引用这些UX可交付成果而不会重复并开始填补空白，并通过查看业务流程和系统/用户交互来捆绑内容策略类型可交付成果（例如工作流和治理）。在建模和结束时规范，您可以通过这种方式获得有用的测试矩阵;加上将对象与分类法相关联的类图（更多的机构可交付成果，以便在Functional Rqmts / Specs阶段联系起来）。

这就是我现在试图解决的问题。

Answer 2

用例可用于建模系统的要求。系统是具有输入和输出映射的结构。因此，如果您有一个静态网页，则无法以其他方式与其进行交互，而不是查看它。

正如评论中所讨论的，如果你认为你不理解利益相关者的目标（你的老板发送的那个单词文件......），你必须要求更多并找到它们，用例是一种很好的技巧。此

在一个循环中，发现参与者（与您必须开发的系统交互的系统和角色）和用例（开发系统应该满足的那些参与者的需求）。每当你找到一个演员时，你可能会问他有什么其他需求（可能的用例），当你找到一个用例时，你应该问谁将参与其中以及谁对它感兴趣（谁是下一个演员和谁是利益相关者）。然后，您可以定义范围边界并确定优先级......