運營商的系統，不會每年讓都這么大規模的讓你折騰，是的，這次機遇難得！目前參加的項目，需要對原系統推翻重來，無論從數據模型，還是技術架構上，都需要進行大規模的升級改造。

    由于系統業務的復雜，雖然需求明確，前期需求分析也做的很充分，但開發人員還是需要對照原系統的代碼來開發業務邏輯。因為需求分析得再細，也細不到某個前臺錄入的數據，應該特殊處理到某個字段。

     因此開發起來效率不高，而且業務不滿足的風險極大！

     公司在需求管理方面，可以說投入不可謂不大，有專門的人，購買專門的系統來管理，但通過這次系統升級發現，之前的需求管理對這次一點幫助沒有，最多是保存了些原來客戶提的需求文檔。做分析的時候還可以，但真正指導開發，還是有一定差距！問題到底出在什么地方？怎么樣的需求管理，才能把當前系統的情況完整展現出來？

     我也不知道，我只能把現在的情況描述下來，希望有經驗的人士給點意見，在此多謝先：
     （1）需求分析：把整理的需求文檔匯總，1-2年下來，這些文檔有幾個G，一個人看下來簡直是不可能的任務，分模塊后，一般每個模塊有個需求小組來完成需求分析工作，輸出業務模型（概念數據模型），更多是讓這些人（將來的組長）熟悉自己要做的業務細節。
     （2）概要設計：主要的工作是細化概念數據模型，成物理模型。
     （3）詳細設計：我們基本沒有，因為這個工作量太大，一般到概要設計，出數據模型后，邊開發，邊做詳細設計，這時還會繼續維護物理數據模型。
     （4）代碼開發：人員流動很大，新員工很多，很多不熟悉業務，不知道要做的東西干什么的，技術和業務培訓會經常進行。這時，問題來，架構設計后，開發人員對照著原代碼的邏輯進行寫程序，因為需要了解原來的程序怎么走的，為什么這么判斷，這個工作很煩躁且必須，因為你不能丟掉原來的功能點和業務限制。

     （5）測試：這也是問題，問題就是用例的粒度很粗，沒有特別熟悉業務的人員，因此業務限制的缺失無法測試得到！

      這么看來，還是功能點的詳細設計沒有做好，業務限制沒有整理出來，如果通過非常明細的測試用例來指導開發呢？