傳統(tǒng)IT行業(yè)里面，會(huì)有一個(gè)需求分析師的角色。做的工作就是：

1.對(duì)甲乙雙方的需求訪談；
2.制定《需求規(guī)格說(shuō)明書(shū)》；
3.開(kāi)需求評(píng)審會(huì)最終需求確認(rèn)；
4.追著甲乙雙方業(yè)務(wù)部門(mén)和技術(shù)部門(mén)簽字；
5.系統(tǒng)開(kāi)發(fā)、測(cè)試以及上線后監(jiān)督功能點(diǎn)是否滿足。

自此，一個(gè)良好的需求分析師對(duì)于上述流程執(zhí)行到位，他/她的職責(zé)就完美了。

如何做到1/2/3/4/5點(diǎn)不在今天的討論范圍之內(nèi)。

我們今天討論的是，如何在需求分析工作中，精細(xì)的收集功能點(diǎn)，然后針對(duì)功能點(diǎn)評(píng)估實(shí)現(xiàn)所需工作量。收集功能點(diǎn)需要對(duì)目標(biāo)業(yè)務(wù)的理解程度超越了解的程度，一般是按照經(jīng)驗(yàn)以及對(duì)開(kāi)發(fā)商的細(xì)致需求訪談中，確認(rèn)實(shí)體維護(hù)、實(shí)體交互、流程編排等單元。這是一個(gè)業(yè)務(wù)和技術(shù)知識(shí)結(jié)合考慮的一個(gè)場(chǎng)景，過(guò)多強(qiáng)調(diào)了知識(shí)的積累。那么有沒(méi)有一個(gè)捷徑，能夠在需求分析的工作基礎(chǔ)上，不需要過(guò)硬的業(yè)務(wù)知識(shí)，就可以向軟件度量托懷送抱呢？

我們存量大約有X00個(gè)系統(tǒng)，每年的新增系統(tǒng)僅僅是個(gè)位數(shù)；然而每年的大大小小的軟件需求卻有Y千個(gè)，分散在幾十個(gè)甲乙類(lèi)系統(tǒng)中。而大量的需求都是新增和修改，所以參考系統(tǒng)的架構(gòu)基線就可以比對(duì)軟件需求的估算度量。因?yàn)榇蠖鄶?shù)情況下，涉及到需求的變化都可以定義為“內(nèi)部邏輯”、“外部接口”、“外部輸入”、“外部輸出”、“外部查詢”（例如IFPUG法）上述實(shí)體的變更，結(jié)合整個(gè)需求的其他一些外部因素作為權(quán)重因子，按照計(jì)算公式得出工作量評(píng)估。

如果將管理需求的系統(tǒng)及管理基線的系統(tǒng)結(jié)合軟件度量有機(jī)的對(duì)接，就能展示在需求實(shí)施過(guò)程中，具體需求分解程度以及需求完成程度，最后可以量化整個(gè)需求實(shí)施的人工和效率。如果結(jié)合掃描代碼規(guī)范和代碼質(zhì)量的落地程度，還可以掛接實(shí)施人員的績(jī)效評(píng)估。

然而收集軟件基線是一個(gè)很苦痛的事情，大量的開(kāi)發(fā)周期管理在沒(méi)有精細(xì)化的情況下，軟件功能點(diǎn)僅僅記錄在代碼中，或者在不立即更新的文檔里。我們對(duì)于需求功能條目化的渴求是比較明顯的。所以不論采取什么措施，將非文檔化的需求功能點(diǎn)，按照業(yè)務(wù)功能菜單：“系統(tǒng)/模塊/功能/操作”維護(hù)進(jìn)入軟件基線，并對(duì)基線的變更有常態(tài)化管理，就能迎接軟件度量的新時(shí)代。

PMP有個(gè)術(shù)語(yǔ)叫組織過(guò)程資產(chǎn)，是把無(wú)形資產(chǎn)轉(zhuǎn)為有形資產(chǎn)。看來(lái)管理這門(mén)課，都是軟噠噠流來(lái)流去一通百通放之四海皆準(zhǔn)怎么說(shuō)都能說(shuō)對(duì)的事情。