我最近遇到乙個專案，在該專案中，乙個新的開發小組將針對早先的開發小組所開發的
求實現乙個應用程式。這個新的開發小組一看到由3英吋活頁紙訂成的軟體需求規格說明就
到十分恐懼，於是立刻編寫**。在構造軟體的過程中，他們沒有參考軟體需求規格說明，
而是根據他們對預期系統的不完整且不正確的理解，按他們自己的想像進行編碼設計。因此，
該專案遇到許多問題便不足為奇了。試圖理解這個龐大的需求規格說明肯定會令人恐懼的，
況且需求規格說明有些部分可能還不完善，但忽略了需求規格說明必定會導致失敗。
我知道乙個十分成功的專案，在開發專案的過程中，開發人員列出了與特定**版本相
對應的需求。專案的質量保證組通過對照需求來執行測試用例從而評價其對應的**版本。
根據測試標準，如果不滿足需求的話就算是乙個錯誤。如果不滿足的需求數量超過預先給定
的乙個數字，或者特定的有重大影響的需求沒有被滿足，那麼這個**塊就被拒絕了。這個
專案的成功之處在於把需求文件作為何時發行產品的基礎。
乙個軟體開發專案最終可發行的是滿足客戶需求和期望的軟體系統。需求是從產品概念
通向使用者滿意之路的最本質的一步。如果你不以高質量的需求作為專案規劃、軟體設計和系
統測試的基礎，那麼在試圖開發優秀產品的過程中將浪費大量的人力和物力。
然而，也不要成為需求過程的奴隸。避免陷入畸形分析的陷阱，此時，開發小組將花費
大量的時間建立不必要的文件，並舉行各種形式上的會議和評審，而並不編寫任何軟體**，
這將會導致專案被取消。努力在精確的規格說明與可將產品失敗的風險降至可接受程度的編
碼之間做出明智的選擇。
從撲克牌看專案的需求管理
1 在撲克牌對弈中，各家的牌面是現實存在，不論我們是否知曉。在專案實施中，各方的需求是現實存在，不論我們是否知曉 2 不論牌面如何糟糕，我們只能依據牌面出牌，重要的不是牌面是否糟糕，而是各家的具體牌面。不論需求如何苛刻，我們只能按需求辦事，重要的不是需求是否苛刻，而是各方的具體需求 3 我們可以依靠...
從需求到測試
詳盡的需求是系統測試的基礎，反過來只能通過測試來判斷軟體是否滿足了需求。你必 須針對軟體需求規格說明中所記錄的產品的預期行為來測試整個軟體，而不是針對設計或編 碼。基於 的系統測試可以變成 自滿足的預見 self fulfilling prophecy 產品可以正確 呈現基於 的測試用例所描述的所有...
從需求到設計
從需求到設計分為 需求 分析 設計三個步驟。1 需求收集和整理階段 盡量詳盡的收集客戶的需求，把複雜的業務化成業務流程圖。需求整理就是把需求按客戶的業務模組進行整理，分模組把需求按業務邏輯整理一遍，去除雜質 規整業務 履順業務流程。2 需求分析 分析整理好的業務需求，把握業務的資料流，畫出業務流和資...