方案設計：
明確需求后，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，我們就能夠對設計方案進行評估。
必要的修改：
方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。如果我們無法準確把握用戶需求同方案設計之間的關系，我們就無法在需要對方案進行必要修改時正確判斷。優秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的余地。
任務劃分：
一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、軟件工程師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。
主持一個大項目的開發并不是件容易的事，總體項目主管的首要任務是對開發項目進行任務劃分，將整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的干預�？傮w項目主管可以將細化的不同模塊的需求分析交給不同的開發隊伍，對于開發進程的監控只需參照需求的解決情況，對于具體的開發細節則不必過問太多。
不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用詞匯。
產品測試：
需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發階段所對應的測試需求。
這里有一個需求、產品和測試系統之間的關系問題，確定需要進行的測試屬于總體開發主管的工作范疇，雖然具體工作并非都要由開發主管來親自完成。
重復開發：
對于總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減�。�。在進行項目開發時，隨著開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。
方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發進程；但在一個能夠進行重復設計、重復開發的產品生命期中，開發人員應當及時搜集用戶對于產品的反饋信息，并將這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同產品開發是統一的。
項目管理的輔助：
在有些地方，需求管理被作為一個技術問題來處理，需求管理所針對的對象只是產品，而同項目管理所涉及的問題例如進程安排或資源分配等無關。實際上，項目管理涉及三方面問題：進程安排、資源分配和質量管理（同需求的統一）。
試想以下三種情況：
●一場高水準的音樂會，預算合理，演出時間卻晚了兩天。
●質量優良的小轎車，交貨及時，然而造價是市價的兩倍。
●一套系統，完全滿足了用戶需求，但在開發過程中使用非法勞工。
這三種情況雖然都滿足了用戶所需，然而缺乏實際意義，因此都以失敗告終。
"我付了錢，但這不是我想要的"，沒有用戶愿意這么說。要避免出現這種情況，在進行項目管理和財務預算時，也必須以需求管理為基礎。僅僅完成了一件設計并不意味著工作的結束，只有這件設計充分解決了需求，它才具有里程碑般的意義。同樣的，一件產品只有在測試和實際操作中完全滿足了需求，已經完全準備好了投入到下一階段的運營，才意味著這件產品在本階段工作的結束。
開發進程中的每一塊里程碑都意味著需求的解決又前進了一步，這樣的每一塊里程碑也都是委托商付款的重要參照，產品開發的整個進程都可以通過需求管理進行監控。
里程碑構造機制的基本方法之一就是進程管理，一項需求的滿足就意味著一塊里程碑的確立。我們應當對用戶需求、針對需求而進行的模塊設計以及每個子模塊的開發進程之間的關聯做到心中有數。
通過我們對需求管理實際應用的分析，幾個關鍵因素凸現出來。首先，需求管理在開發周期中是自始至終存在的。注意：不要把它簡單理解為"需求周期"，需求管理必須始終保持更新，它構成了技術管理的基礎。
其次，需求管理同項目管理是密不可分的。如果我們把每一個需求的解決看作一個里程碑，并以此出發對整個開發進程進行監控，我們就應該對整體開發工作進行精密細致的劃分，從而將需求分析具體化。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
