1. OO 需求搜集
因為“需求搜集”通常包含一些關於需求是什麼以及您如何去搜集它等方面的不正確的假定（至少從 OO
角度）
首要任務是解決必須做什麼，而不是如何去做
--------在 OO 說法中，問題定義的第一步稱為正規問題說明書----------------
2. 問題說明書
在任何一個設計中，精確地陳述問題總是第一步的。這裡，您的目標是要簡潔而精確地說明書您所要解決
的問題。再次重申，您的注意力應在做什麼和為什麼做，而不是如何做。
解有關該問題領域方面的知識
3. 細化您的說明書
不要去做那些細支末節的工作
用清楚而組織良好的語言去說明書它
所要討論的問題必須完全用問題領域方面的詞匯來表達
關於設計完整的一般性原則是，一位有頭腦的外行通過浏覽熟悉該領域的且勝任的程序員的文檔，能夠完
全理解所要解決的具體問題和該問題的一般性解決方案。如果這種層次理解不能實現，那麼設計是不完整的
問題說明書應該涉及問題本身，而不是該問題基於計算機的解決方案
4. 盡可能地確認問題和解決方案
所有 OO 系統必須進行一些建模。如果已存在的問題有一個好的解決方案，但現實的問題是人們不可能很
快地執行已有的解決方案，那麼就需要將現有的解決方案建模。即手動過程自動化是全部所必需的，而您的
問題說明書應完整地描述那個手動過程。
要確認的一件重要事情是用戶的目標。用戶確切地要完成什麼？
您還必須說明所希望的結果。解決問題的最終成果是什麼？最終成果表達了什麼信息？
定義問題。然後，用該領域的詞匯來說明問題，讓您的用戶看一下問題說明書
5. 編碼前的細節
事實上，隨後，當設計和執行時，問題的定義會發生變化。這就是為什麼在設計隊伍中要有一個最終用戶
的原因：以確保您不會因為改善它們而破壞一些事情。
最初的問題定義應盡可能的詳盡。將您所想的都寫在紙上。不要遺漏任何細節，即便是最簡單的
我正在准備進行OO開發，希望得到朋友們的指點，
上面是我的一點學習總結
希望您能指點一二！
