產品用例怎麼寫

概念

     用例(Use Case)是一種描述產品需求的方法,使用用例的方法來描述產品需求的過程就是用例模型,用例模型是由用例圖和每個用例的詳細描述文檔所組成的。在技術和產品的工做領域裏都有用例模型的技能知識。技術人員的用例主要是爲了方便在多名技術人員協同工做,或者技術人員任務交接時,讓參與者更好的理解代碼的邏輯結構。產品人員的用例主要是爲了方便技術研發和功能測試時,讓參與者更好的理解功能的邏輯。安全

起源

      用例起源和發展於軟件時代的產品研發,後來被綜合到UML規範之中,成爲一種標準化的需求表述體系。雖然用例在軟件研發和技術工做中應用的很是普遍,可是在互聯網產品規劃和設計中,並不常用,互聯網產品的需求表達爲了敏捷效率,一般採用原型加產品需求文檔。工具

      UML是英文Unified Modeling Language的縮寫,中文稱爲統一建模語言或標準建模語言,是用例模型的建模語言,經常使用工具是Microsoft Office Visio。產品用例是一種經過用戶的使用場景來獲取需求的方式,每一個用例提供了一個或多個場景,該場景說明了產品是如何和最終用戶或其它產品互動,也就是誰能夠用產品作什麼,從而得到一個明確的業務目標。測試

分類

① 用例圖

     用例圖並非畫成了圖形的用例。用例圖包含一組用例,每個用例用橢圓表示,放置在矩形框中;矩形框表示整個系統。矩形框外畫如圖所示的小人,表示參與者。參與者不必定是人,能夠是其它產品、軟件或硬件等等。某一參與者與某一用例用線連起來,表示該參與者和該用例有交互。spa

      許多人經過UML認識了用例,UML定義爲展示用例的圖形符號。UML並非爲描述用例定義書寫格式的標準,所以許多人誤認爲這些圖形符號就是用例自己;然而,圖形符號只能給出最簡單的一個或一組用例的概要。UML是用例圖形符號最流行的標準,可是除了UML標準,用例也有其它的可選擇的標準。設計

② 用例描述文檔

     用例圖只是在整體上大體描述了產品所能提供的各類服務,讓咱們對於產品的功能有一個整體的認識。除此以外,咱們還須要描述每個用例的詳細信息,這些信息應該包含如下內容:orm

用例名稱:本用例的名稱或者編號開發

行爲角色:參與或操做(執行)該用例的角色文檔

簡要說明:簡要的描述一下本用例的需求(做用和目的)原型

前置條件:參與或操做(執行)本用例的前提條件,或者所處的狀態產品

後置條件:執行完畢後的結果或者狀態

      用例描述文檔基本上是用文本方式來表述的,爲了更加清晰地描述用例,也能夠選擇使用狀態圖、流程圖或序列圖來輔助說明。只要有助於表達的簡潔明瞭,就能夠在用例中任意粘貼用戶界面和流程的圖形化顯示方式,或是其它圖形。如流程圖有助於描述複雜的決策流程,狀態轉移圖有助於描述與狀態相關的系統行爲,序列圖適合於描述基於時間順序的消息傳遞。

      在互聯網產品和設計中,用例的使用愈來愈少,一般有了產品原型再加上功能流程圖和功能說明文檔就可以將產品需求詳細的表述清楚,因此也沒有必須撰寫用例了。可是在大公司裏,每每會追求產品流程的規範性,要求撰寫用例,不過在敏捷開發的時候也會採用其它更有效率的方式,不必定非要撰寫用例。

產品用例怎麼寫

      用例圖描述了系統提供的一個功能單元。用例圖的主要目的是幫助開發團隊以一種可視化的方式理解系統的功能需求,包括基於基本流程的"角色"(actors,也就是與系統交互的其餘實體)關係,以及系統內用例之間的關係。用例圖通常表示出用例的組織關係--要麼是整個系統的所有用例,要麼是完成具備功能(例如,全部安全管理相關的用例)的一組用例。要在用例圖上顯示某個用例,可繪製一個橢圓,而後將用例的名稱放在橢圓的中心或橢圓下面的中間位置。要在用例圖上繪製一個角色(表示一個系統用戶),可繪製一我的形符號。角色和用例之間的關係使用簡單的線段來描述

相關文章
相關標籤/搜索