需求基線定義：團隊成員已經承諾將在某一特定產品版本中實現的功能性和非功能性需求的一組集合。
軟體開發的中後期開發效率會產生大幅度的下降，其實開發團隊經常處於「非計畫」狀態是個比較重要的原因之一，而救火隊式的工作必將導致無法計畫。
分階段開發與迭代開發的區別：
分階段開發中的每個階段的結束時間不是固定的，必須將相應的內容開發完成後才結束；另外每個階段內通常是相應變更的；
迭代開發中的每次迭代的結束時間是固定的，沒有完成的任務將會放到下次迭代，每次迭代內通常是不相應變更的；
迭代開發的思想就是細小的、可管理的步驟開發軟體產品：計畫一小步，說明、設計和實現一小步，整合、測試和執行一小步；每次迭代是一次袖珍專案，採用的是瀑布模型的開發方法；迭代是業務優先順序驅動的。
業務事件和報表型別的判斷：根據它出現的頻率，以及對企業帶來的價值進行評價。
估算是一種手段，而不是目標，我們追求的是管理的可控性，而非估算結果的準確性。
估算的核心思想是「尋找計數單元，考慮複雜因子」，不同的階段的估算應使用不同的計數單元：
需求定義階段：可以考慮業務時間、報表型別、介面作為計數單元；
需求分析一階段：可以考慮用例作為計數單元；
一是分部分、分型別進行估算；二是採用基於權重的估算方法；
悲觀估計、樂觀估計應和「風險」理由對應起來；
產能係數表可以通過工資比例作為其初值；
非使用者可見的基礎設施通脹佔據開發量的30%；
「拋棄work down，迎接value add！」
「對於整個專案而言，我們很難講所有要完成的任務列出來，然後乙個個地work down（完成）；我們需要的是通過一次次的迭代為客戶實現value add（增值）。」
「即使使用者中途停止了開發，也不至於一無所獲」
「良好、統一」的需求項劃分標準是做好這一工作的基礎，實現切實可行的優先順序策略和估算方法是使基線管理卓有成效的必備要素。
納入基線管理的經驗原則
納入基線管理的一般原則是 原則1 所有交付給客戶的文件 可執行程式 購買來的可復用構件等必須納入基線。原則2 影響了對外的承諾的配置項 專案的階段計畫必須納入基線來管理。對外承諾變了 原則3 其變化影響了其他配置項 所有對交付產品有重要影響的文件資料等必須納入基線，主要的工程文件如需求 設計等一般要...
納入基線管理的經驗原則
納入基線管理的一般原則是 原則1 所有交付給客戶的文件 可執行程式 購買來的可復用構件等必須納入基線。原則2 影響了對外的承諾的配置項 專案的階段計畫必須納入基線來管理。對外承諾變了 原則3 其變化影響了其他配置項 所有對交付產品有重要影響的文件資料等必須納入基線，主要的工程文件如需求 設計等一般要...
需求工程之需求基線
什麼是需求基線？需求基線就是把固定的需求都劃一根 線 說明這些需求已經確定下來，新增新的需求或修改原有的需求都必須通過需求變更流程來操作 建立需求基線的目的 防止需求的變化給程式架構造成重大影響。需求基線定義 已經通過正式評審和批准的規格說明或產品，可作為進一步開發的基礎，而且只有通過正式的變更控制...