說明：
1、這裡的用例指的是需求用例，不是設計用例；
2、引入「需求用例」目的在於核心功能的補充描述；
3、核心功能最好的描述方式仍然是語言文字；
概要：
需求用例的使用會有很多誤區，即便是老手也容易出現問題！如果剛開始接觸需求分析、撰寫《需求規格說明書》或起步從事業務需求分析工作，那麼業務需求用例會是乙個好的工具。需要強調的是，它只是乙個輔助工具而已，用的不好對專案發展時有阻礙作用的；
具體內容，如下：
1、業務用例想當然
我看到有人用這樣乙個用例圖來做案例，一眼感覺很彆扭，一時說不出問題出在**。
索性我自己根據內容畫了乙個，如下：
對系統管理員來說：分類管理與使用者管理是乙個層級上的；而作者及讀者也同樣會存則資訊分類的問題；
所以把握用例的層次非常重要！
2、用例分析過度
用例分析的目的我們說啦，是為了對核心功能做補充；在用例的基礎上核心功能目標概念清晰了即可；如下：
首先，上圖整體看上去有點嚇人了。東西太多，誰能一下看清楚？而且上面的用例是可以合併的；
因此，上圖是過度的業務用例；
插一句牢騷話：
專案分析階段，我寧可用繪製上圖的分析人員，也不會去用滿嘴空談的「高手」、「行業專家」， 一切從實際出發，對專案有意義的彎路可以走！
3、正確識別用例的標準-從用例標準入手
上圖中的幾個錯誤
1、所有的維護項都應該從新描述；
2、維護管理員登入許可權，應該被定義為更新管理員許可權與檢視管理員許可權；
修改上圖如下：
結論：1、業務用例不是設計用例；
2、業務用例是描述使用者對系統的操作，不應包括系統自身實現的造作；
3、業務用例的修辭要準確，使用者一眼看不懂、詞彙模糊的用例是無效的用例；
4、沒有業務用例定義的標準的用例，都是沒有價值的用例；
5、增刪改(更新)不是乙個用例，是系統必須做出的機器操作（「序列項」）；
６、查詢是乙個「序列項」，與更新不同的是，在這個用例中即使沒有也可以；如：更新管理員許可權，不一定非要查詢；
附錄：我的規格描述模板
（完）
需求規格說明書
團隊專案之需求規格說明書 任務描述 根據需求分析階段性成果物 編制完整的需求規格說明書 任務目的 一方面鍛鍊需求分析文件編寫能力，另一方面通過對內容評價，掌握需求分析方法 引言部分及階段報告 葉鴻 主要 其他成員參與討論 專案概述部分 張瑞源 主要 其他成員參與討論 功能需求部分 童子銘 主要 其他...
python需求分析說明書 需求規格說明書
1 概述 summary 1.1 專案的目的與目標 purpose and aim of project 學員體能成績管理系統需求說明書是為了讓系統的涉眾就該系統的需求達成一致認可，明確該系統的需求，為後續的開發工作提供依據。通常，該需求規格說明可以作為產品設計的主要依據，並作為程式設計師編碼時了解...
軟體需求規格說明書
在整理完與使用者的談話稿，交付使用者審閱後，下一步是制定軟體需求規格說明書了，貌似和客戶簽約需要依據這份規格說明書，一旦確定，雙方達成協議簽字後，使用者如需更改增加功能是需要再付費的。主要內容有 1.簡介 1.1 目的 1.2 應用範圍 1.3 術語及縮寫定義 2.全面描述 2.1 系統用例圖 2....