如何進(jìn)行軟件需求分析 

51CMM 作者：曹偉 

1．概念
需求的定義包括從用戶角度（系統(tǒng)的外部行為）,，以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求。
關(guān)鍵的問題是一定要編寫需求文檔,。我曾經(jīng)目睹過一個(gè)項(xiàng)目中途更換了所有的開發(fā)者,，客戶被迫與新的需求分析者坐到一起。系統(tǒng)的分析人員說：“我們想與你談?wù)勀愕男枨蟆?#8221;客戶的第一反應(yīng)便是：“我已經(jīng)將我的要求都告訴你們前任了,，現(xiàn)在我要的就是給我編一個(gè)系統(tǒng)”,。而實(shí)際上，需求并未編寫成文檔,，因此新的分析人員不得不從頭做起,。所以如果只有一堆郵件、會(huì)談?dòng)涗浕蛞恍┝闼榈奈凑淼膶?duì)話,，你就確信你已明白用戶的需求,，那完全是自欺欺人。
需求的另外一種定義認(rèn)為需求是“用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開發(fā)工作的說明”,。有些需求分析專家拓展了這個(gè)概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點(diǎn),、功能及屬性等”。這些定義強(qiáng)調(diào)的是產(chǎn)品是什么樣的,，而并非產(chǎn)品是怎樣設(shè)計(jì),、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性：
需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明,。它描述了系統(tǒng)的行為,、特性或?qū)傩裕窃陂_發(fā)過程中對(duì)系統(tǒng)的約束。
從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個(gè)清晰,、毫無二義性的“需求”術(shù)語存在,，真正的“需求”實(shí)際上在人們的腦海中，這個(gè)人們主要是指客戶,，但一般情況下,，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進(jìn)一步和客戶核對(duì),。系統(tǒng)分析員和客戶需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí),。
任何文檔形式的需求（例如如下將要描述的需求規(guī)格說明書）僅是一個(gè)模型，一種描述,。

2．需求分析的任務(wù)
開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么,。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求,，這包括所有面向用戶,、面向機(jī)器和其它軟件系統(tǒng)的接口。同時(shí)這也是一旦做錯(cuò),，將最終會(huì)給系統(tǒng)帶來極大損害的部分,，并且以后再對(duì)它進(jìn)行修改也極為困難。
目前,，國(guó)內(nèi)產(chǎn)品的龐雜,，一家企業(yè)可能有幾個(gè)系統(tǒng)并立運(yùn)行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題,。
對(duì)于商業(yè)最終用戶應(yīng)用程序,，企業(yè)信息系統(tǒng)和軟件作為一個(gè)大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對(duì)于我們開發(fā)人員來說,，并沒有編寫出客戶認(rèn)可的需求文檔,，我們?nèi)绾沃理?xiàng)目于何時(shí)結(jié)束？而如果我們不知道什么對(duì)客戶來說是重要的,，那我們又如何能使客戶感到滿意呢,？
然而，即便并非出于商業(yè)目的的軟件需求也是必須的,。例如庫(kù),、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致,，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果,，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價(jià)，這些血的教訓(xùn)正在國(guó)內(nèi)的軟件開發(fā)者身上發(fā)生,。
近來,，我遇到一個(gè)開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件。不幸的是，當(dāng)他們開發(fā)完這個(gè)工具后,，發(fā)現(xiàn)這個(gè)工具不能打印出源代碼文件,，使用者當(dāng)然希望有這個(gè)功能。結(jié)果這個(gè)小組只好手工抄寫源代碼文檔以供代碼檢查,。這說明那怕需求明確無誤并構(gòu)思準(zhǔn)確,，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了,。
相反的情況,，我曾見一個(gè)要集成到“錯(cuò)誤跟蹤系統(tǒng)”中的簡(jiǎn)單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時(shí)發(fā)現(xiàn)簡(jiǎn)單的一張需求清單竟是如此有用,。他們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí),，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯(cuò)誤,。
事實(shí)上,，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。

3．需求分析過程
可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適,，如圖4-1所示：

圖4-1 需求工程域的層次分解示意圖
需求開發(fā)可進(jìn)一步分為：?jiǎn)栴}獲取,、分析、編寫規(guī)格說明和驗(yàn)證四個(gè)階段,。這些子項(xiàng)包括軟件類產(chǎn)品中需求收集,、評(píng)價(jià)、編寫文檔等所有活動(dòng),。需求開發(fā)活動(dòng)包括以下幾個(gè)方面：
確定產(chǎn)品所期望的用戶類別,。
獲取每個(gè)用戶類的需求。
了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求,。
分析源于用戶的信息以區(qū)別用戶任務(wù)需求,、功能需求、業(yè)務(wù)規(guī)則,、質(zhì)量屬性,、建議解決方法和附加信息。
將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng),，并將需求中的一部份分配給軟件組件,。
了解相關(guān)質(zhì)量屬性的重要性。
商討實(shí)施優(yōu)先級(jí)的劃分,。
將所收集的用戶需求編寫成文檔和模型,。
評(píng)審需求規(guī)格說明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí),，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚,。
需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的合同” 。這種合同都包含在編寫的需求文檔與模型中?？蛻舻慕邮軆H是需求成功的一半,，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中,。通常的需求管理活動(dòng)包括：
定義需求基線（迅速制定需求文檔的主體）,。
評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它,。
以一種可控制的方式將需求變更融入到項(xiàng)目中,。
使當(dāng)前的項(xiàng)目計(jì)劃與需求一致。
估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾,，這種承諾具體體現(xiàn)在項(xiàng)目解決方案上,。
讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤,。
在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其變更情況,。
以上幾點(diǎn)說明是我總結(jié)了成功實(shí)施項(xiàng)目后系統(tǒng)分析人員的經(jīng)驗(yàn)，同時(shí)也根據(jù)國(guó)內(nèi)外的其他系統(tǒng)實(shí)施的相關(guān)成功經(jīng)驗(yàn),，進(jìn)行了總結(jié)。

4．需求的類型
下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義,。
軟件需求包括三個(gè)不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）,。
1．業(yè)務(wù)需求（business requirement）反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng),、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說明,。
2．用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù),，這在使用實(shí)例（use case）文檔或方案腳本說明中予以說明。
3．功能需求(functional requirement)定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能,，使得用戶能完成他們的任務(wù),，從而滿足了業(yè)務(wù)需求。
在軟件需求規(guī)格說明書 （SRS）中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為,。軟件需求規(guī)格說明在開發(fā),、測(cè)試、質(zhì)量保證,、項(xiàng)目管理以及相關(guān)項(xiàng)目功能中都起了重要的作用,。對(duì)一個(gè)大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個(gè)子集,，因?yàn)榱硗庖恍┛赡軐儆谧酉到y(tǒng)（或軟件部件）,。
作為功能需求的補(bǔ)充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等,。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn),、規(guī)范和合約；外部界面的具體細(xì)節(jié),；性能要求,；設(shè)計(jì)或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對(duì)開發(fā)人員在軟件產(chǎn)品設(shè)計(jì)和構(gòu)造上的限制,。質(zhì)量屬性是通過多種角度對(duì)產(chǎn)品的特點(diǎn)進(jìn)行描述,，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對(duì)用戶和開發(fā)人員都極為重要,。
下面以一個(gè)字處理程序?yàn)槔齺碚f明需求的不同種類,。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯(cuò)誤”，該產(chǎn)品的包裝盒封面上可能會(huì)標(biāo)明這是個(gè)滿足業(yè)務(wù)需求的拼寫檢查器,。而對(duì)應(yīng)的用戶需求可能是“找出文檔中的拼寫錯(cuò)誤并通過一個(gè)提供的替換項(xiàng)列表來供選擇替換拼錯(cuò)的詞”,。同時(shí)，該拼寫檢查器還有許多功能需求,，如找到并高亮度提示錯(cuò)詞的操作,；顯示提供替換詞的對(duì)話框以及實(shí)現(xiàn)整個(gè)文檔范圍的替換。
從以上定義可以發(fā)現(xiàn),，需求并未包括設(shè)計(jì)細(xì)節(jié),、實(shí)現(xiàn)細(xì)節(jié)、項(xiàng)目計(jì)劃信息或測(cè)試信息,。需求與這些沒有關(guān)系,，它關(guān)注的是充分說明你究竟想開發(fā)什么。項(xiàng)目也有其它方面的需求,，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求,。盡管這些需求對(duì)項(xiàng)目成功也至關(guān)重要，但它們并非本書所要討論的,。

5．需求分析的原則
不重視需求過程的項(xiàng)目隊(duì)伍將自食其果,。需求工程中的缺陷將給項(xiàng)目成功帶來極大風(fēng)險(xiǎn)，這里的“成功”是指推出的產(chǎn)品能以合理的價(jià)格,、及時(shí)地在功能,、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風(fēng)險(xiǎn),。
不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險(xiǎn):
1. 無足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費(fèi)那么多功夫,，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因?yàn)殚_發(fā)人員感覺與用戶合作不如編寫代碼有意思,；二是因?yàn)殚_發(fā)人員覺得已經(jīng)明白用戶的需求了,。在某些情況下,，與實(shí)際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求,。但還是應(yīng)讓具有代表性的用戶在項(xiàng)目早期直接參與到開發(fā)隊(duì)伍中,，并一同經(jīng)歷整個(gè)開發(fā)過程。
系統(tǒng)人員在實(shí)踐過程中,，也有些感覺,，在實(shí)施一家公司的項(xiàng)目時(shí)，若無足夠的用戶參與,，系統(tǒng)人員獲得的需求是片面的,，不完整的，這樣系統(tǒng)在需求之初就埋下風(fēng)險(xiǎn),。
2. 用戶需求的不斷增加
在開發(fā)中若不斷地補(bǔ)充需求,，項(xiàng)目就越變?cè)烬嫶笠灾鲁^其計(jì)劃及預(yù)算范圍。計(jì)劃并不總是與項(xiàng)目需求規(guī)模與復(fù)雜性,、風(fēng)險(xiǎn),、開發(fā)生產(chǎn)率及需求變更實(shí)際情況相一致，這使得問題更難解決,。實(shí)際上,，問題根源在于用戶需求的改變和開發(fā)者對(duì)新需求所作的修改。
要想把需求變更范圍控制到最小,，必須一開始就對(duì)項(xiàng)目視圖,、范圍、目標(biāo),、約束限制和成功標(biāo)準(zhǔn)給予明確說明,，并將此說明作為評(píng)價(jià)需求變更和新特性的參照框架。說明中包括了對(duì)每種變更進(jìn)行變更影響因素分析的變更控制過程,，有助于所有風(fēng)險(xiǎn)承擔(dān)者明白業(yè)務(wù)決策的合理性，即為何進(jìn)行某些變更,，相應(yīng)消耗的時(shí)間,、資源或特性上的折中,。
產(chǎn)品開發(fā)中不斷延續(xù)的變更會(huì)使其整體結(jié)構(gòu)日漸紊亂，補(bǔ)丁代碼也使得整個(gè)程序難以理解和維護(hù)。插入補(bǔ)丁代碼使模塊違背強(qiáng)內(nèi)聚,、松耦合的設(shè)計(jì)原則，特別是如果項(xiàng)目配置管理工作不完善的話,，收回變更和刪除特性會(huì)帶來問題,。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個(gè)更為健壯的結(jié)構(gòu),，并能更好地適應(yīng)它,。這樣設(shè)計(jì)階段需求變更不會(huì)直接導(dǎo)致補(bǔ)丁代碼,，同時(shí)也有利于減少因變更導(dǎo)致質(zhì)量的下降。
3. 模棱兩可的需求
模棱兩可是需求規(guī)格說明中最為可怕的問題,。它的一層含義是指諸多讀者對(duì)需求說明產(chǎn)生了不同的理解,；另一層含義是指單個(gè)讀者能用不止一個(gè)方式來解釋某個(gè)需求說明。
模棱兩可的需求會(huì)使不同的風(fēng)險(xiǎn)承擔(dān)者產(chǎn)生不同的期望,，它會(huì)使開發(fā)人員為錯(cuò)誤問題而浪費(fèi)時(shí)間,，并且使測(cè)試者與開發(fā)者所期望的不一致。一位系統(tǒng)測(cè)試人員曾告訴我,，她所在的測(cè)試組經(jīng)常對(duì)需求理解有誤,，以致不得不重寫許多測(cè)試用例并重做許多測(cè)試。
處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊(duì)伍,。僅僅簡(jiǎn)單瀏覽一下需求文檔是不能解決模棱兩可問題的,。如果不同的評(píng)審者從不同的角度對(duì)需求說明給予解釋，但每個(gè)評(píng)審人員都真正了解需求文檔,，這樣二義性就不會(huì)直到項(xiàng)目后期才被發(fā)現(xiàn),，那時(shí)再發(fā)現(xiàn)的話會(huì)使得更正代價(jià)很大。
4. 不必要的特性
“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能,。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能性很有用,，以致在其上耗費(fèi)的努力“白搭”了。開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識(shí)的思路,，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時(shí)限內(nèi)的技術(shù)可行性之間求得平衡,，開發(fā)人員應(yīng)努力使功能簡(jiǎn)單易用，而不要未經(jīng)客戶同意,，擅自脫離客戶要求,，自作主張。
同樣,，客戶有時(shí)也可能要求一些看上去很“酷”,，但缺乏實(shí)用價(jià)值的功能，而實(shí)現(xiàn)這些功能只能徒耗時(shí)間和成本,。為了將“畫蛇添足”的危害盡量減小,，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”,，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能,。
5. 過于精簡(jiǎn)的規(guī)格說明
有時(shí)，客戶并不明白需求分析有如此重要,，于是只作一份簡(jiǎn)略之至的規(guī)格說明,，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項(xiàng)目進(jìn)展中去完善,，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明,。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況,。但在大多數(shù)情況下，這會(huì)給開發(fā)人員帶來挫折（使他們?cè)诓徽_的假設(shè)前提和極其有限的指導(dǎo)下工作）,，也會(huì)給客戶帶來煩惱（他們無法得到他們所設(shè)想的產(chǎn)品）,。
6. 忽略了用戶分類
大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異,，使用者受教育程度和經(jīng)驗(yàn)水平也不盡相同,。如果你不能在項(xiàng)目早期就針對(duì)所有這些主要用戶進(jìn)行分類的話，必然導(dǎo)致有的用戶對(duì)產(chǎn)品感到失望,。例如,，菜單驅(qū)動(dòng)操作對(duì)高級(jí)用戶太低效了，但含義不清的命令和快捷鍵又會(huì)使不熟練的用戶感到困難,。
7. 不準(zhǔn)確的計(jì)劃
據(jù)統(tǒng)計(jì),，導(dǎo)致需求過程中軟件成本估計(jì)極不準(zhǔn)確的原因主要有以下五點(diǎn)：頻繁的需求變更、遺漏的需求,、與用戶交流不夠,、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。
對(duì)不準(zhǔn)確的要求所提問題的正確響應(yīng)是“等我真正明白你的需求時(shí),，我就會(huì)來告訴你”,。基于不充分信息和未經(jīng)深思的對(duì)需求不成熟的估計(jì)很容易為一些因素左右,。要作出估計(jì)時(shí),，最好還是給出一個(gè)范圍。未經(jīng)準(zhǔn)備的估計(jì)通常是作為一種猜測(cè)給出的,，聽者卻認(rèn)為是一種承諾,。因此我們要盡力給出可達(dá)到的目標(biāo)并堅(jiān)持完成它。

6．需求分析人員和用戶的合作關(guān)系
優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求基礎(chǔ)之上的,。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作,。通常，開發(fā)人員與客戶或客戶代理人,，如市場(chǎng)人員間的關(guān)系反而會(huì)成為一種對(duì)立關(guān)系,。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下,，不會(huì)給雙方帶來一點(diǎn)益處。
只有當(dāng)雙方參與者都明白要成功自己需要什么,，同時(shí)也應(yīng)知道要成功合作方需要什么時(shí),，才能建立起一種合作關(guān)系。由于項(xiàng)目壓力與日漸增,，所有風(fēng)險(xiǎn)承擔(dān)者有著一個(gè)共同的目標(biāo)這一點(diǎn)容易被遺忘,。其實(shí)大家都想開發(fā)出一個(gè)既能實(shí)現(xiàn)商業(yè)價(jià)值,，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品,。
軟件客戶需求權(quán)利書列出了十條關(guān)于客戶在項(xiàng)目需求工程實(shí)施中與分析人員,、開發(fā)人員交流時(shí)的合法要求。每一項(xiàng)權(quán)利都對(duì)應(yīng)著軟件開發(fā)人員,、分析人員的義務(wù),。而軟件客戶需求義務(wù)書也列出了十條關(guān)于客戶在需求過程中應(yīng)承擔(dān)的義務(wù)。如果愿意,，可以將其作為開發(fā)人員的權(quán)利書,。
客戶有如下權(quán)利：
1：要求分析人員使用符合客戶語言習(xí)慣的表達(dá)
需求討論應(yīng)集中于業(yè)務(wù)需要和任務(wù)，故要使用業(yè)務(wù)術(shù)語,，你應(yīng)將其教給分析人員,，而你 不一定要懂得計(jì)算機(jī)的行業(yè)術(shù)語。
2：要求分析人員了解客戶的業(yè)務(wù)及目標(biāo)
通過與用戶交流來獲取用戶需求,、分析人員才能更好地了解你的業(yè)務(wù)任務(wù)和怎樣才能使產(chǎn)品更好地滿足你的需要,。這將有助于開發(fā)人員設(shè)計(jì)出真正滿足你的需要并達(dá)到你期望的優(yōu)秀軟件。為幫助開發(fā)人員和分析人員,，可以考慮邀請(qǐng)他們觀察你或你的同事是怎樣工作的,。如果新開發(fā)系統(tǒng)是用來替代已有的系統(tǒng)，那么開發(fā)人員應(yīng)使用一下目前的系統(tǒng),，這將有利于他們明白目前系統(tǒng)是怎樣工作的,，其工作流程的情況，以及可供改進(jìn)之處,。
3：要求分析人員編寫軟件需求規(guī)格說明
分析人員要把從你和其他客戶那里獲得的所有信息進(jìn)行整理,，以區(qū)分開業(yè)務(wù)需求及規(guī)范、功能需求,、質(zhì)量目標(biāo),、解決方法和其它信息。通過這些分析就能得到一份軟件需求規(guī)格說明,。而這份軟件需求規(guī)格說明便在開發(fā)人員和客戶之間針對(duì)要開發(fā)的產(chǎn)品內(nèi)容達(dá)成了協(xié)議,。軟件需求規(guī)格說明書可以用一種你認(rèn)為易于翻閱和理解的方式組織編寫。要評(píng)審編寫出的規(guī)格說明以確保它們準(zhǔn)確而完整地表達(dá)了你的需求,。一份高質(zhì)量的軟件需求規(guī)格說明能有助于開發(fā)人員開發(fā)出真正需要的產(chǎn)品,。
4：要求得到需求工作結(jié)果的解釋說明
分析人員可能采用了多種圖表作為文字性軟件需求規(guī)格說明的補(bǔ)充。因?yàn)槿绻ぷ髁鞒虉D那樣的圖表能很清楚地描述出系統(tǒng)行為的某些方面,。所以需求說明中的各種圖表有著極高的價(jià)值,。雖然它們不太難于理解，但是你很可能對(duì)此并不熟悉,。因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發(fā)工作結(jié)果和符號(hào)的意義,，及怎樣檢查圖表有無錯(cuò)誤及不一致等,。
5：要求開發(fā)人員尊重你的意見
如果用戶與開發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會(huì)有障礙,，共同合作能使大家“兼聽則明”,。參與需求開發(fā)過程的客戶有權(quán)要求開發(fā)人員尊重他們并珍惜他們?yōu)轫?xiàng)目成功所付出的時(shí)間。同樣,，客戶也應(yīng)對(duì)開發(fā)人員為項(xiàng)目成功這一共同目標(biāo)所作出的努力表示尊重與感激,。
6：要求開發(fā)人員對(duì)需求及產(chǎn)品實(shí)施提供建議，拿出主意
通常,，客戶所說的“需求”已是一種實(shí)際可能的實(shí)施解決方案,，分析人員將盡力從這些解決方法中了解真正的業(yè)務(wù)及其需求，同時(shí)還應(yīng)找出已有系統(tǒng)不適合當(dāng)前業(yè)務(wù)之處,，以確保產(chǎn)品不會(huì)無效或低效,。在徹底弄清業(yè)務(wù)領(lǐng)域內(nèi)的事情后，分析人員有時(shí)就能提出相當(dāng)好的改進(jìn)方法,。有經(jīng)驗(yàn)且富有創(chuàng)造力的分析人員還能提出增加一些用戶并未發(fā)現(xiàn)的很有價(jià)值的系統(tǒng)特性,。
7：描述產(chǎn)品易使用的特性
你可以要求分析人員在實(shí)現(xiàn)功能需求的同時(shí)還要注重軟件的易用性。因?yàn)檫@些易用特性或質(zhì)量屬性能使你更準(zhǔn)確,、高效地完成任務(wù),。例如，客戶有時(shí)要求產(chǎn)品要“用戶友好”或“健壯”或“高效率”,，但這對(duì)于開發(fā)人員來說,，太主觀了并無實(shí)用價(jià)值。正確的應(yīng)是：分析人員通過詢問和調(diào)查了解客戶所要的友好,、健壯,、高效所包含的具體特性。
8：調(diào)整需求,，允許重用已有的軟件組件
需求通常要有一定的靈活性,。分析人員可能發(fā)現(xiàn)已有的某個(gè)軟件組件與你描述的需求很相符。在這種情況下,，分析人員應(yīng)提供一些修改需求的選擇以便開發(fā)人員能夠在新系統(tǒng)開發(fā)中重用一些已有的軟件,。如果有可重用的機(jī)會(huì)出現(xiàn)，同時(shí)你又能調(diào)整你的需求說明,，那就能降低成本和節(jié)省時(shí)間,，而不必嚴(yán)格按原有的需求說明開發(fā)。所以說,，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件,，而它們并不完全適合你所需的特性，這時(shí)一定程度上的需求靈活性就顯得極為重要了。
9：獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)
每個(gè)人都希望項(xiàng)目獲得成功,。但這不僅要求你要清晰地告知開發(fā)人員關(guān)于系統(tǒng)“做什么”所需的所有信息，而且還要求開發(fā)人員能通過交流了解清楚取舍與限制,。一定要明確說明你的假設(shè)和潛在的期望,。否則，開發(fā)人員開發(fā)出的產(chǎn)品很可能無法讓你滿意,。

客戶有下列義務(wù)：
1：給分析人員講解你的業(yè)務(wù)
分析人員要依靠你給他們講解的業(yè)務(wù)概念及術(shù)語,。但你不能指望分析人員會(huì)成為該領(lǐng)域的專家，而只能讓他們真正明白你的問題和目標(biāo),。不要期望分析人員能把握你們業(yè)務(wù)的細(xì)微與潛在之處,，他們很可能并不知道那些對(duì)于你和你的同事來說理所當(dāng)然的“常識(shí)”。
2：抽出時(shí)間清楚地說明并完善需求
客戶很忙,，經(jīng)常在最忙的時(shí)候還得參與需求開發(fā),。但無論如何，你有義務(wù)抽出時(shí)間參與“頭腦風(fēng)暴”會(huì)議的討論,，接受采訪或其它獲取需求的活動(dòng),。有時(shí)分析人員可能先以為明白了你的觀點(diǎn)，而過后發(fā)現(xiàn)還需要你的講解,。這時(shí),，請(qǐng)耐心一些對(duì)待需求和需求的精化工作過程中的反復(fù)，因?yàn)樗侨藗兘涣髦械暮茏匀坏默F(xiàn)象,，何況這對(duì)軟件產(chǎn)品的成功極為重要,。
3：準(zhǔn)確而詳細(xì)地說明需求
編寫一份清晰、準(zhǔn)確的需求文檔是很困難的,。由于處理細(xì)節(jié)問題不但煩人而且又耗時(shí),，故很容易留下模糊不清的需求。但是,，在開發(fā)過程中,，必須得解決這種模糊性和不準(zhǔn)確性。而你恰是為解決這些問題作出決定的最佳人選,。不然的話,，你就只好靠開發(fā)人員去正確猜測(cè)了。在需求規(guī)格說明中暫時(shí)加上待定（to be determined, TBD也可采用漢語拼音略寫“DQD：待確定”）的標(biāo)志是個(gè)不錯(cuò)的辦法,。用該標(biāo)志可指明了哪些需要進(jìn)一步探討,、分析或增加信息的地方。不過,，有時(shí)也可能因?yàn)槟硞€(gè)特殊需求難以解決或沒有人愿意處理它而注上TBD標(biāo)志,。盡量將每項(xiàng)需求的內(nèi)容都闡述清楚，以便分析人員能準(zhǔn)確的將其寫進(jìn)軟件需求規(guī)格說明中。如果你一時(shí)不能準(zhǔn)確表述,，那就得允許獲取必要的準(zhǔn)確信息這樣一個(gè)過程,。通常使用所謂的原型技術(shù)。通過開發(fā)的原型,，你可以同開發(fā)人員一起反復(fù)修改,，不斷完善需求定義。
4：及時(shí)地作出決定
正如一位建筑師為你修建房屋,，分析人員將要求你做出一些選擇和決定,。這些決定包括來自多個(gè)用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)做出決定的客戶必須積極地對(duì)待這一切,，盡快做處理,、做決定。因?yàn)殚_發(fā)人員通常只有等你做出了決定才能行動(dòng),，而這種等待會(huì)延誤項(xiàng)目的進(jìn)展,。
5：尊重開發(fā)人員的需求可行性及成本評(píng)估
所有的軟件功能都有其成本價(jià)格，開發(fā)人員最適合預(yù)算這些成本（盡管許多開發(fā)人員并不擅長(zhǎng)評(píng)估預(yù)測(cè)）,。你所希望的某些產(chǎn)品特性可能在技術(shù)上行不通,，或者實(shí)現(xiàn)它要付出極為高昂的代價(jià)。而某些需求試圖在操作環(huán)境中要求不可能達(dá)到的性能或試圖得到一些根本得不到的數(shù)據(jù),，開發(fā)人員會(huì)對(duì)此作出負(fù)面的評(píng)價(jià)意見,，你應(yīng)該尊重他們的意見。有時(shí),，你可以重新給出一個(gè)在技術(shù)上可行,、實(shí)現(xiàn)上便宜的需求，例如,，要求某個(gè)行為在“瞬間”發(fā)生是不可行的,，但換種更具體的時(shí)間需求說法（“在50ms以內(nèi)”,但若沒有準(zhǔn)確的技術(shù)分析不能輕易下結(jié)論），這就可以實(shí)現(xiàn)了,。
6： 劃分需求優(yōu)先級(jí)別
大多數(shù)項(xiàng)目沒有足夠的時(shí)間或資源來實(shí)現(xiàn)功能性的每個(gè)細(xì)節(jié),。決定哪些特性是必要的，哪些是重要的,，哪些是好的,，是需求開發(fā)的主要部分。只能由你來負(fù)責(zé)設(shè)定需求優(yōu)先級(jí),，因?yàn)殚_發(fā)者并不可能按你的觀點(diǎn)決定需求優(yōu)先級(jí),。開發(fā)者將為你確定優(yōu)先級(jí)提供有關(guān)每個(gè)需求的花費(fèi)和風(fēng)險(xiǎn)的信息。當(dāng)你設(shè)定優(yōu)先級(jí)時(shí),，你幫助開發(fā)者確保在適當(dāng)?shù)臅r(shí)間內(nèi)用最小的開支取得最好的效果,。在時(shí)間和資源限制下,，關(guān)于所需特性能否完成或完成多少應(yīng)該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在項(xiàng)目中未被實(shí)現(xiàn),，但畢竟是要面對(duì)這種現(xiàn)實(shí)的,。業(yè)務(wù)決策有時(shí)不得不依據(jù)優(yōu)先級(jí)來縮小項(xiàng)目范圍或延長(zhǎng)工期，或增加資源,，或在質(zhì)量上尋找折衷,。
7：評(píng)審需求文檔和原型
正如我們將在第1 4章討論的，無論是正式的還是非正式的方式,，對(duì)需求文檔進(jìn)行評(píng)審都會(huì)對(duì)軟件質(zhì)量提高有所幫助。讓客戶參與評(píng)審才能真正鑒別需求文檔是否的確完整,、正確說明了期望的必要特性,。評(píng)審也給客戶代表提供一個(gè)機(jī)會(huì)，給需求分析人員帶來反饋信息以改進(jìn)他們的工作,。如果你認(rèn)為編寫的需求文檔不夠準(zhǔn)確,，就有義務(wù)盡早告訴分析人員并為改進(jìn)提供建議。通過閱讀需求規(guī)格說明,，很難想象實(shí)際的軟件是什么樣子的,。更好的方法是先為產(chǎn)品開發(fā)一個(gè)原型。這樣你就能提供更有價(jià)值的反饋信息給開發(fā)人員,，幫助他們更好地理解你的需求,。必須認(rèn)識(shí)到：原型并非是一個(gè)實(shí)際產(chǎn)品，但開發(fā)人員能將其轉(zhuǎn)變,、擴(kuò)充成功能齊全的系統(tǒng),。
8：需求出現(xiàn)變更要馬上聯(lián)系
不斷的需求變更會(huì)給在預(yù)定計(jì)劃內(nèi)完成高質(zhì)量產(chǎn)品帶來嚴(yán)重的負(fù)面影響。變更是不可避免的,，但在開發(fā)周期中變更越在晚期出現(xiàn),，其影響越大。變更不僅會(huì)導(dǎo)致代價(jià)極高的返工,，而且工期也會(huì)被迫延誤,，特別是在大體結(jié)構(gòu)已完成后又需要增加新特性時(shí)。所以一旦你發(fā)現(xiàn)需要變更需求時(shí),，請(qǐng)一定立即通知分析人員,。
9：應(yīng)遵照開發(fā)組織處理需求變更的過程
為了將變更帶來的負(fù)面影響減少到最低限度，所有的參與者必須遵照項(xiàng)目的變更控制過程,。這要求不放棄所有提出的變更,，對(duì)每項(xiàng)要求的變更進(jìn)行分析、綜合考慮,，最后作出合適的決策以確定將某些變更引入項(xiàng)目中,。
10：尊重開發(fā)人員采用的需求工程過程
軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認(rèn)為需求過程不太劃算,，但請(qǐng)相信花在需求開發(fā)上的時(shí)間是“很有價(jià)值”的,。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術(shù),，那么整個(gè)過程將會(huì)更為順利,。盡管去詢問分析人員為什么他們要收集某些信息，或參與與需求有關(guān)的活動(dòng),。
系統(tǒng)分析人員在開發(fā)過程中可能會(huì)遇到以下問題,，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導(dǎo)致不理想的產(chǎn)品,。故一定要確保需求開發(fā)中的主要參與者都了解并接受他們的義務(wù),。如果遇到分歧，通過協(xié)商以達(dá)成對(duì)各自義務(wù)的相互理解,，這樣能減少今后的摩擦,。

7．需求文檔
需求開發(fā)的最終成果是：客戶和開發(fā)小組對(duì)將要開發(fā)的產(chǎn)品達(dá)成一致協(xié)議。協(xié)議綜合了業(yè)務(wù)需求,、用戶需求和軟件功能需求,。就像我們?cè)缦人吹降模?xiàng)目視圖和范圍文檔包含了業(yè)務(wù)需求,，而使用實(shí)例文檔則包含了用戶需求,。你必須編寫從使用實(shí)例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔,，包括質(zhì)量屬性和外部接口需求,。只有以結(jié)構(gòu)化和可讀性方式編寫這些文檔，并由項(xiàng)目的風(fēng)險(xiǎn)承擔(dān)者評(píng)審?fù)ㄟ^后,，各方面人員才能確信他們所贊同的需求是可靠的,。
你可以使用以下三種方法編寫軟件需求規(guī)格說明：
用好的結(jié)構(gòu)化和自然語言編寫文本型文檔。
建立圖形化模型,，這些模型可以描繪轉(zhuǎn)換過程,、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系,、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系,。
編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上精確的形式化邏輯語言來定義需求,。
由于形式化規(guī)格說明具有很強(qiáng)的嚴(yán)密性和精確度,，因此，所使用的形式化語言只有極少數(shù)軟件開發(fā)人員才熟悉,，更不用說客戶了,。雖然結(jié)構(gòu)化的自然語言具有許多缺點(diǎn),，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實(shí)的方法,。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已經(jīng)為大多數(shù)項(xiàng)目所接受,。圖形化分析模型通過提供另一種需求視圖，增強(qiáng)了軟件需求規(guī)格說明,。
軟件需求規(guī)格說明不僅是系統(tǒng)測(cè)試和用戶文檔的基礎(chǔ),，也是所有子系列項(xiàng)目規(guī)劃、設(shè)計(jì)和編碼的基礎(chǔ),。它應(yīng)該盡可能完整地描述系統(tǒng)預(yù)期的外部行為和用戶可視化行為,。除了設(shè)計(jì)和實(shí)現(xiàn)上的限制，軟件需求規(guī)格說明不應(yīng)該包括設(shè)計(jì),、構(gòu)造,、測(cè)試或工程管理的細(xì)節(jié)。許多讀者使用軟件需求規(guī)格說明來達(dá)到不同的目的：
客戶和營(yíng)銷部門依賴它來了解他們所能提供的產(chǎn)品,。
項(xiàng)目經(jīng)理根據(jù)包含在軟件需求規(guī)格說明中描述的產(chǎn)品來制定規(guī)劃并預(yù)測(cè)進(jìn)度安排、工作量和資源,。
軟件開發(fā)小組依賴它來理解他們將要開發(fā)的產(chǎn)品,。
測(cè)試小組使用軟件需求規(guī)格說明中對(duì)產(chǎn)品行為的描述制定測(cè)試計(jì)劃、測(cè)試用例和測(cè)試過程,。
軟件維護(hù)和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的某部分是做什么的,。
產(chǎn)品發(fā)布組在需求規(guī)格說明和用戶界面設(shè)計(jì)的基礎(chǔ)上編寫客戶文檔，如用戶手冊(cè)和幫助屏幕等,。
培訓(xùn)人員根據(jù)需求規(guī)格說明和用戶文檔編寫培訓(xùn)材料,。
軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設(shè),。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說明,，那么它將不能作為協(xié)議的一部分并且不能在產(chǎn)品中出現(xiàn)。
我見過有一個(gè)項(xiàng)目突然接到測(cè)試人員發(fā)出的錯(cuò)誤災(zāi)難的報(bào)告,。結(jié)果是他們測(cè)試的是老版本的軟件需求規(guī)格說明,，而他們覺得錯(cuò)誤的地方正是產(chǎn)品所獨(dú)有的特性。他們的測(cè)試工作是徒勞的,，因?yàn)樗麄円恢痹诶习姹镜能浖枨笠?guī)格說明中尋找錯(cuò)誤的系統(tǒng)行為,。
在編寫軟件需求規(guī)格說明，希望讀者牢記以下的建議：
對(duì)節(jié),、小節(jié)和單個(gè)需求的號(hào)碼編排必須一致,。
在右邊部分留下文本注釋區(qū)。
允許不加限制地使用空格,。
正確使用各種可視化強(qiáng)調(diào)標(biāo)志（例如,，黑體,、下劃線、斜體和其它不同字體）,。
創(chuàng)建目錄表和索引表有助于讀者尋找所需的信息,。
對(duì)所有圖和表指定號(hào)碼和標(biāo)識(shí)號(hào)，并且可按號(hào)碼進(jìn)行查閱,。
使用字處理程序中交叉引用的功能來查閱文檔中其它項(xiàng)或位置,，而不是通過頁碼或節(jié)號(hào)。
為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標(biāo)準(zhǔn),，必須唯一確定每個(gè)軟件需求,。這可以使你在變更請(qǐng)求、修改歷史記錄,、交叉引用或需求的可跟蹤矩陣中查閱特定的需求,。由于要達(dá)到這一目的，用單一的項(xiàng)目列表是不夠的,，因此,，我將描述幾個(gè)不同的需求標(biāo)識(shí)方法，并闡明它們的優(yōu)點(diǎn)與缺點(diǎn),?？梢赃x擇最適合你的方法。
(1) 序列號(hào)最簡(jiǎn)單的方法是賦予每個(gè)需求一個(gè)唯一的序列號(hào),，例如SRS-13,。當(dāng)一個(gè)新的需求加入到商業(yè)需求管理工具的數(shù)據(jù)庫(kù)之后，這些管理工具就會(huì)為其分配一個(gè)序列號(hào)（許多這樣的工具也支持層次化編號(hào)）,。序列號(hào)的前綴代表了需求類型,，例如SRS代表“軟件需求說明”。由于序列號(hào)不能重用,，所以把需求從數(shù)據(jù)庫(kù)中刪除時(shí),，并不釋放其所占據(jù)的序列號(hào)，而新的需求只能得到下一個(gè)可用的序列號(hào),。這種簡(jiǎn)單的編號(hào)方法并不能提供任何相關(guān)需求在邏輯上或?qū)哟紊系膮^(qū)別,，而且需求的標(biāo)識(shí)不能提供任何有關(guān)每個(gè)需求內(nèi)容的信息。
(2) 層次化編碼這也許是最常用的方法,。如果功能需求出現(xiàn)在軟件需求規(guī)格說明中第3 . 2部分,，那么它們將具有諸如3.2.4.3這樣的標(biāo)識(shí)號(hào)。標(biāo)識(shí)號(hào)中的數(shù)字越多則表示該需求越詳細(xì),，屬于較低層次上的需求,。即使在一個(gè)中型的軟件需求規(guī)格說明中，這些標(biāo)識(shí)號(hào)也會(huì)擴(kuò)展到許多位數(shù)字,，并且這些標(biāo)識(shí)也不提供任何有關(guān)每個(gè)需求目的的信息,。如果你要插入一個(gè)新的需求,，那么該需求所在部分其后所有需求的序號(hào)將要增加。刪除或移去一個(gè)需求,，那么該需求所在部分其后所有需求的序號(hào)將要減少,。但其他地方的引用將混亂，對(duì)于這種簡(jiǎn)單的層次化編號(hào)的一種改進(jìn)方法是對(duì)需求中主要的部分進(jìn)行層次化編號(hào),，然后對(duì)于每個(gè)部分中的單一功能需求用一個(gè)簡(jiǎn)短文字代碼加上一個(gè)序列號(hào)來識(shí)別,。例如，軟件需求規(guī)格說明可能包含“第3.2.5部分—編輯功能”,，并將此部分編寫成子模塊文檔,，然后配置管理。
有時(shí),，你覺得缺少特定需求的某些信息,。在解決這個(gè)不確定性之前，可能必須與客戶商議,、檢查與另一個(gè)系統(tǒng)的接口或者定義另一個(gè)需求,。使用“待確定”（to be determined, TBD或采用漢語拼音略寫DQD）符號(hào)作為標(biāo)準(zhǔn)指示器來強(qiáng)調(diào)軟件需求規(guī)格說明中這些需求的缺陷。通過這種方法,，你可以在軟件需求規(guī)格說明中查找所要澄清需求的部分,。記錄誰將解決哪個(gè)問題、怎樣解決及什么時(shí)候解決,。把每個(gè)TBD編號(hào)并創(chuàng)建一個(gè)TBD列表，這有助于方便地跟蹤每個(gè)項(xiàng)目,。
在繼續(xù)進(jìn)行構(gòu)造需求集合之前,，必須解決所有的TBD問題，因?yàn)槿魏芜z留下來的不確定問題將會(huì)增加出錯(cuò)的風(fēng)險(xiǎn)和需求返工,。當(dāng)開發(fā)人員遇到一個(gè)TBD問題或其它模糊之處時(shí),，他可能不會(huì)返回到原始需求來解決問題。多半開發(fā)者對(duì)它進(jìn)行猜測(cè),，但并不總是正確的,。如果有TBD問題尚未解決，而你又要繼續(xù)進(jìn)行開發(fā)工作,，那么盡可能推遲實(shí)現(xiàn)這些需求,，或者解決這些需求的開放式問題，把產(chǎn)品的這部分設(shè)計(jì)得易于更改,。
編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法,，最好是根據(jù)經(jīng)驗(yàn)進(jìn)行。從過去所遇到的問題中可使你受益匪淺,。許多需求文檔可以通過使用有效的技術(shù)編寫風(fēng)格和使用用戶術(shù)語而不是計(jì)算機(jī)專業(yè)術(shù)語的方式得以改進(jìn),。
你在編寫優(yōu)秀的需求文檔時(shí),，希望讀者還需牢記以下幾點(diǎn)建議：
保持語句和段落的簡(jiǎn)短。
采用主動(dòng)語態(tài)的表達(dá)方式,。
編寫具有正確的語法,、拼寫和標(biāo)點(diǎn)的完整句子。
使用的術(shù)語與詞匯表中所定義的應(yīng)該一致,。
需求陳述應(yīng)該具有一致的樣式,，例如“系統(tǒng)必須..”或者“用戶必須..”，并緊跟一個(gè)行為動(dòng)作和可觀察的結(jié)果,。例如,，“倉(cāng)庫(kù)管理子系統(tǒng)必須顯示一張所請(qǐng)求的倉(cāng)庫(kù)中有存貨的庫(kù)存清單。”
為了減少不確定性,，必須避免模糊的,、主觀的術(shù)語，例如,，用戶友好,、簡(jiǎn)單、有效,、,、最新技術(shù)、優(yōu)越的,、可接受的等,。當(dāng)用客說“用戶友好”或者“快”時(shí)，你應(yīng)該明確它們的真正含義并且在需求中闡明用戶的意圖,。
避免使用比較性的詞匯,，定量地說明所需要提高的程度或者說清一些參數(shù)可接受的最大值和最小值。當(dāng)客戶說明系統(tǒng)應(yīng)該“處理”,、“支持”或“管理”某些事情時(shí),，你應(yīng)該能理解客戶的意圖。由于需求的編寫是層次化的,，因此,，可以把頂層不明確的需求向低層詳細(xì)分解，直到消除不明確性為止,。
文檔的編寫人員不應(yīng)該把多個(gè)需求集中在一個(gè)冗長(zhǎng)的敘述段落中,。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個(gè)需求,。務(wù)必記住,，不要在需求說明中使用“和/或”，“等等”之類的連詞,。

8．需求分析的過程
需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步,。獲取需求的一個(gè)必不可少的結(jié)果是對(duì)項(xiàng)目中描述的客戶需求的普遍理解,。一旦理解了需求，分析者,、開發(fā)者和客戶就能探索出描述這些需求的多種解決方案,。參與需求獲取者只有在他們理解了問題之后才能開始設(shè)計(jì)系統(tǒng)，否則,，對(duì)需求定義的任何改進(jìn),，設(shè)計(jì)上都必須大量的返工。把需求獲取集中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設(shè)計(jì)問題而造成的失誤,。
需求獲取,、分析、編寫需求規(guī)格說明和驗(yàn)證并不遵循線性的順序,，這些活動(dòng)是相互隔開,、增量和反復(fù)的。當(dāng)你和客戶合作時(shí),，你就將會(huì)問一些問題,，并且取得他們所提供的信息（需求獲取）,。同時(shí),，你將處理這些信息以理解它們，并把它們分成不同的類別,，還要把客戶需求同可能的軟件需求相聯(lián)系,。然后，你可以使客戶信息結(jié)構(gòu)化,，并編寫成文檔和示意圖,。下一步，就可以讓客戶代表評(píng)審文檔并糾正存在的錯(cuò)誤,。這四個(gè)過程貫穿著需求開發(fā)的整個(gè)階段。
由于軟件開發(fā)項(xiàng)目和組織文化的不同,，對(duì)于需求開發(fā)沒有一個(gè)簡(jiǎn)單的,、公式化的途徑。下面列出了1 4個(gè)步驟,，你可以利用它們指導(dǎo)你的需求開發(fā)活動(dòng),。對(duì)于需求的任何子集，一旦你完成了第十三步,，那么你就可以很有信心地繼續(xù)進(jìn)行系統(tǒng)的每一部分的設(shè)計(jì),、構(gòu)造，因?yàn)槟銓㈤_發(fā)出一個(gè)好的產(chǎn)品:
1. 定義項(xiàng)目的視圖和范圍,。
2. 確定用戶類,。
3. 在每個(gè)用戶類中確定適當(dāng)?shù)拇怼?br>4. 確定需求決策者和他們的決策過程,。
5. 選擇你所用的需求獲取技術(shù)。
6. 運(yùn)用需求獲取技術(shù)對(duì)作為系統(tǒng)一部分的使用實(shí)例進(jìn)行開發(fā)并設(shè)置優(yōu)先級(jí),。
7. 從用戶那里收集質(zhì)量屬性的信息和其它非功能需求,。
8. 詳細(xì)擬訂使用實(shí)例使其融合到必要的功能需求中。
9. 評(píng)審使用實(shí)例的描述和功能需求,。
10. 如果有必要,，就要開發(fā)分析模型用以澄清需求獲取的參與者對(duì)需求的理解。
11. 開發(fā)并評(píng)估用戶界面原型以助想像還未理解的需求,。
12. 從使用實(shí)例中開發(fā)出概念測(cè)試用例,。
13. 用測(cè)試用例來論證使用實(shí)例、功能需求,、分析模型和原型,。
14. 在繼續(xù)進(jìn)行設(shè)計(jì)和構(gòu)造系統(tǒng)每一部分之前，重復(fù)6~1 3步,。
需求獲取可能是軟件開發(fā)中最困難,、最關(guān)鍵、最易出錯(cuò)及最需要交流的方面,。需求獲取只有通過有效的客戶—開發(fā)者的合作才能成功,。分析者必須建立一個(gè)對(duì)問題進(jìn)行徹底探討的環(huán)境，而這些問題與產(chǎn)品有關(guān),。為了方便清晰地進(jìn)行交流,，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法,。對(duì)需求問題的全面考察需要一種技術(shù),，利用這種技術(shù)不但考慮了問題的功能需求方面，還可討論項(xiàng)目的非功能需求,。確定用戶已經(jīng)理解：對(duì)于某些功能的討論并不意味著即將在產(chǎn)品中實(shí)現(xiàn)它,。對(duì)于想到的需求必須集中處理并設(shè)定優(yōu)先級(jí)，以避免一個(gè)不能帶來任何益處的無限大的項(xiàng)目,。
需求獲取是一個(gè)需要高度合作的活動(dòng),，而并不是客戶所說的需求的簡(jiǎn)單拷貝。作為一個(gè)分析者,，你必須透過客戶所提出的表面需求理解他們的真正需求,。詢問一個(gè)可擴(kuò)充的問題有助于你更好地理解用戶目前的業(yè)務(wù)過程并且知道新系統(tǒng)如何幫助或改進(jìn)他們的工作。
需求獲取利用了所有可用的信息來源,，這些信息描述了問題域或在軟件解決方案中合理的特性,。一個(gè)研究表明：比起不成功的項(xiàng)目，一個(gè)成功的項(xiàng)目在開發(fā)者和客戶之間采用了更多的交流方式。與單個(gè)客戶或潛在的用戶組一起座談,，對(duì)于業(yè)務(wù)軟件包或信息管理系統(tǒng)（MIS）的應(yīng)用來說是一種傳統(tǒng)的需求來源,。
在每一次座談?dòng)懻撝螅浵滤懻摰臈l目,，并請(qǐng)參與討論的用戶評(píng)論并更正,。及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑，因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求,。進(jìn)行深入收集和分析以消除任何沖突或不一致性,。盡量理解用戶用于表述他們需求的思維過程。充分研究用戶執(zhí)行任務(wù)時(shí)作出決策的過程,，并提取出潛在的邏輯關(guān)系,。流程圖和決策樹是描述這些邏輯決策途徑的好方法。
當(dāng)進(jìn)行需求獲取時(shí),，應(yīng)避免受不成熟的細(xì)節(jié)的影響,。在對(duì)切合的客戶任務(wù)取得共識(shí)之前，用戶能很容易地在一個(gè)報(bào)表或?qū)υ捒蛑辛谐雒恳豁?xiàng)的精確設(shè)計(jì),。如果這些細(xì)節(jié)都作為需求記錄下來,，他們會(huì)給隨后的設(shè)計(jì)過程帶來不必要的限制。你可能要周期性地檢查需求獲取,，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上,。向他們保證在開發(fā)過程中，將會(huì)詳盡闡述他們的需求,。
在一個(gè)逐次詳細(xì)描述過程中,，重復(fù)地詳述需求，以確定用戶目標(biāo)和任務(wù),，并作為使用實(shí)例,。然后，把任務(wù)描述成功能需求,，這些功能需求可以使用戶完成其任務(wù),，也可以把它們描述成非功能需求，這些非功能需求描述了系統(tǒng)的限制和用戶對(duì)質(zhì)量的期望,。雖然最初的屏幕構(gòu)思有助于描述你對(duì)需求的理解,，但是你必須細(xì)化用戶界面設(shè)計(jì)。

作者小傳：
曹偉,，南京易點(diǎn)網(wǎng)絡(luò)軟件公司技術(shù)總監(jiān)。從ERP的系統(tǒng)開發(fā),，對(duì)整體系統(tǒng)有較強(qiáng)的認(rèn)識(shí)欲望,，現(xiàn)正在實(shí)施企業(yè)級(jí)軟件系統(tǒng)構(gòu)架，實(shí)施一個(gè)國(guó)際化企業(yè)電子化的解決方案。