結(jié)果要么用戶不置可否，要么直接講看不懂，為什么呢？一是開發(fā)人員在文檔中分子系統(tǒng)、分模塊、分功能點(diǎn)一層深入下去描述，不符合用戶的思維習(xí)慣，他們希望能夠從業(yè)務(wù)流程、業(yè)務(wù)活動(dòng)的角度來考慮問題，而不是功能；二是太多了，用戶也沒有時(shí)間靜下心來去消化、吸收如此多的文檔，需求畢竟不是小說，能夠那么吸引讀者。

　　（3）用戶IT主管與開發(fā)人員，包括設(shè)計(jì)人員、編碼人員、同行的專家

　　大多數(shù)分析人員可能最擅長(zhǎng)的就是些寫這類的文檔了，往往也是那這類的文檔給所有的讀者看，其問題我們上邊都說了，這里我們就不贅述了。

　　需要注意的是在描述需求時(shí)候傳統(tǒng)的做法是以功能為主線，來展開描述，實(shí)際上如果是以數(shù)據(jù)為主線來描述需求也是一種很好的辦法，在我們上面談到的五元組中，從數(shù)據(jù)的角度來分析系統(tǒng)可以更容易實(shí)現(xiàn)向OOA、OOD的切換。


　?。?） 項(xiàng)目管理人員：包括項(xiàng)目經(jīng)理、質(zhì)量保證人員、測(cè)試人員、需求管理員、配置管理員、計(jì)劃人員等等

　　把拿給開發(fā)人員看的需求文檔給管理人員看，這也是分析人員常犯的毛病。管理人員實(shí)際上最關(guān)心的是需求列表。

　　在此基礎(chǔ)上項(xiàng)目經(jīng)理、質(zhì)量保證人員可以據(jù)此來進(jìn)入項(xiàng)目策劃過程，測(cè)試人員可據(jù)此進(jìn)入測(cè)試策劃過程，需求管理員、配置管理員可以識(shí)別配置項(xiàng)制定相關(guān)的活動(dòng)計(jì)劃。沒有這張表管理人員就很難高效地開展他們的管理活動(dòng)，也就談不到最基本的需求復(fù)用了。在上述的表中，需求的優(yōu)先級(jí)是很重要的一列，對(duì)項(xiàng)目經(jīng)理進(jìn)行項(xiàng)目管理的平衡決策是很重要的，實(shí)際上需求的優(yōu)先級(jí)可能比需求本身更重要。

　　3 需求描述的表示技巧

　　上面我們談到了，需求文檔是人與人之間交互的文檔，是不同類型的人之間交互的文檔，因此需求文檔的可讀性是一個(gè)很重要的方面，為了提高文檔的可讀性可以借鑒下面的一些做法：

　　在文檔的描述中，適當(dāng)運(yùn)用鏈接，增強(qiáng)文檔的可讀性；

　　多用窮舉的方式，以便于發(fā)現(xiàn)遺漏的需求；

　　通過適當(dāng)?shù)膿Q行來提高可讀性 ；

　　采用黑體、斜體、下劃線、顏色等多種方式來突出重要內(nèi)容；

　　定義標(biāo)準(zhǔn)的術(shù)語，以減少二義性，減少文檔的頁(yè)數(shù)；

　　在功能需求的描述中，對(duì)于類似的、統(tǒng)一的功能可以單獨(dú)地進(jìn)行詳細(xì)描述，其他地方進(jìn)行引用，或做為術(shù)語進(jìn)行定義，以簡(jiǎn)化文檔，減少重復(fù)。如；

　　·錄入功能

　　·打印功能 

　　· 條件查詢功能

　　·排序功能等等


　　結(jié) 語

　　盡管你按照上述的方法去做了，也不要期望能夠編寫出一份能體現(xiàn)需求應(yīng)具備的所有特性的文檔，無論你如何去細(xì)化、分析、評(píng)論和優(yōu)化需求，都不可能達(dá)到完美，但是你能夠做到“可接受”，寫一份客戶、用戶、開發(fā)人員、管理人員都認(rèn)可的一份需求，而不是完美的需求！ 轉(zhuǎn)貼于：http://m.opto-elec.com.cn

    項(xiàng)目經(jīng)理勝任力免費(fèi)測(cè)評(píng)PMQ上線啦！快來測(cè)測(cè)你排多少名吧~

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