用例，有时候也叫做需求场景

用例，有时候也叫做需求场景。

用例，有时候也称之为需求场景，是描述用户将如何与网站互动的故事或者序列图解。有些人也将它用于任务分析或者用户流。不管你如何称呼它们，概念是一样的。用以说明用户即将进行的人物场景或者具体的工作。所以可交付物的名称是相对自我描述的。一个（学习）用户或者场景的事件。听起来没有问题。

需求场景能确认具体的工作或者大多数普遍的概念和使用方式。例如，如果雅虎的信息架构师（IAs）正在建立简单的用例，其中一个可以说明下面的场景。

一个用户打开他们的火狐浏览器然后浏览他们的主页——Yahoo.com。用户查看主页上的个性化的新闻大标题。他们继续往下滚动去查看他们当地的天气预报。然后，用户点击金融链接去查看他们持有的股票。再然后...

这是一个没有太多意义的一般性的例子，但是这些场景的类型对于信息架构师和设计师来说却是有意义的。更多的用例细节能够告诉我们很多的用法和导航方式。

建立需求场景在信息架构师和设计师设计新网站时是很有用的。如果场景是准确无误的，它将帮助网站团队去了解网站将如何被用户使用。有效的需求分析，用户和客户端的访问，以及观察报告将会帮助引导出准确的用例。

当你在阅读用例的时候，可以通过“角色”或者“外部代理”的说法。这里也有常用的其他方式用于特殊的用户，但是也可能意味着其他的体系。

我需要多少个网站用例？

这取决于你所开发的网站的规模和范围。也取决于你的预算。对于小预算的项目——常规的用例规范会超出范围。当时间和金钱都允许的时候，相当多的规范或者很多的场景将会对项目团队非常有价值。而在实际的规范会是什么样子方面会有很多变数。

真实和基本的用例

用例会独立于技术说明书（即编程语言，服务，数据等）。或者它们会包含技术说明书。这些变化作为基本的用例和真实的用例的区别。从根本上说，模型是高级别的说明了普遍概念的场景。而后者牵涉更多的网站具体的细节。

通过其他的交付物使用用例

如果你是熟悉建设网站的需求和交付物的人，你会明白用例和用户特征（人物外貌）之间的天然的联系。在特征中包含需求场景会很有用。这个方法告诉那些阅读文档的人——一个目标用户的快速印象，以及对他们的网络习惯的总的看法，还有一些简单的使用场景。

如果你是在可用性测试中有经验的人，你会看到用例和可用性测试工作之间的联系。有些会冲突而无法产生联系，但是如果你花费一些时间并且努力的发展现实的需求场景，就如他们会很好的转化了具体的可用性测试工作一样。举例来说，一个用例可能会描述如何引导雅虎用户到金融财政版块以及进行一个股票的报价查询。为什么不像可用性测试所涉及的工作那样使用场景。结果有可能或者可能没有去支持你的用例。