1．概念
需求的定義包括從用戶角度（系統(tǒng)的外部行為），以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求。
關(guān)鍵的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個項目中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起。系統(tǒng)的分析人員說：“我們想與你談?wù)勀愕男枨??！笨蛻舻牡谝环磻?yīng)便是：“我已經(jīng)將我的要求都告訴你們前任了，現(xiàn)在我要的就是給我編一個系統(tǒng)”。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。
需求的另外一種定義認為需求是“用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明”。有些需求分析專家拓展了這個概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點、功能及屬性等”。這些定義強調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計、構(gòu)造的。而下面的定義則從用戶需要進一步轉(zhuǎn)移到了系統(tǒng)特性：
需求是指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_發(fā)過程中對系統(tǒng)的約束。
從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進一步和客戶核對。系統(tǒng)分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務(wù)必達成共識。
任何文檔形式的需求（例如如下將要描述的需求規(guī)格說明書）僅是一個模型，一種描述。
2．需求分析的任務(wù)
開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細技術(shù)需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進行修改也極為困難。
目前，國內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個系統(tǒng)并立運行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。
對于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認可的需求文檔，我們?nèi)绾沃理椖坑诤螘r結(jié)束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？
然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內(nèi)的軟件開發(fā)者身上發(fā)生。
近來，我遇到一個開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計算機輔助軟件。不幸的是，當他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結(jié)果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構(gòu)思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。
相反的情況，我曾見一個要集成到“錯誤跟蹤系統(tǒng)”中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。他們依據(jù)需求對系統(tǒng)進行測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。
事實上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。
3．需求分析過程
可把整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適
需求開發(fā)可進一步分為：問題獲取、分析、編寫規(guī)格說明和驗證四個階段。這些子項包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。需求開發(fā)活動包括以下幾個方面：
確定產(chǎn)品所期望的用戶類別。
獲取每個用戶類的需求。
了解實際用戶任務(wù)和目標以及這些任務(wù)所支持的業(yè)務(wù)需求。
分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。
將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。
了解相關(guān)質(zhì)量屬性的重要性。
商討實施優(yōu)先級的劃分。
將所收集的用戶需求編寫成文檔和模型。
評審需求規(guī)格說明，確保對用戶需求達到共同的理解與認識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。
需求管理需要“建立并維護在軟件工程中同客戶達成的合同” 。這種合同都包含在編寫的需求文檔與模型中?？蛻舻慕邮軆H是需求成功的一半，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中。通常的需求管理活動包括：
定義需求基線（迅速制定需求文檔的主體）。
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。
以一種可控制的方式將需求變更融入到項目中。
使當前的項目計劃與需求一致。
估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾，這種承諾具體體現(xiàn)在項目解決方案上。
讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。
在整個項目過程中跟蹤需求狀態(tài)及其變更情況。
以上幾點說明是我總結(jié)了成功實施項目后系統(tǒng)分析人員的經(jīng)驗，同時也根據(jù)國內(nèi)外的其他系統(tǒng)實施的相關(guān)成功經(jīng)驗，進行了總結(jié)。
4．需求的類型
下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義。
軟件需求包括三個不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。
1．業(yè)務(wù)需求（business requirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。
2．用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實例（use case）文檔或方案腳本說明中予以說明。
3．功能需求(functional requirement)定義了開發(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)品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點進行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。
下面以一個字處理程序為例來說明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產(chǎn)品的包裝盒封面上可能會標明這是個滿足業(yè)務(wù)需求的拼寫檢查器。而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。
從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計細節(jié)、實現(xiàn)細節(jié)、項目計劃信息或測試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你究竟想開發(fā)什么。項目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對項目成功也至關(guān)重要，但它們并非本書所要討論的。
5．需求分析的原則
不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這里的“成功”是指推出的產(chǎn)品能以合理的價格、及時地在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風險。
不適當?shù)男枨筮^程所引起的一些風險:
1. 無足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為開發(fā)人員感覺與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。
系統(tǒng)人員在實踐過程中，也有些感覺，在實施一家公司的項目時，若無足夠的用戶參與，系統(tǒng)人員獲得的需求是片面的，不完整的，這樣系統(tǒng)在需求之初就埋下風險。
2. 用戶需求的不斷增加
在開發(fā)中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預(yù)算范圍。計劃并不總是與項目需求規(guī)模與復(fù)雜性、風險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。
要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業(yè)務(wù)決策的合理性，即為何進行某些變更，相應(yīng)消耗的時間、資源或特性上的折中。
產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體結(jié)構(gòu)日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內(nèi)聚、松耦合的設(shè)計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計階段需求變更不會直接導(dǎo)致補丁代碼，同時也有利于減少因變更導(dǎo)致質(zhì)量的下降。
3. 模棱兩可的需求
模棱兩可是需求規(guī)格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。
模棱兩可的需求會使不同的風險承擔者產(chǎn)生不同的期望，它會使開發(fā)人員為錯誤問題而浪費時間，并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我，她所在的測試組經(jīng)常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發(fā)現(xiàn)，那時再發(fā)現(xiàn)的話會使得更正代價很大。
4. 不必要的特性
“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發(fā)人員應(yīng)當為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限內(nèi)的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。
同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現(xiàn)這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。
5. 過于精簡的規(guī)格說明
有時，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規(guī)格說明，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項目進展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會給開發(fā)人員帶來挫折（使他們在不正確的假設(shè)前提和極其有限的指導(dǎo)下工作），也會給客戶帶來煩惱（他們無法得到他們所設(shè)想的產(chǎn)品）。
6. 忽略了用戶分類
大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要用戶進行分類的話，必然導(dǎo)致有的用戶對產(chǎn)品感到失望。例如，菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。
7. 不準確的計劃
據(jù)統(tǒng)計，導(dǎo)致需求過程中軟件成本估計極不準確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。
對不準確的要求所提問題的正確響應(yīng)是“等我真正明白你的需求時，我就會來告訴你”?；诓怀浞中畔⒑臀唇?jīng)深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，還是給出一個范圍。未經(jīng)準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。因此我們要盡力給出可達到的目標并堅持完成它。
需求的定義包括從用戶角度（系統(tǒng)的外部行為），以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求。
關(guān)鍵的問題是一定要編寫需求文檔。我曾經(jīng)目睹過一個項目中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起。系統(tǒng)的分析人員說：“我們想與你談?wù)勀愕男枨??！笨蛻舻牡谝环磻?yīng)便是：“我已經(jīng)將我的要求都告訴你們前任了，現(xiàn)在我要的就是給我編一個系統(tǒng)”。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。
需求的另外一種定義認為需求是“用戶所需要的并能觸發(fā)一個程序或系統(tǒng)開發(fā)工作的說明”。有些需求分析專家拓展了這個概念：“從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點、功能及屬性等”。這些定義強調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計、構(gòu)造的。而下面的定義則從用戶需要進一步轉(zhuǎn)移到了系統(tǒng)特性：
需求是指明必須實現(xiàn)什么的規(guī)格說明。它描述了系統(tǒng)的行為、特性或?qū)傩裕窃陂_發(fā)過程中對系統(tǒng)的約束。
從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個清晰、毫無二義性的“需求”術(shù)語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進一步和客戶核對。系統(tǒng)分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務(wù)必達成共識。
任何文檔形式的需求（例如如下將要描述的需求規(guī)格說明書）僅是一個模型，一種描述。
2．需求分析的任務(wù)
開發(fā)軟件系統(tǒng)最為困難的部分就是準確說明開發(fā)什么。最為困難的概念性工作便是編寫出詳細技術(shù)需求，這包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口。同時這也是一旦做錯，將最終會給系統(tǒng)帶來極大損害的部分，并且以后再對它進行修改也極為困難。
目前，國內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個系統(tǒng)并立運行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題。
對于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個大系統(tǒng)的一部分的產(chǎn)品是顯而易見的。但是對于我們開發(fā)人員來說，并沒有編寫出客戶認可的需求文檔，我們?nèi)绾沃理椖坑诤螘r結(jié)束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？
然而，即便并非出于商業(yè)目的的軟件需求也是必須的。例如庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內(nèi)的軟件開發(fā)者身上發(fā)生。
近來，我遇到一個開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計算機輔助軟件。不幸的是，當他們開發(fā)完這個工具后，發(fā)現(xiàn)這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結(jié)果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構(gòu)思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。
相反的情況，我曾見一個要集成到“錯誤跟蹤系統(tǒng)”中的簡單界面寫了一頁需求說明。而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時發(fā)現(xiàn)簡單的一張需求清單竟是如此有用。他們依據(jù)需求對系統(tǒng)進行測試時，此系統(tǒng)不僅非常清晰地實現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯誤。
事實上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用。
3．需求分析過程
可把整個軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適
需求開發(fā)可進一步分為：問題獲取、分析、編寫規(guī)格說明和驗證四個階段。這些子項包括軟件類產(chǎn)品中需求收集、評價、編寫文檔等所有活動。需求開發(fā)活動包括以下幾個方面：
確定產(chǎn)品所期望的用戶類別。
獲取每個用戶類的需求。
了解實際用戶任務(wù)和目標以及這些任務(wù)所支持的業(yè)務(wù)需求。
分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息。
將系統(tǒng)級的需求分為幾個子系統(tǒng)，并將需求中的一部份分配給軟件組件。
了解相關(guān)質(zhì)量屬性的重要性。
商討實施優(yōu)先級的劃分。
將所收集的用戶需求編寫成文檔和模型。
評審需求規(guī)格說明，確保對用戶需求達到共同的理解與認識，并在整個開發(fā)小組接受說明之前將問題都弄清楚。
需求管理需要“建立并維護在軟件工程中同客戶達成的合同” 。這種合同都包含在編寫的需求文檔與模型中?？蛻舻慕邮軆H是需求成功的一半，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中。通常的需求管理活動包括：
定義需求基線（迅速制定需求文檔的主體）。
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它。
以一種可控制的方式將需求變更融入到項目中。
使當前的項目計劃與需求一致。
估計變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾，這種承諾具體體現(xiàn)在項目解決方案上。
讓每項需求都能與其對應(yīng)的設(shè)計、源代碼和測試用例聯(lián)系起來以實現(xiàn)跟蹤。
在整個項目過程中跟蹤需求狀態(tài)及其變更情況。
以上幾點說明是我總結(jié)了成功實施項目后系統(tǒng)分析人員的經(jīng)驗，同時也根據(jù)國內(nèi)外的其他系統(tǒng)實施的相關(guān)成功經(jīng)驗，進行了總結(jié)。
4．需求的類型
下面這些定義是需求工程領(lǐng)域中常見術(shù)語的定義。
軟件需求包括三個不同的層次：業(yè)務(wù)需求、用戶需求和功能需求（也包括非功能需求）。
1．業(yè)務(wù)需求（business requirement）反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。
2．用戶需求(user requirement) 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實例（use case）文檔或方案腳本說明中予以說明。
3．功能需求(functional requirement)定義了開發(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)品必須遵從的標準、規(guī)范和合約；外部界面的具體細節(jié)；性能要求；設(shè)計或?qū)崿F(xiàn)的約束條件及質(zhì)量屬性。所謂約束是指對開發(fā)人員在軟件產(chǎn)品設(shè)計和構(gòu)造上的限制。質(zhì)量屬性是通過多種角度對產(chǎn)品的特點進行描述，從而反映產(chǎn)品功能。多角度描述產(chǎn)品對用戶和開發(fā)人員都極為重要。
下面以一個字處理程序為例來說明需求的不同種類。業(yè)務(wù)需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產(chǎn)品的包裝盒封面上可能會標明這是個滿足業(yè)務(wù)需求的拼寫檢查器。而對應(yīng)的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現(xiàn)整個文檔范圍的替換。
從以上定義可以發(fā)現(xiàn)，需求并未包括設(shè)計細節(jié)、實現(xiàn)細節(jié)、項目計劃信息或測試信息。需求與這些沒有關(guān)系，它關(guān)注的是充分說明你究竟想開發(fā)什么。項目也有其它方面的需求，如開發(fā)環(huán)境需求或發(fā)布產(chǎn)品及移植到支撐環(huán)境的需求。盡管這些需求對項目成功也至關(guān)重要，但它們并非本書所要討論的。
5．需求分析的原則
不重視需求過程的項目隊伍將自食其果。需求工程中的缺陷將給項目成功帶來極大風險，這里的“成功”是指推出的產(chǎn)品能以合理的價格、及時地在功能、質(zhì)量上完全滿足用戶的期望。下面將討論一些需求風險。
不適當?shù)男枨筮^程所引起的一些風險:
1. 無足夠用戶參與
客戶經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需花費那么多功夫，開發(fā)人員可能也不重視用戶的參與。究其原因：一是因為開發(fā)人員感覺與用戶合作不如編寫代碼有意思；二是因為開發(fā)人員覺得已經(jīng)明白用戶的需求了。在某些情況下，與實際使用產(chǎn)品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應(yīng)讓具有代表性的用戶在項目早期直接參與到開發(fā)隊伍中，并一同經(jīng)歷整個開發(fā)過程。
系統(tǒng)人員在實踐過程中，也有些感覺，在實施一家公司的項目時，若無足夠的用戶參與，系統(tǒng)人員獲得的需求是片面的，不完整的，這樣系統(tǒng)在需求之初就埋下風險。
2. 用戶需求的不斷增加
在開發(fā)中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預(yù)算范圍。計劃并不總是與項目需求規(guī)模與復(fù)雜性、風險、開發(fā)生產(chǎn)率及需求變更實際情況相一致，這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發(fā)者對新需求所作的修改。
要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照框架。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業(yè)務(wù)決策的合理性，即為何進行某些變更，相應(yīng)消耗的時間、資源或特性上的折中。
產(chǎn)品開發(fā)中不斷延續(xù)的變更會使其整體結(jié)構(gòu)日漸紊亂，補丁代碼也使得整個程序難以理解和維護。插入補丁代碼使模塊違背強內(nèi)聚、松耦合的設(shè)計原則，特別是如果項目配置管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區(qū)別這些可能帶來變更的特性，你就能開發(fā)一個更為健壯的結(jié)構(gòu)，并能更好地適應(yīng)它。這樣設(shè)計階段需求變更不會直接導(dǎo)致補丁代碼，同時也有利于減少因變更導(dǎo)致質(zhì)量的下降。
3. 模棱兩可的需求
模棱兩可是需求規(guī)格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明產(chǎn)生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。
模棱兩可的需求會使不同的風險承擔者產(chǎn)生不同的期望，它會使開發(fā)人員為錯誤問題而浪費時間，并且使測試者與開發(fā)者所期望的不一致。一位系統(tǒng)測試人員曾告訴我，她所在的測試組經(jīng)常對需求理解有誤，以致不得不重寫許多測試用例并重做許多測試。
處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發(fā)現(xiàn)，那時再發(fā)現(xiàn)的話會使得更正代價很大。
4. 不必要的特性
“畫蛇添足”是指開發(fā)人員力圖增加一些“用戶欣賞”但需求規(guī)格說明中并未涉及的新功能。經(jīng)常發(fā)生的情況是用戶并不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發(fā)人員應(yīng)當為客戶構(gòu)思方案并為他們提供一些具有創(chuàng)新意識的思路，具體提供哪些功能要在客戶所需與開發(fā)人員在允許時限內(nèi)的技術(shù)可行性之間求得平衡，開發(fā)人員應(yīng)努力使功能簡單易用，而不要未經(jīng)客戶同意，擅自脫離客戶要求，自作主張。
同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現(xiàn)這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應(yīng)確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業(yè)務(wù)任務(wù)的核心功能。
5. 過于精簡的規(guī)格說明
有時，客戶并不明白需求分析有如此重要，于是只作一份簡略之至的規(guī)格說明，僅涉及了產(chǎn)品概念上的內(nèi)容，然后讓開發(fā)人員在項目進展中去完善，結(jié)果很可能出現(xiàn)的是開發(fā)人員先建立產(chǎn)品的結(jié)構(gòu)之后再完成需求說明。這種方法可能適合于尖端研究性的產(chǎn)品或需求本身就十分靈活的情況。但在大多數(shù)情況下，這會給開發(fā)人員帶來挫折（使他們在不正確的假設(shè)前提和極其有限的指導(dǎo)下工作），也會給客戶帶來煩惱（他們無法得到他們所設(shè)想的產(chǎn)品）。
6. 忽略了用戶分類
大多數(shù)產(chǎn)品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經(jīng)驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要用戶進行分類的話，必然導(dǎo)致有的用戶對產(chǎn)品感到失望。例如，菜單驅(qū)動操作對高級用戶太低效了，但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難。
7. 不準確的計劃
據(jù)統(tǒng)計，導(dǎo)致需求過程中軟件成本估計極不準確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與用戶交流不夠、質(zhì)量低下的需求規(guī)格說明和不完善的需求分析。
對不準確的要求所提問題的正確響應(yīng)是“等我真正明白你的需求時，我就會來告訴你”?；诓怀浞中畔⒑臀唇?jīng)深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，還是給出一個范圍。未經(jīng)準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。因此我們要盡力給出可達到的目標并堅持完成它。