可以“使用案例”场景适用于网站设计吗？
我知道有些网站是应用程序，但并非所有网站都是应用程序（尽管可能只是一个小册子查看网站）
是否有一个小册子类型网站的深入虚拟用例，这将有利于使用。
例如，当涉及到企业前端网站时，我会遭受功能盲目性的困扰，尽管对于实际的数据库驱动的应用程序（例如采购订单系统），我感觉自己在自己的元素之内。
是否有任何资源可以帮助我以与无偿数据库驱动应用程序相同的方式查看“宣传册”网站。
I know that some website are applications, but not all websites are applications (albeit maybe just a brochure viewing site)
Is there an in depth dummy use case for a brochure type site which would be beneficial to use.
When it comes to a corporate front facing website for example I suffer from feature blindness, although for an actual database driven application (for example a purchase order system) I feel within my element.
Is there any resources that can help me view "brochure" sites in the same light than I do with a pro bono database driven applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是非常有用的线程。尽管我完全支持使用 UML，但我一直在与小册子网站的用例作斗争……我经常感到陷入了 UX 机构输出和用户体验机构输出之间的困境。试图确保整个需求规范联系在一起，特别是当机构倾向于不使用 UML 时。
有几个用例确实适用于查看菜单/查看小册子页面之外的情况 - 站点功能，如打印页面、搜索站点等，有时接受 cookie 来查看特定内容 - 但在经典小册子软件上并不多。 （所有这些都与用户旅程/角色密切相关，而无需重述 UX 可交付成果）
但是，一旦使用系统（例如 CMS）来创建网站内容 - 那么我认为用例会变得非常有用（根据上面的评论），因为系统中不仅（通常）有多个参与者，而且每种内容类型都有不同的情况，因此您可以参考这些用户体验可交付成果而无需重复并开始填补空白，再加上绑定内容策略类型可交付成果（例如工作流程和治理）通过研究业务流程和系统/用户交互。在建模结束时规范，您可以通过这种方式获得有用的测试矩阵；加上将对象与分类法相关联的类图（更多机构可交付成果在功能需求/规格阶段结合在一起）。
这就是我这些天试图解决这个问题的方法。
This is really useful thread. I have always battled with use cases for brochure sites, despite totally espousing the use of UML... I often feel caught between UX agency outputs & trying to ensure the whole Requirements Spec ties together, especially when agencies tend not to use UML.
There are several use cases that do apply beyond view menu / view brochure page - site functionality like print page, search site etc, sometimes accept a cookie to view specific content - but not much on classic brochure-ware. (All that ties well into user journeys / personas without having to restate the UX deliverables)
However, once using a system eg a CMS to create the website content - then I think the use cases get properly useful (as per comments above), as there are not only (usually) several actors inc the system, but also varying cases per content type so you can reference those UX deliverables without duplication and start filling in the gaps, plus tie up content strategy type deliverables (eg workflow & governance) by looking into the business processes and the system / user interactions. At the end of the modelling & specifications, you can get useful test matrices this way; plus class diagrams that relate objects to taxonomies (more agency deliverables to tie together in Functional Rqmts / Specs stage).
That's the way I'm trying to tackle it these days.
用例可用于对系统的需求进行建模。系统是一个具有输入和输出映射的结构。因此，如果您有一个静态网页，除了查看之外，您无法以其他方式与其进行交互。
正如评论中所讨论的，如果您认为您不理解利益相关者的目标（您老板发送的文字文档是什么......），您必须询问更多并找到他们，用例是一个很好的技术。
在一个周期中，发现参与者（与您必须开发的系统交互的系统和角色）和用例（开发的系统应该满足这些参与者的哪些需求）。每次你找到一个演员时，你可能会问他还有什么其他需求（可能的用例），当你找到一个用例时，你应该问谁会参与其中，谁对此感兴趣（谁是下一个演员以及谁）是利益相关者）。然后您可以定义范围边界并确定优先级......
Use Cases can be used to model requirements of a system. System is a structure with input and output mappings. So if you have a static web page, you cannot interact with it in a other way than to view it.
As discussed in comments, if you think you did not understood the goals of stakeholders (what that word document sent by your boss ment...), you have to ask more and find them, use cases are a good technique for this.
In a cycle, discover actors (systems and roles interacting with the system you have to develop) and use cases (what needs of those actors the developed system should ssatisfy). Every time you find an actor, you may ask what other needs (possible use cases) he has and when you find an use case, you should ask who will participate in it and who is interested in it (who is the next actor and who are the stakeholders). Then you can define the scope boundaries and prioritize...