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