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