最近參與開發乙個新的專案，經理給我們調研好的需求文件，我們參考文件進行開發。
由於剛參加工作，對實際的軟體開發過程不熟悉，但公司的管理流程又不是很規範，所以
遭遇了很多的困惑，一時不知如何去做。最後，嘗試著慢慢的把這個專案開發完成，這個過程
的痛苦。 而然讀到溫伯格先生寫的《成為技術的領導者》一書，發現裡面的第三章解決了我對
如何「從學習需求文件到設計開發」的疑惑，
現摘錄如下：
仔細閱讀任務規範。成功或失敗往往取決於對問題定義的細微差別。
儘管對問題有乙個整體、全面的了解非常必要，但這種對全域性的正確認識
往往是從乙個關鍵的細節開始的。解決問題型領導者們認識到了這一點，
並且特別關注這類細節。而神遊者們則恰恰相反，他們對這類細節感到厭煩，
一旦他們找到似乎有效的解決方法，他們就會迅速轉向其他的問題。對於
最糟糕的神遊者而言，解決方案的終端使用者僅僅是一群令人討厭的傢伙。
鼓勵團隊成員仔細閱讀任務規範。通過閱讀任務規範可以獲得大量的資訊。
僅僅依靠乙個人來閱讀任務規範是遠遠不夠的。乙個成功的解決問題型領導者
知道如何組織乙個好環境，讓所有的工作人員都全力以赴閱讀任務規範。
參與問題的初始定義以消除爭論。除非並且只有當所有的團隊成員對
問題有了統一的認識時，解決問題的努力才會有意義而不至於導致無謂地浪費。
大部分冗長的爭論其實是由於人們對問題理解的差異所引起的，而不是解決方案的
不同。解決問題型領導者要能區分乙個爭論究竟是基於對問題定義理解的不同還是
基於對解決方法上的差異。
從客戶那裡澄清任務規範並獲得額外的資訊。即使是書面的材料也無法對乙個
有價值的專案進行充分、全面且絕對正確的描述，但有些人寧可與手頭現有的材料
進行長時間的糾纏，也不願去與別人討論。其實有時候只要通過一次簡單
的交流就可以取得很好的效果。
在工作進行了一段時間，並對某些需求的含義有了更好的認識後，我們
應該再回顧一下任務規範。對於乙個複雜的問題，我們不可能一開始就對
它有完全的認識。但我們總是認為自己的理解是正確的，許多災難性的失敗
往往就源於此。所以我們強烈建議要定期對問題的假設條件進行複查。
成功的領導者會在工作中建立對自己理解的問題進行連續檢驗的機制。雖然
他們很自信，但他們對自己在智力上的侷限性也有清醒的認識。
從需求到設計
從需求到設計分為 需求 分析 設計三個步驟。1 需求收集和整理階段 盡量詳盡的收集客戶的需求，把複雜的業務化成業務流程圖。需求整理就是把需求按客戶的業務模組進行整理，分模組把需求按業務邏輯整理一遍，去除雜質 規整業務 履順業務流程。2 需求分析 分析整理好的業務需求，把握業務的資料流，畫出業務流和資...
從需求到設計 編碼的轉化
在你可以開始實現各個部分需求前，不必為整個產品進行完整 詳細的設計。然而，在 你進行編碼前，必須設計好每個部分。設計規劃將有益於大難度專案 有許多內部元件介面 和互動作用的系統和開發人員無經驗的專案 mcconnell 1998 然而，下面介紹的步驟將 有益於所有的專案 應該為在維護過程中起支撐作用...
從需求到測試
詳盡的需求是系統測試的基礎，反過來只能通過測試來判斷軟體是否滿足了需求。你必 須針對軟體需求規格說明中所記錄的產品的預期行為來測試整個軟體，而不是針對設計或編 碼。基於 的系統測試可以變成 自滿足的預見 self fulfilling prophecy 產品可以正確 呈現基於 的測試用例所描述的所有...