圖二：功能點分析方法結(jié)構(gòu)圖
其中，數(shù)據(jù)功能需求區(qū)分為應用內(nèi)部邏輯數(shù)據(jù)和應用外部的接口數(shù)據(jù)；事務功能區(qū)分為對數(shù)據(jù)的外部輸入、輸出和查詢。數(shù)據(jù)功能的 復雜性由數(shù)據(jù)元素類型（DET ）和記錄元素類型（RET ）決定 ；而事務功能的復雜性由數(shù)據(jù)元素類型（DET ）和文件引用類型（FTR ）決定 。將功能轉(zhuǎn)換為對應的復雜程度，再根據(jù)復雜程度轉(zhuǎn)換為對應的功能點數(shù)值[3]，這樣就將用戶的業(yè)務功能需求表述為一個用數(shù)值表示的軟件需求規(guī)模。完整的功能點計數(shù)過程如圖三所示[3]。
圖三：功能點計數(shù)過程
因為功能點分析方法是一個確定軟件需求規(guī)模的標準方法，所以它可以界定需求的有效粒度。從而有助于約束需求的詳細程度，并采用統(tǒng)一的尺度衡量軟件需求規(guī)模。
3. 采用功能點方法管理軟件需求變更
3.1. 基于功能點分析方法的需求變更分類
何謂軟件需求變更？從功能點分析的角度就是需求發(fā)生了變化，而這種變化的判定依據(jù)可以參考功能點的識別規(guī)則。需求的變更相對于原有的需求而言無非就是三種類型：新增需求、修改需求和刪除需求。新增需求和刪除需求相對容易判斷，而修改需求的判斷就不是那么直接了。在實際的軟件項目中，需求的變更通常存在下列的情形：
第一種是需求不明確的前提所提出的變更，即在需求定義時用戶沒有能力或時間定義需求，或定義的需求不夠詳細，因而在需求確認后提出變更，通常包括新增需求和變更需求；
第二種是在需求明確的前提下所提出的變更，通常是因為當前的業(yè)務與最初提出的需求已經(jīng)發(fā)生了變化或者原有的功能已經(jīng)不適用，通常包括新增需求、刪除的需求和變更的需求。
我們將第一種需求稱為遺漏性需求變更，而將第二種需求變更稱為追加性需求變更。下面分析的結(jié)果對于遺漏性和追加性的需求變更都適用。
3.1.1. 數(shù)據(jù)功能的需求變更分類
對于新增和刪除的數(shù)據(jù)功能容易識別，例如在原有需求的基礎之增加或刪除發(fā)票信息或價格規(guī)則信息，則易判斷發(fā)票信息或價格規(guī)則信息為增加或刪除的數(shù)據(jù)功能。對于修改的數(shù)據(jù)功能則比較困難。
判斷修改的數(shù)據(jù)功能時應注意：如果修改僅包含邏輯文件中新紀錄的增加或者已存在字段中新值的增加，那么不能認為數(shù)據(jù)功能被修改；如果數(shù)據(jù)功能中添加了新字段，而這個新字段卻并沒有被應用所使用，那么該數(shù)據(jù)功能也不能認為是被修改的數(shù)據(jù)功能。一個數(shù)據(jù)功能被算作被修改的功能，通常其結(jié)構(gòu)要發(fā)生改變（如：增加或刪除一個字段或者修改了字段特征）[3]。
所以對于數(shù)據(jù)功能的需求變更可以區(qū)分為增加、修改和刪除。
3.1.2. 事務功能的需求變更分類
類似于數(shù)據(jù)功能的判斷，對于新增和刪除的事務功能也容易識別。例如在原有需求的基礎之增加或刪除價格規(guī)則維護功能，則易判斷價格規(guī)則維護功能為增加或刪除的事務功能。通常，當判斷有新增或刪除的數(shù)據(jù)功能時，事務功能也會有新增或刪除。而當新增或刪除事務功能時，數(shù)據(jù)功能卻不一定發(fā)生變化。例如，增加或刪除了價格規(guī)則這樣的數(shù)據(jù)功能時，則對應的應該有新增或刪除的事務功能。否則，如何維護對應的數(shù)據(jù)功能？反之，則不必然。
對于修改的事務功能判斷相對困難。判斷EI/EO/EQ類型的事務功能是否被修改，則可參考事務功能的唯一性判定原則。如果以下三個條件任一條件滿足，則說明事務功能發(fā)生了變化，需求應被當作變更的需求處理。判斷事務功能是否變更的三個條件如下：
事務功能的DET是否發(fā)生變化，例如增加、刪除或修改DET
事務功能關(guān)聯(lián)的FTR是否發(fā)生變化，例如FTR增加、減少或修改
事務功能對應的處理邏輯是否發(fā)生變化，
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
