我個人的寫作水平有限，而且自己開發的經驗有限，下面的內容只是自己的一點體會。希望閱讀者能以乙個批判的態度閱讀，希望對你有幫助，並願意聽取你的意見。
學習軟體工程的知識有較長一段時間了，但是自己的腦子裡面對於軟體開發的過程一直就是：需求分析，設計，實現，測試，維護。但是真的做起開發來，感覺總是把精力集中在了實現這一塊上。對於其它方面如：需求分析，就是不知道怎麼做。不過通過最近一段時間的學習，慢慢的開始找到了方法。軟體開發其實就是乙個過程，這個過程就是乙個分析業務需求，並把業務需求轉換為計算機可以理解的一些**。大的方向我認為就是這樣的，但是具體的怎麼做一直的很迷茫，讀了幾本ivar jacobson先生的一些作品之後，感覺他提倡的基於用例的軟體開發過程比較好，適合現在的我。對於乙個沒有太多開發經驗的我來說，先盡量的按照他提倡的方式去做軟體開發（當然在這個過程中要與自己的實際結合），當自己有了一定經驗與知識積累後，再去調整，以便他的方法可以更好的適合自己。
其實有時候，我們對做軟體迷茫是因為：我們不知道自己要做什麼，也就是沒有思想。我現在覺得：基於用例的軟體開發（或者說是參照統一軟體開發過程）是一種比較好的方法。我找到了分析問題的起點：那就是用例，我們所做的一切工作都要基於用例，用例是我們做後面所有事情的基礎。
總之一句話，從用例開始我們的軟體開發過程。
如何開發用例描述
visual paradign 僅以uml表示法顯示用例圖是不夠的。每個用例都附有說明用例目的的文字，以及在執行用例時完成的功能。用例規範通常以迭代方式在分析和設計階段建立。用例描述由執行者生成的任務，該任務生成業務的業務價值結果。用例可以視覺化為用例圖或 和結構化文字規範格式 用例 任務 客戶想要...
用例驅動開發之心得
我們做任何事情，背後都有一股驅動力。比如，我們吃飯，是因為飢餓驅動我們去吃飯 簡單地說，人類的多數行為都是受到 慾望 驅動。我們做程式設計師的，也需要一股實實在在的驅動力，來驅動我們完成手頭的工作。如果找不到這股驅動力，或者驅動力不夠強，我們便會覺得心煩 隨便上上網，看看技術文章，學學新技術，不知不...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...