編寫了那麼多的用例，那用例到底是幹嘛的？用例為管理者指明應提交給使用者的系統功能。用例的標題指明主執行者的需求，同時系統也必須支援這些需求，而用例描述則說明了系統需要什麼功能以及將提供什麼服務。
在一開始接觸用例的時候，uml課程中提及過用例的優先順序以及用例版本號等其他細節，對於這些資訊的彙總可以稱為規劃表，而規劃表在專案開發過程中，可以非常容易的對這張表進行審核和操作。另外，可以對每個用例進行評估，指定用例開發組，以及對每個用例，每個版本的工作進行跟蹤。
在編寫用例的過程中，出錯是非常正常的，而發現錯誤和會改正錯誤的這一步時非常正常的。那麼，**會經常出問題？怎麼修改？這是乙個很重要的環節，十九章就給出了當用例缺少系統、主執行者、過多的使用者介面、過低的目標級別等問題出現的時候，相對應的解決辦法。
雖然本書第二部分內容不多章節也少，但是都對編寫用例經常會遇到的問題，提供了相應的解決辦法和理論依據。由於大多例子都是依附於案例的，全都搬到筆記裡並不適合，因此，只留下了一些理論的依據和緣由，並未展開詳細講解。
由此，很快的進入了本書的第三部分「對忙於編寫用例的人的提示」。看到標題應該就可以猜到這部分是給「光幹活不注意細節的人」的人看的。哈哈，比如我。上次寫一分課後作業，寫了好半天，回頭一翻，竟然還寫錯內容了!真真是白白忙活。編寫用例也是一樣的，與其花很多時間捉摸研究，不如，先跳出來好好看看，看看自己可能會遇到的問題，再進入其中研究相關問題。
在一開始學用例的時候，我們第乙個接觸的便是用例圖，後面才是使用的語言描述，我們總覺得，學工科的東西，表述的越簡單越好，但是，用例卻應該是一篇散文，易於閱讀，但是又要富有美感。那麼多人在學習，肯定不是所有的人都喜歡閱讀的，所以，讓別人能夠看得下去，第乙個點就是讓問題短小而切題，並且從頭開始，用一條主線貫穿始終。跟寫作文一樣，用例是是要起因經過結果的，並且遵循主旨。而且，為了讓問題短小精悍，就要使用動詞短語來命名用例，然後從觸發事件開始，至到目標實現或者被取消，用例才可能結束。其餘的相關的細節過多，就不一一闡述了，但是，不說不代表重要，所有的細節都是重點。頂層的散文故事，只是一部分，而後續需要不斷展開的故事，就像寫故事背景一般，故事的開始不僅僅是乙個開始，還是乙個又乙個的故事。而且寫故事的時候不能跑題，一定要記得自己原有的業務範圍和業務邊界，儘管這個邊界某種程度上來說十分的模糊，但是卻又不得不去區分。
《編寫有效用例》閱讀筆記05
用例在整個過程中的作用是什麼呢？首先說什麼是用例，用例是用來描述業務功能的，但用例圖卻不僅僅是角色和用例的堆積，首先，用例是有層次概念的，乙個大的用例可以用更小的多個用例來細化，直到無需再細分為止 乙個用例的執行是要有前因和後果的 前提是什麼，結果會怎麼樣 乙個用例一般會由幾個有序的步驟來完成的 一...
《編寫有效用例》閱讀筆記05
編寫有效用例 為我們提供了很多用例的編寫技巧以及需求分析的知識，通過這些知識我們可以根據實際專案的情況運用更加嫻熟的用例編寫技巧來幫助我們更好的完成工作。在第一篇閱讀筆記中我們就談到了用例應用範圍是很大的，但是這段時間的閱讀讓我產生了乙個困惑，那就是用例到底應用在專案開發過程中的什麼地方，以及如何合...
《編寫有效用例》閱讀筆記三
基於資料庫操作的小用力稱為crud用例，每個小用例都表達了單獨需求，在處理這種用例是會有兩種不同的方法，可以將其分離或者先使用單個管理實體用例對其處理。在提取系統用例時或有許多用例大致相同，對此可能會建立一種通用搜尋機。用例每個目標步驟的命名類似於程式語言中的子過程呼叫，而且用例是有人而不是計算機使...