“用例”场景可以应用于网站设计吗？

Question

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

对于小册子类型的网站是否有一个深入的虚拟用例，这将有助于使用。

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

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

Answer 1

这是一个非常有用的线程。尽管我完全支持使用 UML，但我一直在与小册子网站的用例作斗争……我经常感到夹在 UX 机构输出和试图确保整个需求规范联系在一起时，尤其是当机构倾向于不使用 UML 时。

有几个用例确实适用于查看菜单/查看小册子页面 - 站点功能，如打印页面、搜索站点等，有时接受 cookie 来查看特定内容 - 但在经典小册子软件上并不多。 （所有这些都与用户旅程/角色密切相关，而无需重申 UX 可交付成果）

但是，一旦使用系统（例如 CMS）来创建网站内容 - 然后我认为用例会变得非常有用（根据上面的 cmets），因为系统不仅（通常）有几个参与者，而且每种内容类型都有不同的案例，因此您可以参考这些 UX 可交付成果而无需重复，并开始填补空白，并通过查看业务流程和系统/用户交互来整合内容策略类型的可交付成果（例如工作流程和治理）。在建模和规范结束时，您可以通过这种方式获得有用的测试矩阵；加上将对象与分类法相关联的类图（在功能性 Rqmts / Specs 阶段将更多的机构可交付成果结合在一起）。

这就是我最近尝试解决的方法。

Answer 2

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

正如 cmets 中所讨论的，如果您认为您不了解利益相关者的目标（您的老板发送的那个 word 文档是什么......），您必须多问并找到他们，用例是一种很好的技术这个。

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