用例，有時候也叫做需求場景

用例，有時候也叫做需求場景。

用例，有時候也稱之為需求場景，是描述使用者將如何與網站互動的故事或者序列圖解。有些人也將它用於任務分析或者使用者流。不管你如何稱呼它們，概念是一樣的。用以說明使用者即將進行的人物場景或者具體的工作。所以可交付物的名稱是相對自我描述的。一個（學習）使用者或者場景的事件。聽起來沒有問題。

需求場景能確認具體的工作或者大多數普遍的概念和使用方式。例如，如果雅虎的資訊架構師（IAs）正在建立簡單的用例，其中一個可以說明下面的場景。

一個使用者開啟他們的火狐瀏覽器然後瀏覽他們的主頁——Yahoo.com。使用者檢視主頁上的個性化的新聞大標題。他們繼續往下滾動去檢視他們當地的天氣預報。然後，使用者點選金融連結去檢視他們持有的股票。再然後...

這是一個沒有太多意義的一般性的例子，但是這些場景的型別對於資訊架構師和設計師來說卻是有意義的。更多的用例細節能夠告訴我們很多的用法和導航方式。

建立需求場景在資訊架構師和設計師設計新網站時是很有用的。如果場景是準確無誤的，它將幫助網站團隊去了解網站將如何被使用者使用。有效的需求分析，使用者和客戶端的訪問，以及觀察報告將會幫助引匯出準確的用例。

當你在閱讀用例的時候，可以透過“角色”或者“外部代理”的說法。這裡也有常用的其他方式用於特殊的使用者，但是也可能意味著其他的體系。

我需要多少個網站用例？

這取決於你所開發的網站的規模和範圍。也取決於你的預算。對於小預算的專案——常規的用例規範會超出範圍。當時間和金錢都允許的時候，相當多的規範或者很多的場景將會對專案團隊非常有價值。而在實際的規範會是什麼樣子方面會有很多變數。

真實和基本的用例

用例會獨立於技術說明書（即程式語言，服務，資料等）。或者它們會包含技術說明書。這些變化作為基本的用例和真實的用例的區別。從根本上說，模型是高階別的說明了普遍概念的場景。而後者牽涉更多的網站具體的細節。

透過其他的交付物使用用例

如果你是熟悉建設網站的需求和交付物的人，你會明白用例和使用者特徵（人物外貌）之間的天然的聯絡。在特徵中包含需求場景會很有用。這個方法告訴那些閱讀文件的人——一個目標使用者的快速印象，以及對他們的網路習慣的總的看法，還有一些簡單的使用場景。

如果你是在可用性測試中有經驗的人，你會看到用例和可用性測試工作之間的聯絡。有些會衝突而無法產生聯絡，但是如果你花費一些時間並且努力的發展現實的需求場景，就如他們會很好的轉化了具體的可用性測試工作一樣。舉例來說，一個用例可能會描述如何引導雅虎使用者到金融財政版塊以及進行一個股票的報價查詢。為什麼不像可用性測試所涉及的工作那樣使用場景。結果有可能或者可能沒有去支援你的用例。