2011-03-21 63 views
2

我知道有些網站是應用程序,但並非所有網站都應用(雖然也許只是一本小冊子,觀看網站)'使用案例'情景適用於網站設計嗎?

是否有一個深入的假人用例一本小冊子類型的網站這將是有益的使用。

當涉及到企業的前置網站例如我從功能失明痛苦,雖然實際的數據庫驅動的應用程序(例如採購訂單系統)我覺得我的元素中。

有什麼資源,可以幫助我查看相同的光比我做的一個公益數據庫驅動的應用程序「手冊」的網站。

+0

「小冊子瀏覽網站」是否僅限於2個用例? 「查看可供選擇的網頁列表以查看」,「查看小冊子/頁面」?只是我的想法... – Bazzz 2011-03-21 10:09:46

+0

這正是我在想什麼,這就是爲什麼我覺得很難轉換某人在excel電子表格中編寫的網站的解釋,有人需要轉換爲crm或定製的應用程序的例子。 – 2011-03-21 10:36:32

+0

也許你應該模擬你的2個用例,並與客戶討論它們,看看他們給出了什麼樣的反饋。我認爲嘗試添加不符合客戶認知理解網站應該如何工作的案例是沒有用的。如果客戶不想要這些功能,那麼您患有功能失明並不是那麼糟糕。 – Bazzz 2011-03-21 11:47:30

回答

0

用例可以用來模擬系統的需求。系統是一個具有輸入和輸出映射的結構。所以如果你有一個靜態的網頁,你不能以其他方式與它進行交互而不是查看它。

正如評論所討論的,如果你認爲你沒有了解利益相關方的目標(由你的老闆換貨......送什麼word文檔),你要問更去找他們,用例是一個很好的技術爲了這。

在一個週期內,發現演員(系統和角色與您要開發系統進行交互)和用例(這些行動者開發的系統應該ssatisfy的哪些方面需要)。每當你找到一個演員時,你可能會問他有什麼其他需求(可能的用例),當你找到一個用例時,你應該問誰將參與其中,誰對它感興趣(誰是下一個演員,誰是誰是利益相關者)。然後你可以定義範圍邊界和優先級...

+0

我同意你的看法,你必須向人們展示你的意思,並教導客戶創建可定義的需求,而不是長時間的電子郵件與衝突的想法。 – 2011-03-31 09:52:09

1

這真的很有用的線程。儘管完全支持使用UML,但我總是覺得在UX代理輸出&之間嘗試確保整個需求規範聯繫在一起,特別是當代理傾向於不使用UML時,我總是與小冊子站點的用例進行對抗。

有那些應用不僅僅是查看菜單/圖冊頁幾個用例 - 網站功能,例如打印頁面,搜索網站等,有時接受cookie來查看具體內容 - 但沒有太多的經典宣傳冊式。 (全是關係順利進入用戶的旅程/人物角色,而不必重述UX交付),

但是使用一旦系統如CMS創建網站的內容 - 那麼我想用例得到正確有用的(按評論因爲不僅有(通常)多個參與者加入系統,而且每種內容類型都有不同的情況,因此您可以參考這些UX可交付成果而不重複,並開始填補空白,並加上內容戰略類型可交付成果(例如工作流通過查看業務流程和系統/用戶交互來實現治理)。在&規範的建模結束時,您可以通過這種方式獲得有用的測試矩陣;以及將對象與分類法相關聯的類圖(在Functional Rqmts/Specs階段將更多機構可交付成果結合在一起)。

這就是我想這些天來對付它的辦法。