例如處理邏輯增加、減少或修改

什么是處理邏輯？功能點分析方法通過枚舉方式列出十三種邏輯[3]，如表一所示。需要注意的是，區(qū)分事務(wù)功能的唯一性時，可以不考慮處理邏輯13，即重新分類或重新排列數(shù)據(jù)邏輯；而當判斷一個事務(wù)功能是否被修改時，則所有的處理邏輯都在考慮的范圍，哪怕事務(wù)功能僅僅只是對處理邏輯13 做了修改，也應(yīng)視作修改的事務(wù)功能。 
 
表一：事務(wù)功能的13種處理邏輯

表一中各字母表示的含義如下：
M：事務(wù)功能必須執(zhí)行的處理邏輯
M*：事務(wù)功能必須執(zhí)行其中的至少一個
C：事務(wù)功能可以執(zhí)行，但并不是必須執(zhí)行的處理邏輯
N：事務(wù)功能不能執(zhí)行的處理邏輯
至此，可以將軟件需求變更歸類為遺漏性需求變更和追加性需求變更。而對每一性質(zhì)的變更又可區(qū)分為新增、刪除和變更三種類型。下一節(jié)進一步描述不同需求變更類型的功能點算法。

3.2. 需求變更的影響分析

正如圖一中項目管理三角形描述的那樣，采用功能點衡量需求變更的程度，是為了更好地評價需求對項目的工期、成本以及質(zhì)量的影響。首先涉及到的問題就是如何對需求變更后的項目規(guī)模重新評價，在上一節(jié)描述了對單次需求變更（包括增加、修改和刪除）的識別，在此基礎(chǔ)上可以根據(jù)下面的公式計算變更后的項目功能點規(guī)模。

CAFP=(CBFP+DEL)*VAFB+(ADD+CHGA+CFP)*VAFA                          （1）

其中

CAFP：變更后項目功能點總數(shù)（表示每次需求變更后對項目功能點的計數(shù)）
CBFP：變更前項目功能點總數(shù) （最初的項目功能點數(shù)通常在需求規(guī)格說明書批準后得到，又稱為項目的初始基線功能點）
DEL：刪除需求的功能點總數(shù)
VAFB：修改前調(diào)整系數(shù)
ADD：增加需求的功能點總數(shù)
CHGA：修改后需求的功能點總數(shù)
CFP：數(shù)據(jù)轉(zhuǎn)換的功能點數(shù)（如果系統(tǒng)中涉及到遺留系統(tǒng)數(shù)據(jù)遷移時會有此類型功能點）     
VAFA：修改后調(diào)整系數(shù)    

需要說明的是，在軟件需求變更的過程中，VAFB和VAFA通常是一致的，因為單次需求變更往往對于系統(tǒng)的非功能性需求沒有明顯的影響。

因為每次需求變更后可以重新確定項目的功能點，所以可以在此基礎(chǔ)上重新確定項目的工期、成本和質(zhì)量[2]，[4-8]。

對于后續(xù)階段提出的需求變更與項目前期提出的需求變更所引發(fā)的工作量的評估看起來會有比較大的不同，感覺上好像后續(xù)的變更引發(fā)的工作量更大。這是因為后續(xù)階段提出的新需求可能會涉及到對技術(shù)架構(gòu)體系的修改，這樣就會涉及到很多工作量。但如果不涉及到技術(shù)架構(gòu)的話，需求在前期與后期提出對于引發(fā)的工期、成本和質(zhì)量應(yīng)該區(qū)別不大。

需求變更影響分析在合同管理方面有著重要的意義，軟件項目合同的項目約束條件（工期、費用和質(zhì)量要求）與項目的范圍有直接的對應(yīng)關(guān)系。當軟件需求如果比原有需求增加、修改和刪除時，項目的約束條件應(yīng)該也隨之發(fā)生變化。因為在很多軟件項目中存在需求前期不明確、不完整的情形，所以軟件需求變更管理應(yīng)該充分考慮這一因素，因而本文將其區(qū)分為遺漏性需求與追加性需求。上述的公式（1）主要適用于項目組內(nèi)部對于需求規(guī)模的評價，而客戶方與開發(fā)方組織對于需求規(guī)模的評定應(yīng)充分考慮遺漏性需求發(fā)生的可能性，因為遺漏性需求不應(yīng)該排除在項目的合同范圍之外，也即意味著客戶無需為遺漏性需求支付額外的費用或降低其他約束標準。

4. 采用功能點方法約束軟件需求

不同于軟件項目的追加性需求，軟件項目的遺漏性需求是應(yīng)該并且也可能避免的。在需求的獲取階段可以標準功能點作為需求的約束標準，避免產(chǎn)生遺漏性需求。具體來說，對于每一項客戶提出的業(yè)務(wù)功能都應(yīng)該以圖二所描述的模型作為約束標準。每一項功能都必須有對應(yīng)的數(shù)據(jù)功

    項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~

    http://m.opto-elec.com.cn/pmqhd/index.html