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

EN

用例可以用来对系统的需求进行建模。系统是一个具有输入和输出映射的结构。因此，如果你有一个静态网页，你不能以其他方式与它交互，只能查看它。

正如评论中所讨论的，如果你认为你不理解涉众的目标(你的老板政府发送了什么word文档...)，你必须问更多并找到他们，用例是一个很好的技术。

在一个周期中，发现参与者(与您必须开发的系统交互的系统和角色)和用例(开发的系统应该满足这些参与者的哪些需求)。每次你找到一个参与者，你可能会问他有什么其他需求(可能的用例)，当你找到一个用例时，你应该问谁将参与其中，谁对它感兴趣(谁是下一个参与者，谁是涉众)。然后您可以定义作用域边界并确定优先级...

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

有几个用例确实适用于查看菜单/查看宣传册页面之外的站点功能，如打印页面、搜索网站等，有时接受cookie来查看特定内容-但不太适用于传统的宣传册-软件。(所有这些都与用户行程/角色很好地联系在一起，而不必重新说明UX可交付内容)

然而，一旦使用系统，例如CMS来创建网站内容-那么我认为用例变得非常有用(根据上面的评论)，因为系统中不仅(通常)有几个参与者，而且每个内容类型也有不同的情况，所以您可以引用这些UX交付件而不重复，并开始填补空白，并通过查看业务流程和系统/用户交互来捆绑内容策略类型的交付件(例如工作流和治理)。在建模和规范的末尾，您可以通过这种方式获得有用的测试矩阵；外加将对象与分类相关联的类图(更多代理交付内容将在Functional Rqmts / Specs阶段绑定在一起)。

这就是我最近想要解决的问题。