這兩個月來，主要都是在進行和需求相關的培訓和咨詢，我發(fā)現(xiàn)在行業(yè)里一個根深蒂固的認識是需要/可以存在多份不同格式的分立的需求文檔：業(yè)務人員可以寫一份意識流的業(yè)務（客戶）需求文檔，開發(fā)人員可以在再寫一份充斥著分析結果及IT術語的軟件（軟件）需求，測試人員則可以寫一份閉門造車的測試需求。好像每個人都很好的完成了任務，但是誰來保證這些需求的一致性呢？我們有很好的答案—請業(yè)務人員確認他們看不懂的軟件需求，請開發(fā)人員確認他們沒時間或心思看的測試需求，絕妙的主意！
    目前大多數(shù)客戶編寫軟件需求規(guī)約的思路和格式基本上都與IEEE Std 830-1998標準一脈相承，這種基于結構化分析和功能分解的文檔體系（包括數(shù)據(jù)流圖，數(shù)據(jù)字典等）起源于70年代，當時，軟件的主要應用還是科學計算或信息處理，理解需求的人往往也受過結構化分析的相關教育，然而這些內(nèi)容對今天的大多說業(yè)務人員或最終用戶而言就是很難理解的了?？梢哉f在這樣的軟件需求規(guī)約里分析多于需求，為了解決這個問題，有的組織開始引入了非形式化、非結構化的業(yè)務需求，然而卻很難在兩種需求之間建立明確的對應關系，從而造成了第一段中描述的困境。
    另一個造成多份不同格式的分立的需求存在的原因可能與僵化地執(zhí)行CMMI有關，CMMI在三級的需求開發(fā)（Requirements Developement）這個過程域（Process Area）中將開發(fā)客戶需求（Customer Requirements）和開發(fā)產(chǎn)品需求（Product Requirements）明確地分成了兩個不同的特定目標（Specific Goals），這導致有些企業(yè)讓業(yè)務人員負責客戶需求，而讓開發(fā)團隊負責產(chǎn)品（軟件）需求，表面上各司其職，但實際上帶來的是大家在郵件里將文檔發(fā)來發(fā)去，工作效率很低而溝通的效果也不好。
    我們推薦的需求體系是基于用例的, 它是一種可以被各方真正理解和溝通、并可以被逐步精化的需求體系。用例是這一需求文檔體系的主體，但其實這一體系是由如下文檔來構成的：
前景文檔：對目標系統(tǒng)的商業(yè)前景進行分析；
涉眾分析：對目標系統(tǒng)的涉眾以及他們對目標系統(tǒng)的主要要求（Needs）進行分析；
特性列表：概述目標系統(tǒng)的主要特性
詞匯表：對領域內(nèi)的名詞、術語和商業(yè)規(guī)則進行解釋；
領域模型：用模型的方式對領域內(nèi)的實體關系進行描述；
用例模型：對整個用例模型進行概述；
用例規(guī)約：對每個用例的基本流和備選流進行詳細的描述；
補充規(guī)約: 對目標系統(tǒng)級的非功能性需求進行描述；
我們推薦的工作方式是：
不同的角色（業(yè)務，開發(fā)，測試等）組成一個虛擬團隊，基于同一個基于用例的需求體系進行協(xié)同的需求開發(fā)；
    在需求開發(fā)的前期，以業(yè)務人員為主導，通過對業(yè)務的分析來豐富需求的內(nèi)容； 而在需求開發(fā)的中后期，以開發(fā)人員為主導，通過對需求的分析來細化需求；如果組織需要通過CMMI評估，那么可以將前期的一個需求基線作為客戶需求，而將后期的一個需求基線作為產(chǎn)品需求；
    需求是在開發(fā)過程中不斷演進的，虛擬需求團隊定期對需求的變更進行復審，因此對需求的確認是不斷以增量方式進行的；
    開發(fā)人員將需求分析的結果以需求分析規(guī)約或分析模型的方式記錄下來，但如果認為需求有問題，就應該以協(xié)作的方式對需求進行改進而不是另寫一份文檔；
測試人員同樣也是對需求進行分析準備測試方案和測試用例，并同時對需求提出改進建議；
可能需要考慮引入一些工具來支持這樣的協(xié)同需求開發(fā)過程；
總之，我們推薦的需求開發(fā)方法是以一個緊密協(xié)同的虛擬團隊在一個需求體系之上來進行的。

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

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