-.z如何進(jìn)展軟件需求分析1、概念需求的定義包括從用戶角度〔系統(tǒng)的外部行為〕，以及從開發(fā)者角度〔一些部特性〕來闡述需求。關(guān)鍵的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個工程中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起。系統(tǒng)的分析人員說：“我們想與你談?wù)勀愕男枨蟆（暱蛻舻牡谝环错懕闶牵骸拔乙呀?jīng)將我的要求都告訴你們前任了，現(xiàn)在我要的就是給我編一個系統(tǒng)〞。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。需求的另外一種定義認(rèn)為需“用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明〞。有些需求分析專家拓展了這個概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點、功能及屬性等〞。這些定義強(qiáng)調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計、構(gòu)造的。而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性：需指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_發(fā)過程中對系統(tǒng)的約束。從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個清晰、毫無二義性的“需求〞術(shù)語存在，真正的“需求〞實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進(jìn)一步和客戶核對。系統(tǒng)分析員和客戶需要確保所有工程風(fēng)險承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識。任何文檔形式的需求〔例如如下將要描述的需求規(guī)格說明書〕僅是一個模型，一種描述。2．需求分析的任務(wù)開發(fā)軟件系統(tǒng)最為困難的局部就是準(zhǔn)確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的局部，并且以后再對它進(jìn)展修改也極為困難。目前，國產(chǎn)品的龐雜，一家企業(yè)可能有幾個系統(tǒng)并立運行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。對于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一局部的產(chǎn)品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃拦こ逃诤螘r完畢.而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢.然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組部使用的軟件。當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可防止的后果，而重新編制代碼的代價遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價，這些血的教訓(xùn)正在國的軟件開發(fā)者身上發(fā)生。近來，我遇到一個開發(fā)小組開發(fā)包括代碼編輯器在的一套部使用的計算機(jī)輔助軟件。不幸的是，當(dāng)他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，使用者當(dāng)然希望有這個功能。結(jié)果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構(gòu)思準(zhǔn)確，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了。相反的情況，我曾見一個要集成到“錯誤跟蹤系統(tǒng)〞中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時發(fā)現(xiàn)簡單的一需求清單竟是如此有用。他們依據(jù)需求對系統(tǒng)進(jìn)展測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。事實上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。3．需求分析過程可把整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩局部更適宜，如圖4-1所示：圖4-1需求工程域的層次分解示意圖需求開發(fā)可進(jìn)一步分為：問題獲取、分析、編寫規(guī)格說明和驗證四個階段。這些子項包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。需求開發(fā)活動包括以下幾個方面：確定產(chǎn)品所期望的用戶類別。獲取每個用戶類的需求。了解實際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求。分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。了解相關(guān)質(zhì)量屬性的重要性。商討實施優(yōu)先級的劃分。將所收集的用戶需求編寫成文檔和模型。評審需求規(guī)格說明，確保對用戶需求到達(dá)共同的理解與認(rèn)識，并在整個開發(fā)小組承受說明之前將問題都弄清楚。需求管理需要“建立并維護(hù)在軟件工程中同客戶達(dá)成的合同〞。這種合同都包含在編寫的需求文檔與模型中。客戶的承受僅是需求成功的一半，開發(fā)人員也必須能夠承受他們，并真正把需求應(yīng)用到產(chǎn)品中。通常的需求管理活動包括：定義需求基線〔迅速制定需求文檔的主體〕。評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。以一種可控制的方式將需求變更融入到工程中。使當(dāng)前的工程方案與需求一致。估計變更需求所產(chǎn)生影響并在此根底上協(xié)商新的承諾，這種承諾具體表達(dá)在工程解決方案上。讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。在整個工程過程中跟蹤需求狀態(tài)及其變更情況。以上幾點說明是我總結(jié)了成功實施工程后系統(tǒng)分析人員的經(jīng)歷，同時也根據(jù)國外的其他系統(tǒng)實施的相關(guān)成功經(jīng)歷，進(jìn)展了總結(jié)。4．需求的類型下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義。軟件需求包括三個不同的層次：業(yè)務(wù)需求、用戶需求和功能需求〔也包括非功能需求〕。1．業(yè)務(wù)需求〔businessrequirement〕反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們在工程視圖與圍文檔中予以說明。2．用戶需求(userrequirement)文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實例〔usecase〕文檔或方案腳本說明中予以說明。3．功能需求(functionalrequirement)定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。在軟件需求規(guī)格說明書〔SRS〕中說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為。軟件需求規(guī)格說明在開發(fā)、測試、質(zhì)量保證、工程管理以及相關(guān)工程功能中都起了重要的作用。對一個大型系統(tǒng)來說，軟件功能需求也許只是系統(tǒng)需求的一個子集，因為另外一些可能屬于子系統(tǒng)〔或軟件部件〕。作為功能需求的補充，軟件需求規(guī)格說明還應(yīng)包括非功能需求，它描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等。它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)和合約；外部界面的具體細(xì)節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點進(jìn)展描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。下面以一個字處理程序為例來說明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤〞，該產(chǎn)品的包裝盒封面上可能會標(biāo)明這是個滿足業(yè)務(wù)需求的拼寫檢查器。而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞〞。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現(xiàn)整個文檔圍的替換。從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計細(xì)節(jié)、實現(xiàn)細(xì)節(jié)、工程方案信息或測試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你終究想開發(fā)什么。工程也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對工程成功也至關(guān)重要，但它們并非本書所要討論的。5．需求分析的原則不重視需求過程的工程隊伍將自食其果。需求工程中的缺陷將給工程成功帶來極大風(fēng)險，這里的“成功〞是指推出的產(chǎn)品能以合理的價格、及時地在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風(fēng)險。不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險:

1.無足夠用戶參與客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費則多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為開發(fā)人員感覺與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在*些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在工程早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。系統(tǒng)人員在實踐過程中，也有些感覺，在實施一家公司的工程時，假設(shè)無足夠的用戶參與，系統(tǒng)人員獲得的需片面的，不完整的，這樣系統(tǒng)在需求之初就埋下風(fēng)險。2.用戶需求的不斷增加在開發(fā)中假設(shè)不斷地補充需求，工程就越變越龐大以致超過其方案及預(yù)算圍。方案并不總是與工程需求規(guī)模與復(fù)雜性、風(fēng)險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。要想把需求變更圍控制到最小，必須一開場就對工程視圖、圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進(jìn)展變更影響因素分析的變更控制過程，有助于所有風(fēng)險承擔(dān)者明白業(yè)務(wù)決策的合理性，即為何進(jìn)展*些變更，相應(yīng)消耗的時間、資源或特性上的折中。產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體構(gòu)造日漸紊亂，補丁代碼也使得整個程序難以理解和維護(hù)。插入補丁代碼使模塊違背強(qiáng)聚、松耦合的設(shè)計原則，特別是如果工程配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為強(qiáng)健的構(gòu)造，并能更好地適應(yīng)它。這樣設(shè)計階段需求變更不會直接導(dǎo)致補丁代碼，同時也有利于減少因變更導(dǎo)致質(zhì)量的下降。3.模棱兩可的需求模棱兩可是需求規(guī)格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋*個需求說明。模棱兩可的需求會使不同的風(fēng)險承擔(dān)者產(chǎn)生不同的期望，它會使開發(fā)人員為錯誤問題而浪費時間，并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我，她所在的測試組經(jīng)常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。處理模棱兩可需求的一種方法是組織好負(fù)責(zé)從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到工程后期才被發(fā)現(xiàn)，那時再發(fā)現(xiàn)的話會使得更正代價很大。4.不必要的特性“畫蛇添足〞是指開發(fā)人員力圖增加一些“用戶欣賞〞但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認(rèn)為這些功能性很有用，以致在其上消耗的努力“白搭〞了。開發(fā)人員應(yīng)當(dāng)為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主。同樣，客戶有時也可能要求一些看上去很“酷〞，但缺乏實用價值的功能，而實現(xiàn)這些功能只能徒耗時間和本錢。為了將“畫蛇添足〞的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈〞，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。5.過于精簡的規(guī)格說明有時，客戶并不明白需求分析有如此重要，于是只作一份簡單之至的規(guī)格說明，僅涉及了產(chǎn)品概念上的容，然后讓開發(fā)人員在工程進(jìn)展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的構(gòu)造之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會給開發(fā)人員帶來挫折〔使他們在不正確的假設(shè)前提和極其有限的指導(dǎo)下工作〕，也會給客戶帶來煩惱〔他們無法得到他們所設(shè)想的產(chǎn)品〕。6.忽略了用戶分類大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)歷水平也不盡一樣。如果你不能在工程早期就針對所有這些主要用戶進(jìn)展分類的話，必然導(dǎo)致有的用戶對產(chǎn)品感到失望。例如，菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。7.不準(zhǔn)確的方案據(jù)統(tǒng)計，導(dǎo)致需求過程中軟件本錢估計極不準(zhǔn)確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。對不準(zhǔn)確的要求所提問題的正確響應(yīng)是“等我真正明白你的需求時，我就會來告訴你〞。基于不充分信息和未經(jīng)深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，最好還是給出一個圍。未經(jīng)準(zhǔn)備的估計通常是作為一種猜測給出的，聽者卻認(rèn)為是一種承諾。因此我們要盡力給出可到達(dá)的目標(biāo)并堅持完成它。6．需求分析人員和用戶的合作關(guān)系優(yōu)秀的軟件產(chǎn)品是建立在優(yōu)秀的需求根底之上的。而高質(zhì)量的需求來源于客戶與開發(fā)人員之間有效的交流與合作。通常，開發(fā)人員與客戶或客戶代理人，如市場人員間的關(guān)系反而會成為一種對立關(guān)系。雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產(chǎn)生摩擦，在這種情況下，不會給雙方帶來一點益處。只有當(dāng)雙方參與者都明白要成功自己需要什么，同時也應(yīng)知道要成功合作方需要什么時，才能建立起一種合作關(guān)系。由于工程壓力與日漸增，所有風(fēng)險承擔(dān)者有著一個共同的目標(biāo)這一點容易被遺忘。其實大家都想開發(fā)出一個既能實現(xiàn)商業(yè)價值，又能滿足用戶需要，還能使開發(fā)者感到滿足的優(yōu)秀軟件產(chǎn)品。軟件客戶需求權(quán)利書列出了十條關(guān)于客戶在工程需求工程實施中與分析人員、開發(fā)人員交流時的合法要求。每一項權(quán)利都對應(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ī)的行業(yè)術(shù)語。2：要求分析人員了解客戶的業(yè)務(wù)及目標(biāo)通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業(yè)務(wù)任務(wù)和怎樣才能使產(chǎn)品更好地滿足你的需要。這將有助于開發(fā)人員設(shè)計出真正滿足你的需要并到達(dá)你期望的優(yōu)秀軟件。為幫助開發(fā)人員和分析人員，可以考慮邀請他們觀察你或你的同事是怎樣工作的。如果新開發(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ā)人員和客戶之間針對要開發(fā)的產(chǎn)品容達(dá)成了協(xié)議。軟件需求規(guī)格說明書可以用一種你認(rèn)為易于翻閱和理解的方式組織編寫。要評審編寫出的規(guī)格說明以確保它們準(zhǔn)確而完整地表達(dá)了你的需求。一份高質(zhì)量的軟件需求規(guī)格說明能有助于開發(fā)人員開發(fā)出真正需要的產(chǎn)品。4：要求得到需求工作結(jié)果的解釋說明分析人員可能采用了多種圖表作為文字性軟件需求規(guī)格說明的補充。因為如工作流程圖那樣的圖表能很清楚地描述出系統(tǒng)行為的*些方面。所以需求說明中的各種圖表有著極高的價值。雖然它們不太難于理解，但是你很可能對此并不熟悉。因此可以要求分析人員解釋說明每圖表的作用或其它的需求開發(fā)工作結(jié)果和符號的意義，及怎樣檢查圖表有無錯誤及不一致等。5：要求開發(fā)人員尊重你的意見如果用戶與開發(fā)人員之間不能相互理解，那關(guān)于需求的討論將會有障礙，共同合作能使大家“兼聽則明〞。參與需求開發(fā)過程的客戶有權(quán)要求開發(fā)人員尊重他們并珍惜他們?yōu)楣こ坛晒λ冻龅臅r間。同樣，客戶也應(yīng)對開發(fā)人員為工程成功這一共同目標(biāo)所作出的努力表示尊重與感謝。6：要求開發(fā)人員對需求及產(chǎn)品實施提供建議，拿出主意通常，客戶所說的“需求〞已是一種實際可能的實施解決方案，分析人員將盡力從這些解決方法中了解真正的業(yè)務(wù)及其需求，同時還應(yīng)找出已有系統(tǒng)不適合當(dāng)前業(yè)務(wù)之處，以確保產(chǎn)品不會無效或低效。在徹底弄清業(yè)務(wù)領(lǐng)域的事情后，分析人員有時就能提出相當(dāng)好的改進(jìn)方法。有經(jīng)歷且富有創(chuàng)造力的分析人員還能提出增加一些用戶并未發(fā)現(xiàn)的很有價值的系統(tǒng)特性。7：描述產(chǎn)品易使用的特性你可以要求分析人員在實現(xiàn)功能需求的同時還要注重軟件的易用性。因為這些易用特性或質(zhì)量屬性能使你更準(zhǔn)確、高效地完成任務(wù)。例如，客戶有時要求產(chǎn)品要“用戶友好〞或“強(qiáng)健〞或“高效率〞，但這對于開發(fā)人員來說，太主觀了并無實用價值。正確的應(yīng)是：分析人員通過詢問和調(diào)查了解客戶所要的友好、強(qiáng)健、高效所包含的具體特性。8：調(diào)整需求，允許重用已有的軟件組件需求通常要有一定的靈活性。分析人員可能發(fā)現(xiàn)已有的*個軟件組件與你描述的需求很相符。在這種情況下，分析人員應(yīng)提供一些修改需求的選擇以便開發(fā)人員能夠在新系統(tǒng)開發(fā)中重用一些已有的軟件。如果有可重用的時機(jī)出現(xiàn)，同時你又能調(diào)整你的需求說明，那就能降低本錢和節(jié)省時間，而不必嚴(yán)格按原有的需求說明開發(fā)。所以說，如果想在產(chǎn)品中使用一些已有的商業(yè)常用組件，而它們并不完全適合你所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。9：獲得滿足客戶功能和質(zhì)量要求的系統(tǒng)每個人都希望工程獲得成功。但這不僅要求你要清晰地告知開發(fā)人員關(guān)于系統(tǒng)“做什么〞所需的所有信息，而且還要求開發(fā)人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設(shè)和潛在的期望。否則，開發(fā)人員開發(fā)出的產(chǎn)品很可能無法讓你滿意。客戶有以下義務(wù)：1：給分析人員講解你的業(yè)務(wù)分析人員要依靠你給他們講解的業(yè)務(wù)概念及術(shù)語。但你不能指望分析人員會成為該領(lǐng)域的專家，而只能讓他們真正明白你的問題和目標(biāo)。不要期望分析人員能把握你們業(yè)務(wù)的細(xì)微與潛在之處，他們很可能并不知道那些對于你和你的同事來說理所當(dāng)然的“常識〞。2：抽出時間清楚地說明并完善需求客戶很忙，經(jīng)常在最忙的時候還得參與需求開發(fā)。但無論如何，你有義務(wù)抽出時間參與“頭腦風(fēng)暴〞會議的討論，承受采訪或其它獲取需求的活動。有時分析人員可能先以為明白了你的觀點，而過后發(fā)現(xiàn)還需要你的講解。這時，請耐心一些對待需求和需求的精化工作過程中的反復(fù)，因為它是人們交流中的很自然的現(xiàn)象，何況這對軟件產(chǎn)品的成功極為重要。3：準(zhǔn)確而詳細(xì)地說明需求編寫一份清晰、準(zhǔn)確的需求文檔是很困難的。由于處理細(xì)節(jié)問題不但煩人而且又耗時，故很容易留下模糊不清的需求。但是，在開發(fā)過程中，必須得解決這種模糊性和不準(zhǔn)確性。而你恰是為解決這些問題作出決定的最正確人選。不然的話，你就只好靠開發(fā)人員去正確猜測了。在需求規(guī)格說明中暫時加上待定〔tobedetermined,TBD也可采用漢語拼音略寫“DQD：待確定〞〕的標(biāo)志是個不錯的方法。用該標(biāo)志可指明了哪些需要進(jìn)一步探討、分析或增加信息的地方。不過，有時也可能因為*個特殊需求難以解決或沒有人愿意處理它而注上TBD標(biāo)志。盡量將每項需求的容都闡述清楚，以便分析人員能準(zhǔn)確的將其寫進(jìn)軟件需求規(guī)格說明中。如果你一時不能準(zhǔn)確表述，那就得允許獲取必要的準(zhǔn)確信息這樣一個過程。通常使用所謂的原型技術(shù)。通過開發(fā)的原型，你可以同開發(fā)人員一起反復(fù)修改，不斷完善需求定義。4：及時地作出決定正如一位建筑師為你修建房屋，分析人員將要求你做出一些選擇和決定。這些決定包括來自多個用戶提出的處理方法或在質(zhì)量特性沖突和信息準(zhǔn)確度中選擇折衷方案等。有權(quán)做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發(fā)人員通常只有等你做出了決定才能行動，而這種等待會延誤工程的進(jìn)展。5：尊重開發(fā)人員的需求可行性及本錢評估所有的軟件功能都有其本錢價格，開發(fā)人員最適合預(yù)算這些本錢〔盡管許多開發(fā)人員并不擅長評估預(yù)測〕。你所希望的*些產(chǎn)品特性可能在技術(shù)上行不通，或者實現(xiàn)它要付出極為高昂的代價。而*些需求試圖在操作環(huán)境中要求不可能到達(dá)的性能或試圖得到一些根本得不到的數(shù)據(jù)，開發(fā)人員會對此作出負(fù)面的評價意見，你應(yīng)該尊重他們的意見。有時，你可以重新給出一個在技術(shù)上可行、實現(xiàn)上廉價的需求，例如，要求*個行為在“瞬間〞發(fā)生是不可行的，但換種更具體的時間需求說法〔“在50ms以〞,但假設(shè)沒有準(zhǔn)確的技術(shù)分析不能輕易下結(jié)論〕，這就可以實現(xiàn)了。6：劃分需求優(yōu)先級別大多數(shù)工程沒有足夠的時間或資源來實現(xiàn)功能性的每個細(xì)節(jié)。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發(fā)的主要局部。只能由你來負(fù)責(zé)設(shè)定需求優(yōu)先級，因為開發(fā)者并不可能按你的觀點決定需求優(yōu)先級。開發(fā)者將為你確定優(yōu)先級提供有關(guān)每個需求的花費和風(fēng)險的信息。當(dāng)你設(shè)定優(yōu)先級時，你幫助開發(fā)者確保在適當(dāng)?shù)臅r間用最小的開支取得最好的效果。在時間和資源限制下，關(guān)于所需特性能否完成或完成多少應(yīng)該尊重開發(fā)人員的意見。盡管沒有人愿意看到自己所希望的需求在工程中未被實現(xiàn)，但畢竟是要面對這種現(xiàn)實的。業(yè)務(wù)決策有時不得不依據(jù)優(yōu)先級來縮小工程圍或延長工期，或增加資源，或在質(zhì)量上尋找折衷。7：評審需求文檔和原型正如我們將在第14章討論的，無論是正式的還是非正式的方式，對需求文檔進(jìn)展評審都會對軟件質(zhì)量提高有所幫助。讓客戶參與評審才能真正鑒別需求文檔是否確實完整、正確說明了期望的必要特性。評審也給客戶代表提供一個時機(jī)，給需求分析人員帶來反響信息以改進(jìn)他們的工作。如果你認(rèn)為編寫的需求文檔不夠準(zhǔn)確，就有義務(wù)盡早告訴分析人員并為改進(jìn)提供建議。通過閱讀需求規(guī)格說明，很難想象實際的軟件是什么樣子的。更好的方法是先為產(chǎn)品開發(fā)一個原型。這樣你就能提供更有價值的反響信息給開發(fā)人員，幫助他們更好地理解你的需求。必須認(rèn)識到：原型并非是一個實際產(chǎn)品，但開發(fā)人員能將其轉(zhuǎn)變、擴(kuò)大成功能齊全的系統(tǒng)。8：需求出現(xiàn)變更要馬上聯(lián)系不斷的需求變更會給在預(yù)定方案完成高質(zhì)量產(chǎn)品帶來嚴(yán)重的負(fù)面影響。變更是不可防止的，但在開發(fā)周期中變更越在晚期出現(xiàn)，其影響越大。變更不僅會導(dǎo)致代價極高的返工，而且工期也會被迫延誤，特別是在大體構(gòu)造已完成后又需要增加新特性時。所以一旦你發(fā)現(xiàn)需要變更需求時，請一定立即通知分析人員。9：應(yīng)遵照開發(fā)組織處理需求變更的過程為了將變更帶來的負(fù)面影響減少到最低限度，所有的參與者必須遵照工程的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進(jìn)展分析、綜合考慮，最后作出適宜的決策以確定將*些變更引入工程中。10：尊重開發(fā)人員采用的需求工程過程軟件開發(fā)中最具挑戰(zhàn)性的莫過于收集需求并確定其正確性。分析人員采用的方法有其合理性。也許你認(rèn)為需求過程不太劃算，但請相信花在需求開發(fā)上的時間是“很有價值〞的。如果你理解并支持分析人員為收集、編寫需求文檔和確保其質(zhì)量所采用的技術(shù)，則整個過程將會更為順利。盡管去詢問分析人員為什么他們要收集*些信息，或參與與需求有關(guān)的活動。系統(tǒng)分析人員在開發(fā)過程中可能會遇到以下問題，一些很忙的客戶可能不愿意積極參與需求過程，而缺少客戶參與將很可能導(dǎo)致不理想的產(chǎn)品。故一定要確保需求開發(fā)中的主要參與者都了解并承受他們的義務(wù)。如果遇到分歧，通過協(xié)商以達(dá)成對各自義務(wù)的相互理解，這樣能減少今后的摩擦。7．需求文檔需求開發(fā)的最終成果是：客戶和開發(fā)小組對將要開發(fā)的產(chǎn)品達(dá)成一致協(xié)議。協(xié)議綜合了業(yè)務(wù)需求、用戶需求和軟件功能需求。就像我們早先所看到的，工程視圖和圍文檔包含了業(yè)務(wù)需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產(chǎn)品的非功能需求文檔，包括質(zhì)量屬性和外部接口需求。只有以構(gòu)造化和可讀性方式編寫這些文檔，并由工程的風(fēng)險承擔(dān)者評審?fù)ㄟ^后，各方面人員才能確信他們所贊同的需可靠的。你可以使用以下三種方法編寫軟件需求規(guī)格說明：用好的構(gòu)造化和自然語言編寫文本型文檔。建立圖形化模型，這些模型可以描繪轉(zhuǎn)換過程、系統(tǒng)狀態(tài)和它們之間的變化、數(shù)據(jù)關(guān)系、邏輯流或?qū)ο箢惡退鼈兊年P(guān)系。編寫形式化規(guī)格說明，這可以通過使用數(shù)學(xué)上準(zhǔn)確的形式化邏輯語言來定義需求。由于形式化規(guī)格說明具有很強(qiáng)的嚴(yán)密性和準(zhǔn)確度，因此，所使用的形式化語言只有極少數(shù)軟件開發(fā)人員才熟悉，更不用說客戶了。雖然構(gòu)造化的自然語言具有許多缺點，但在大多數(shù)軟件工程中，它仍是編寫需求文檔最現(xiàn)實的方法。包含了功能和非功能需求的基于文本的軟件需求規(guī)格說明已經(jīng)為大多數(shù)工程所承受。圖形化分析模型通過提供另一種需求視圖，增強(qiáng)了軟件需求規(guī)格說明。軟件需求規(guī)格說明不僅是系統(tǒng)測試和用戶文檔的根底，也是所有子系列工程規(guī)劃、設(shè)計和編碼的根底。它應(yīng)該盡可能完整地描述系統(tǒng)預(yù)期的外部行為和用戶可視化行為。除了設(shè)計和實現(xiàn)上的限制，軟件需求規(guī)格說明不應(yīng)該包括設(shè)計、構(gòu)造、測試或工程管理的細(xì)節(jié)。許多讀者使用軟件需求規(guī)格說明來到達(dá)不同的目的：客戶和營銷部門依賴它來了解他們所能提供的產(chǎn)品。工程經(jīng)理根據(jù)包含在軟件需求規(guī)格說明中描述的產(chǎn)品來制定規(guī)劃并預(yù)測進(jìn)度安排、工作量和資源。軟件開發(fā)小組依賴它來理解他們將要開發(fā)的產(chǎn)品。測試小組使用軟件需求規(guī)格說明中對產(chǎn)品行為的描述制定測試方案、測試用例和測試過程。軟件維護(hù)和支持人員根據(jù)需求規(guī)格說明了解產(chǎn)品的*局部是做什么的。產(chǎn)品發(fā)布組在需求規(guī)格說明和用戶界面設(shè)計的根底上編寫客戶文檔，如用戶手冊和幫助屏幕等。培訓(xùn)人員根據(jù)需求規(guī)格說明和用戶文檔編寫培訓(xùn)材料。軟件需求規(guī)格說明作為產(chǎn)品需求的最終成果必須具有綜合性：必須包括所有的需求。開發(fā)者和客戶不能作任何假設(shè)。如果任何所期望的功能或非功能需求未寫入軟件需求規(guī)格說明，則它將不能作為協(xié)議的一局部并且不能在產(chǎn)品中出現(xiàn)。我見過有一個工程突然接到測試人員發(fā)出的錯誤災(zāi)難的報告。結(jié)果是他們測試的是老版本的軟件需求規(guī)格說明，而他們覺得錯誤的地方正是產(chǎn)品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟件需求規(guī)格說明中尋找錯誤的系統(tǒng)行為。在編寫軟件需求規(guī)格說明，希望讀者牢記以下的建議：對節(jié)、小節(jié)和單個需求的編排必須一致。在右邊局部留下文本注釋區(qū)。允許不加限制地使用空格。正確使用各種可視化強(qiáng)調(diào)標(biāo)志〔例如，黑體、下劃線、斜體和其它不同字體〕。創(chuàng)立目錄表和索引表有助于讀者尋找所需的信息。對所有圖和表指定和標(biāo)識號，并且可按進(jìn)展查閱。使用字處理程序叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節(jié)號。為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標(biāo)準(zhǔn)，必須唯一確定每個軟件需求。這可以使你在變更請求、修改歷史記錄、穿插引用或需求的可跟蹤矩陣中查閱特定的需求。由于要到達(dá)這一目的，用單一的工程列表是不夠的，因此，我將描述幾個不同的需求標(biāo)識方法，并說明它們的優(yōu)點與缺點。可以選擇最適合你的方法。(1)序列號最簡單的方法是賦予每個需求一個唯一的序列號，例如SRS-13。當(dāng)一個新的需求參加到商業(yè)需求管理工具的數(shù)據(jù)庫之后，這些管理工具就會為其分配一個序列號〔許多這樣的工具也支持層次化編號〕。序列號的前綴代表了需求類型，例如SRS代表“軟件需求說明〞。由于序列號不能重用，所以把需求從數(shù)據(jù)庫中刪除時，并不釋放其所占據(jù)的序列號，而新的需求只能得到下一個可用的序列號。這種簡單的編號方法并不能提供任何相關(guān)需求在邏輯上或?qū)哟紊系膮^(qū)別，而且需求的標(biāo)識不能提供任何有關(guān)每個需求容的信息。(2)層次化編碼這也許是最常用的方法。如果功能需求出現(xiàn)在軟件需求規(guī)格說明中第3.2局部，則它們將具有諸如這樣的標(biāo)識號。標(biāo)識號中的數(shù)字越多則表示該需求越詳細(xì)，屬于較低層次上的需求。即使在一個中型的軟件需求規(guī)格說明中，這些標(biāo)識號也會擴(kuò)展到許多位數(shù)字，并且這些標(biāo)識也不提供任何有關(guān)每個需求目的的信息。如果你要插入一個新的需求，則該需求所在局部其后所有需求的序號將要增加。刪除或移去一個需求，則該需求所在局部其后所有需求的序號將要減少。但其他地方的引用將混亂，對于這種簡單的層次化編號的一種改進(jìn)方法是對需求中主要的局部進(jìn)展層次化編號，然后對于每個局部中的單一功能需求用一個簡短文字代碼加上一個序列號來識別。例如，軟件需求規(guī)格說明可能包含“第局部—編輯功能〞，并將此局部編寫成子模塊文檔，然后配置管理。有時，你覺得缺少特定需求的*些信息。在解決這個不確定性之前，可能必須與客戶商議、檢查與另一個系統(tǒng)的接口或者定義另一個需求。使用“待確定〞〔tobedetermined,TBD或采用漢語拼音略寫DQD〕符號作為標(biāo)準(zhǔn)指示器來強(qiáng)調(diào)軟件需求規(guī)格說明中這些需求的缺陷。通過這種方法，你可以在軟件需求規(guī)格說明中查找所要澄清需求的局部。記錄誰將解決哪個問題、怎樣解決及什么時候解決。把每個TBD編號并創(chuàng)立一個TBD列表，這有助于方便地跟蹤每個工程。在繼續(xù)進(jìn)展構(gòu)造需求集合之前，必須解決所有的TBD問題，因為任何遺留下來的不確定問題將會增加出錯的風(fēng)險和需求返工。當(dāng)開發(fā)人員遇到一個TBD問題或其它模糊之處時，他可能不會返回到原始需求來解決問題。多半開發(fā)者對它進(jìn)展猜測，但并不總是正確的。如果有TBD問題尚未解決，而你又要繼續(xù)進(jìn)展開發(fā)工作，則盡可能推遲實現(xiàn)這些需求，或者解決這些需求的開放式問題，把產(chǎn)品的這局部設(shè)計得易于更改。編寫優(yōu)秀的需求文檔沒有現(xiàn)成固定的方法，最好是根據(jù)經(jīng)歷進(jìn)展。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術(shù)編寫風(fēng)格和使用用戶術(shù)語而不是計算機(jī)專業(yè)術(shù)語的方式得以改進(jìn)。你在編寫優(yōu)秀的需求文檔時，希望讀者還需牢記以下幾點建議：保持語句和段落的簡短。采用主動語態(tài)的表達(dá)方式。編寫具有正確的語法、拼寫和標(biāo)點的完整句子。使用的術(shù)語與詞匯表中所定義的應(yīng)該一致。需求述應(yīng)該具有一致的樣式，例如“系統(tǒng)必須..〞或者“用戶必須..〞，并緊跟一個行為動作和可觀察的結(jié)果。例如，“倉庫管理子系統(tǒng)必須顯示一所請求的倉庫中有存貨的庫存清單。〞為了減少不確定性，必須防止模糊的、主觀的術(shù)語，例如，用戶友好、簡單、有效、、最新技術(shù)、優(yōu)越的、可承受的等。當(dāng)用客說“用戶友好〞或者“快〞時，你應(yīng)該明確它們的真正含義并且在需求中說明用戶的意圖。防止使用比較性的詞匯，定量地說明所需要提高的程度或者說清一些參數(shù)可承受的最大值和最小值。當(dāng)客戶說明系統(tǒng)應(yīng)該“處理〞、“支持〞或“管理〞*些事情時，你應(yīng)該能理解客戶的意圖。由于需求的編寫是層次化的，因此，可以把頂層不明確的需求向低層詳細(xì)分解，直到消除不明確性為止。文檔的編寫人員不應(yīng)該把多個需求集中在一個冗長的表達(dá)段落中。在需求中諸如“和〞，“或〞之類的連詞就說明了該局部集中了多個需求。務(wù)必記住，不要在需求說明中使用“和/或〞，“等等〞之類的連詞。8．需求分析的過程需求獲取是在問題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個必不可少的結(jié)果是對工程中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開發(fā)者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問題之后才能開場設(shè)計系統(tǒng)，否則，對需求定義的任何改進(jìn)，設(shè)計上都必須大量的返工。把需求獲取集中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開發(fā)組由于草率處理設(shè)計問題而造成的失誤。需求獲取、分析、編寫需求規(guī)格說明和驗證并不遵循線性的順序，這些活動是相互隔開、增量和反復(fù)的。當(dāng)你和客戶合作時，你就將會問一些問題，并且取得他們所提供的信息〔需求獲取〕。同時，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯(lián)系。然后，你可以使客戶信息構(gòu)造化，并編寫成文檔和示意圖。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤。這四個過程貫穿著需求開發(fā)的整個階段。由于軟件開發(fā)工程和組織文化的不同，對于需求開發(fā)沒有一個簡單的、公式化的途徑。下面列出了14個步驟，你可以利用它們