在你可以開始實現各個部分需求前，不必為整個產品進行完整、詳細的設計。然而，在
你進行編碼前，必須設計好每個部分。設計規劃將有益於大難度專案（有許多內部元件介面
和互動作用的系統和開發人員無經驗的專案）（mcconnell 1998）。然而，下面介紹的步驟將
有益於所有的專案：
• 應該為在維護過程中起支撐作用的子系統和軟體元件建立乙個堅固的體系結構。
• 明確需要建立的物件類或功能模組，定義他們的介面、功能範圍以及與其它**單元的協作。
• 根據強內聚、松耦合和資訊隱藏的良好設計原則定義每個**單元的預期功能。
• 確保你的設計滿足了所有的功能需求並且不包括任何不必要的功能。
當開發者把需求轉化為設計和**時，他們將會遇到不確定和混淆的地方。理想情況下，
開發者可沿著發生的問題回溯至客戶並獲得解決方案。如果不能馬上解決問題，那麼開發者
所做出的任何假設，猜想或解釋都要編寫成文件記錄下來，並由客戶代表評審。如果遇到許
多諸如此類的問題，那麼就說明開發者在實現需求之前，這些需求還不十分清晰或具體。在
這種情況下，最好安排一兩個開發人員對剩餘的需求進行評審後才能使開發工作繼續進行。
從需求到設計
從需求到設計分為 需求 分析 設計三個步驟。1 需求收集和整理階段 盡量詳盡的收集客戶的需求，把複雜的業務化成業務流程圖。需求整理就是把需求按客戶的業務模組進行整理，分模組把需求按業務邏輯整理一遍，去除雜質 規整業務 履順業務流程。2 需求分析 分析整理好的業務需求，把握業務的資料流，畫出業務流和資...
從學習需求文件到設計開發
最近參與開發乙個新的專案，經理給我們調研好的需求文件，我們參考文件進行開發。由於剛參加工作，對實際的軟體開發過程不熟悉，但公司的管理流程又不是很規範，所以 遭遇了很多的困惑，一時不知如何去做。最後，嘗試著慢慢的把這個專案開發完成，這個過程 的痛苦。而然讀到溫伯格先生寫的 成為技術的領導者 一書，發現...
從需求到測試
詳盡的需求是系統測試的基礎，反過來只能通過測試來判斷軟體是否滿足了需求。你必 須針對軟體需求規格說明中所記錄的產品的預期行為來測試整個軟體，而不是針對設計或編 碼。基於 的系統測試可以變成 自滿足的預見 self fulfilling prophecy 產品可以正確 呈現基於 的測試用例所描述的所有...