需求分析－如何進行軟體需求分析

1．概念

需求的定義包括從使用者角度（系統的外部行為），以及從開發者角度（一些内部特性）來闡述需求。

關 鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說：“我們想與你談談你 的需求。”客戶的第一反應便是：“我已經将我的要求都告訴你們前任了，現在我要的就是給我編一個系統”。而實際上，需求并未編寫成文檔，是以新的分析人員 不得不從頭做起。是以如果隻有一堆郵件、會談記錄或一些零碎的未整理的對話，你就确信你已明白使用者的需求，那完全是自欺欺人。

需求的另外 一種定義認為需求是“使用者所需要的并能觸發一個程式或系統開發工作的說明 ”。有些需求分析專家拓展了這個概念：“從系統外部能發現系統所具有的滿足于使用者 的特點、功能及屬性等 ”。這些定義強調的是産品是什麼樣的，而并非産品是怎樣設計、構造的。而下面的定義則從使用者需要進一步轉移到了系統特性：

需求是指明必須實作什麼的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的限制。

從 上面這些不同形式的定義不難發現：并沒有一個清晰、毫無二義性的“需求”術語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情 況下，使用者并不能描述自己的需要，隻就需要系統分析人員根據使用者的自己語言的描述整理出相關的需要再進一步和客戶核對。系統分析員和客戶需要確定所有項目 風險承擔者在描述需求的那些名詞的了解上務必達成共識。

任何文檔形式的需求（例如如下将要描述的需求規格說明書）僅是一個模型，一種描述。

2．需求分析的任務

開發軟體系統最為困難的部分就是準确說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的接口。同時這也是一旦做錯，将最終會給系統帶來極大損害的部分，并且以後再對它進行修改也極為困難。

目前，國内産品的龐雜，一家企業可能有幾個系統并立運作，它們之間接口是系統開發人員最頭痛的問題。

對于商業最終使用者應用程式，企業資訊系統和軟體作為一個大系統的一部分的産品是顯而易見的。但是對于我們開發人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束？而如果我們不知道什麼對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？

然 而，即便并非出于商業目的的軟體需求也是必須的。例如庫、元件和工具這些供開發小組内部使用的軟體。當然你可能偶爾勿需文檔說明就能與其他人意見較為一 緻，但更常見的是出現重複返工這種不可避免的後果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國内的軟體開發者身上發生。

近 來，我遇到一個開發小組開發包括代碼編輯器在内的一套内部使用的計算機輔助軟體。不幸的是，當他們開發完這個工具後，發現這個工具不能列印出源代碼檔案， 使用者當然希望有這個功能。結果這個小組隻好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明确無誤并構思準确，如果我們沒有編寫文檔，軟體達不到期望 目标也隻能是咎由自取了。

相反的情況，我曾見一個要內建到“錯誤跟蹤系統”中的簡單界面寫了一頁需求說明。而作業系統系統管理者在為處理腳本時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實作了所有必需功能，而且未發現任何錯誤。

事實上，需求文檔在開發過程中一直起指導作用。

3．需求分析過程

可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合适，如圖4-1所示：

圖4-1 需求工程域的層次分解示意圖

需求開發可進一步分為：問題擷取、分析、編寫規格說明和驗證四個階段。這些子項包括軟體類産品中需求收集、評價、編寫文檔等所有活動。需求開發活動包括以下幾個方面：

确定産品所期望的使用者類别。

擷取每個使用者類的需求。

了解實際使用者任務和目标以及這些任務所支援的業務需求。

分析源于使用者的資訊以差別使用者任務需求、功能需求、業務規則、品質屬性、建議解決方法和附加資訊。

将系統級的需求分為幾個子系統，并将需求中的一部份配置設定給軟體元件。

了解相關品質屬性的重要性。

商讨實施優先級的劃分。

将所收集的使用者需求編寫成文檔和模型。

評審需求規格說明，確定對使用者需求達到共同的了解與認識，并在整個開發小組接受說明之前将問題都弄清楚。

需求管理需要“建立并維護在軟體工程中同客戶達成的合同” 。這種合同都包含在編寫的需求文檔與模型中。客戶的接受僅是需求成功的一半，開發人員也必須能夠接受他們，并真正把需求應用到産品中。通常的需求管理活動包括：

定義需求基線（迅速制定需求文檔的主體）。

評審提出的需求變更、評估每項變更的可能影響進而決定是否實施它。

以一種可控制的方式将需求變更融入到項目中。

使目前的項目計劃與需求一緻。

估計變更需求所産生影響并在此基礎上協商新的承諾，這種承諾具體展現在項目解決方案上。

讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實作跟蹤。

在整個項目過程中跟蹤需求狀态及其變更情況。

以上幾點說明是我總結了成功實施項目後系統分析人員的經驗，同時也根據國内外的其他系統實施的相關成功經驗，進行了總結。

4．需求的類型

下面這些定義是需求工程領域中常見術語的定義。

軟體需求包括三個不同的層次：業務需求、使用者需求和功能需求（也包括非功能需求）。

1．業務需求（business requirement）反映了組織機構或客戶對系統、産品高層次的目标要求，它們在項目視圖與範圍文檔中予以說明。

2．使用者需求(user requirement) 文檔描述了使用者使用産品必須要完成的任務，這在使用執行個體（use case）文檔或方案腳本說明中予以說明。

3．功能需求(functional requirement)定義了開發人員必須實作的軟體功能，使得使用者能完成他們的任務，進而滿足了業務需求。

在 軟體需求規格說明書 （SRS）中說明的功能需求充分描述了軟體系統所應具有的外部行為。軟體需求規格說明在開發、測試、品質保證、項目管理以及相關項目功能中都起了重要的作 用。對一個大型系統來說，軟體功能需求也許隻是系統需求的一個子集，因為另外一些可能屬于子系統（或軟體部件）。

作為功能需求的補充，軟 件需求規格說明還應包括非功能需求，它描述了系統展現給使用者的行為和執行的操作等。它包括産品必須遵從的标準、規範和合約；外部界面的具體細節；性能要 求；設計或實作的限制條件及品質屬性。所謂限制是指對開發人員在軟體産品設計和構造上的限制。品質屬性是通過多種角度對産品的特點進行描述，進而反映産品 功能。多角度描述産品對使用者和開發人員都極為重要。

下面以一個字處理程式為例來說明需求的不同種類。業務需求可能是：“使用者能有效地糾正 文檔中的拼寫錯誤”，該産品的包裝盒封面上可能會标明這是個滿足業務需求的拼寫檢查器。而對應的使用者需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替 換項清單來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實作整個文檔範圍的替 換。

從以上定義可以發現，需求并未包括設計細節、實作細節、項目計劃資訊或測試資訊。需求與這些沒有關系，它關注的是充分說明你究竟想開發什麼。 項目也有其它方面的需求，如開發環境需求或釋出産品及移植到支撐環境的需求。盡管這些需求對項目成功也至關重要，但它們并非本書所要讨論的。

5．需求分析的原則

不重視需求過程的項目隊伍将自食其果。需求工程中的缺陷将給項目成功帶來極大風險，這裡的“成功”是指推出的産品能以合理的價格、及時地在功能、品質上完全滿足使用者的期望。下面将讨論一些需求風險。

不适當的需求過程所引起的一些風險:

1. 無足夠使用者參與

客 戶經常不明白為什麼收集需求和確定需求品質需花費那麼多功夫，開發人員可能也不重視使用者的參與。究其原因：一是因為開發人員感覺與使用者合作不如編寫代碼有 意思；二是因為開發人員覺得已經明白使用者的需求了。在某些情況下，與實際使用産品的使用者直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有 代表性的使用者在項目早期直接參與到開發隊伍中，并一同經曆整個開發過程。

系統人員在實踐過程中，也有些感覺，在實施一家公司的項目時，若無足夠的使用者參與，系統人員獲得的需求是片面的，不完整的，這樣系統在需求之初就埋下風險。

2. 使用者需求的不斷增加

在開發中若不斷地補充需求，項目就越變越龐大以緻超過其計劃及預算範圍。計劃并不總是與項目需求規模與複雜性、風險、開發生産率及需求變更實際情況相一緻，這使得問題更難解決。實際上，問題根源在于使用者需求的改變和開發者對新需求所作的修改。

要 想把需求變更範圍控制到最小，必須一開始就對項目視圖、範圍、目标、限制限制和成功标準給予明确說明，并将此說明作為評價需求變更和新特性的參照架構。說 明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助于所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性 上的折中。

産品開發中不斷延續的變更會使其整體結構日漸紊亂，更新檔代碼也使得整個程式難以了解和維護。插入更新檔代碼使子產品違背強内聚、松耦合的設 計原則，特别是如果項目配置管理工作不完善的話，收回變更和删除特性會帶來問題。如果你盡早地差別這些可能帶來變更的特性，你就能開發一個更為健壯的結 構，并能更好地适應它。這樣設計階段需求變更不會直接導緻更新檔代碼，同時也有利于減少因變更導緻品質的下降。

3. 模棱兩可的需求

模棱兩可是需求規格說明中最為可怕的問題。它的一層含義是指諸多讀者對需求說明産生了不同的了解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。

模棱兩可的需求會使不同的風險承擔者産生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一緻。一位系統測試人員曾告訴我，她所在的測試組經常對需求了解有誤，以緻不得不重寫許多測試用例并重做許多測試。

處 理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單浏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需 求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目後期才被發現，那時再發現的話會使得更正代價很大。

4. 不必要的特性

“畫 蛇添足”是指開發人員力圖增加一些“使用者欣賞”但需求規格說明中并未涉及的新功能。經常發生的情況是使用者并不認為這些功能性很有用，以緻在其上耗費的努力 “白搭”了。開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限内的技術可行性之間求得 平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。

同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實 用價值的功能，而實作這些功能隻能徒耗時間和成本。為了将“畫蛇添足”的危害盡量減小，應确信：你明白為什麼要包括這些功能，以及這些功能的“來龍去 脈”，這樣使得需求分析過程始終是注重那些能使使用者完成他們業務任務的核心功能。

5. 過于精簡的規格說明

有時，客戶并不明白需求分析有如此重要，于是隻作 一份簡略之至的規格說明，僅涉及了産品概念上的内容，然後讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立産品的結構之後再完成需求說 明。這種方法可能适合于尖端研究性的産品或需求本身就十分靈活的情況。但在大多數情況下，這會給開發人員帶來挫折（使他們在不正确的假設前提和極其有限的 指導下工作），也會給客戶帶來煩惱（他們無法得到他們所設想的産品）。

6. 忽略了使用者分類

大多數産品是由不同的人使用 其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經驗水準也不盡相同。如果你不能在項目早期就針對所有這些主要使用者進行分類的話，必然導緻有的 使用者對産品感到失望。例如，菜單驅動操作對進階使用者太低效了，但含義不清的指令和快捷鍵又會使不熟練的使用者感到困難。

7. 不準确的計劃

據統計，導緻需求過程中軟體成本估計極不準确的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與使用者交流不夠、品質低下的需求規格說明和不完善的需求分析。

對 不準确的要求所提問題的正确響應是“等我真正明白你的需求時，我就會來告訴你”。基于不充分資訊和未經深思的對需求不成熟的估計很容易為一些因素左右。要 作出估計時，最好還是給出一個範圍。未經準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。是以我們要盡力給出可達到的目标并堅持完成它。

6．需求分析人員和使用者的合作關系

優 秀的軟體産品是建立在優秀的需求基礎之上的。而高品質的需求來源于客戶與開發人員之間有效的交流與合作。通常，開發人員與客戶或客戶代理人，如市場人員間 的關系反而會成為一種對立關系。雙方的管理者都隻想自己的利益而擱置使用者提供的需求進而産生摩擦，在這種情況下，不會給雙方帶來一點益處。

隻 有當雙方參與者都明白要成功自己需要什麼，同時也應知道要成功合作方需要什麼時，才能建立起一種合作關系。由于項目壓力與日漸增，所有風險承擔者有着一個 共同的目标這一點容易被遺忘。其實大家都想開發出一個既能實作商業價值，又能滿足使用者需要，還能使開發者感到滿足的優秀軟體産品。

軟體客戶需求權利書列出了十條關于客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求。每一項權利都對應着軟體開發人員、分析人員的義務。而軟體客戶需求義務書也列出了十條關于客戶在需求過程中應承擔的義務。如果願意，可以将其作為開發人員的權利書。

客戶有如下權利：

1：要求分析人員使用符合客戶語言習慣的表達

需求讨論應集中于業務需要和任務，故要使用業務術語，你應将其教給分析人員，而你 不一定要懂得計算機的行業術語。

2：要求分析人員了解客戶的業務及目标

通 過與使用者交流來擷取使用者需求、分析人員才能更好地了解你的業務任務和怎樣才能使産品更好地滿足你的需要。這将有助于開發人員設計出真正滿足你的需要并達到 你期望的優秀軟體。為幫助開發人員和分析人員，可以考慮邀請他們觀察你或你的同僚是怎樣工作的。如果新開發系統是用來替代已有的系統，那麼開發人員應使用 一下目前的系統，這将有利于他們明白目前系統是怎樣工作的，其工作流程的情況，以及可供改進之處。

3：要求分析人員編寫軟體需求規格說明

分 析人員要把從你和其他客戶那裡獲得的所有資訊進行整理，以區分開業務需求及規範、功能需求、品質目标、解決方法和其它資訊。通過這些分析就能得到一份軟體 需求規格說明。而這份軟體需求規格說明便在開發人員和客戶之間針對要開發的産品内容達成了協定。軟體需求規格說明書可以用一種你認為易于翻閱和了解的方式 組織編寫。要評審編寫出的規格說明以確定它們準确而完整地表達了你的需求。一份高品質的軟體需求規格說明能有助于開發人員開發出真正需要的産品。

4：要求得到需求工作結果的解釋說明

分 析人員可能采用了多種圖表作為文字性軟體需求規格說明的補充。因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面。是以需求說明中的各種圖表 有着極高的價值。雖然它們不太難于了解，但是你很可能對此并不熟悉。是以可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符号的意義， 及怎樣檢查圖表有無錯誤及不一緻等。

5：要求開發人員尊重你的意見

如果使用者與開發人員之間不能互相了解，那關于需求的讨論将會有障礙，共同合作能使大家“兼聽則明”。參與需求開發過程的客戶有權要求開發人員尊重他們并珍惜他們為項目成功所付出的時間。同樣，客戶也應對開發人員為項目成功這一共同目标所作出的努力表示尊重與感激。

6：要求開發人員對需求及産品實施提供建議，拿出主意

通 常，客戶所說的“需求”已是一種實際可能的實施解決方案，分析人員将盡力從這些解決方法中了解真正的業務及其需求，同時還應找出已有系統不适合目前業務之 處，以確定産品不會無效或低效。在徹底弄清業務領域内的事情後，分析人員有時就能提出相當好的改進方法。有經驗且富有創造力的分析人員還能提出增加一些用 戶并未發現的很有價值的系統特性。

7：描述産品易使用的特性

你可以要求分析人員在實作功能需求的同時還要注重軟體的易用 性。因為這些易用特性或品質屬性能使你更準确、高效地完成任務。例如，客戶有時要求産品要“使用者友好”或“健壯”或“高效率”，但這對于開發人員來說，太 主觀了并無實用價值。正确的應是：分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性。

8：調整需求，允許重用已有的軟體元件

需 求通常要有一定的靈活性。分析人員可能發現已有的某個軟體元件與你描述的需求很相符。在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠在 新系統開發中重用一些已有的軟體。如果有可重用的機會出現，同時你又能調整你的需求說明，那就能降低成本和節省時間，而不必嚴格按原有的需求說明開發。所 以說，如果想在産品中使用一些已有的商業常用元件，而它們并不完全适合你所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。

9：獲得滿足客戶功能和品質要求的系統

每個人都希望項目獲得成功。但這不僅要求你要清晰地告知開發人員關于系統“做什麼”所需的所有資訊，而且還要求開發人員能通過交流了解清楚取舍與限制。一定要明确說明你的假設和潛在的期望。否則，開發人員開發出的産品很可能無法讓你滿意。

客戶有下列義務：

1：給分析人員講解你的業務

分析人員要依靠你給他們講解的業務概念及術語。但你不能指望分析人員會成為該領域的專家，而隻能讓他們真正明白你的問題和目标。不要期望分析人員能把握你們業務的細微與潛在之處，他們很可能并不知道那些對于你和你的同僚來說理所當然的“常識”。

2：抽出時間清楚地說明并完善需求

客 戶很忙，經常在最忙的時候還得參與需求開發。但無論如何，你有義務抽出時間參與“頭腦風暴”會議的讨論，接受采訪或其它擷取需求的活動。有時分析人員可能 先以為明白了你的觀點，而過後發現還需要你的講解。這時，請耐心一些對待需求和需求的精化工作過程中的反複，因為它是人們交流中的很自然的現象，何況這對 軟體産品的成功極為重要。

3：準确而詳細地說明需求

編寫一份清晰、準确的需求文檔是很困難的。由于處理細節問題不但煩人 而且又耗時，故很容易留下模糊不清的需求。但是，在開發過程中，必須得解決這種模糊性和不準确性。而你恰是為解決這些問題作出決定的最佳人選。不然的話， 你就隻好靠開發人員去正确猜測了。在需求規格說明中暫時加上待定（to be determined, TBD也可采用漢語拼音略寫“DQD：待确定”）的标志是個不錯的辦法。用該标志可指明了哪些需要進一步探讨、分析或增加資訊的地方。不過，有時也可能因 為某個特殊需求難以解決或沒有人願意處理它而注上TBD标志。盡量将每項需求的内容都闡述清楚，以便分析人員能準确的将其寫進軟體需求規格說明中。如果你 一時不能準确表述，那就得允許擷取必要的準确資訊這樣一個過程。通常使用所謂的原型技術。通過開發的原型，你可以同開發人員一起反複修改，不斷完善需求定 義。

4：及時地作出決定

正如一位建築師為你修建房屋，分析人員将要求你做出一些選擇和決定。這些決定包括來自多個使用者提 出的處理方法或在品質特性沖突和資訊準确度中選擇折衷方案等。有權做出決定的客戶必須積極地對待這一切，盡快做處理、做決定。因為開發人員通常隻有等你做 出了決定才能行動，而這種等待會延誤項目的進展。

5：尊重開發人員的需求可行性及成本評估

所有的軟體功能都有其成本價 格，開發人員最适合預算這些成本（盡管許多開發人員并不擅長評估預測）。你所希望的某些産品特性可能在技術上行不通，或者實作它要付出極為高昂的代價。而 某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的資料，開發人員會對此作出負面的評價意見，你應該尊重他們的意見。有時，你可以 重新給出一個在技術上可行、實作上便宜的需求，例如，要求某個行為在“瞬間”發生是不可行的，但換種更具體的時間需求說法（“在50ms以内”,但若沒有 準确的技術分析不能輕易下結論），這就可以實作了。

6： 劃分需求優先級别

大多數項目沒有足夠的時間或資源來實作功能性 的每個細節。決定哪些特性是必要的，哪些是重要的，哪些是好的，是需求開發的主要部分。隻能由你來負責設定需求優先級，因為開發者并不可能按你的觀點決定 需求優先級。開發者将為你确定優先級提供有關每個需求的花費和風險的資訊。當你設定優先級時，你幫助開發者確定在适當的時間内用最小的開支取得最好的效 果。在時間和資源限制下，關于所需特性能否完成或完成多少應該尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實作，但畢竟是要面對 這種現實的。業務決策有時不得不依據優先級來縮小項目範圍或延長工期，或增加資源，或在品質上尋找折衷。

7：評審需求文檔和原型

正如我們将在第1 4章讨論的，無論是正式的還是非正式的方式，對需求文檔進行評審都會對軟體品質提高有所幫助。讓客戶參與評審才能真正鑒别需求文檔是否的确完整、正确說明 了期望的必要特性。評審也給客戶代表提供一個機會，給需求分析人員帶來回報資訊以改進他們的工作。如果你認為編寫的需求文檔不夠準确，就有義務盡早告訴分 析人員并為改進提供建議。通過閱讀需求規格說明，很難想象實際的軟體是什麼樣子的。更好的方法是先為産品開發一個原型。這樣你就能提供更有價值的回報資訊 給開發人員，幫助他們更好地了解你的需求。必須認識到：原型并非是一個實際産品，但開發人員能将其轉變、擴充成功能齊全的系統。

8：需求出現變更要馬上聯系

不 斷的需求變更會給在預定計劃内完成高品質産品帶來嚴重的負面影響。變更是不可避免的，但在開發周期中變更越在晚期出現，其影響越大。變更不僅會導緻代價極 高的返工，而且工期也會被迫延誤，特别是在大體結構已完成後又需要增加新特性時。是以一旦你發現需要變更需求時，請一定立即通知分析人員。

9：應遵照開發組織處理需求變更的過程

為了将變更帶來的負面影響減少到最低限度，所有的參與者必須遵照項目的變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後作出合适的決策以确定将某些變更引入項目中。

10：尊重開發人員采用的需求工程過程

軟 件開發中最具挑戰性的莫過于收集需求并确定其正确性。分析人員采用的方法有其合理性。也許你認為需求過程不太劃算，但請相信花在需求開發上的時間是“很有 價值”的。如果你了解并支援分析人員為收集、編寫需求文檔和確定其品質所采用的技術，那麼整個過程将會更為順利。盡管去詢問分析人員為什麼他們要收集某些 資訊，或參與與需求有關的活動。

系統分析人員在開發過程中可能會遇到以下問題，一些很忙的客戶可能不願意積極參與需求過程，而缺少客戶參與将很可能導緻不理想的産品。故一定要確定需求開發中的主要參與者都了解并接受他們的義務。如果遇到分歧，通過協商以達成對各自義務的互相了解，這樣能減少今後的摩擦。

7．需求文檔

需 求開發的最終成果是：客戶和開發小組對将要開發的産品達成一緻協定。協定綜合了業務需求、使用者需求和軟體功能需求。就像我們早先所看到的，項目視圖和範圍 文檔包含了業務需求，而使用執行個體文檔則包含了使用者需求。你必須編寫從使用執行個體派生出的功能需求文檔，還要編寫産品的非功能需求文檔，包括品質屬性和外部接 口需求。隻有以結構化和可讀性方式編寫這些文檔，并由項目的風險承擔者評審通過後，各方面人員才能确信他們所贊同的需求是可靠的。

你可以使用以下三種方法編寫軟體需求規格說明：

用好的結構化和自然語言編寫文本型文檔。

建立圖形化模型，這些模型可以描繪轉換過程、系統狀态和它們之間的變化、資料關系、邏輯流或對象類和它們的關系。

編寫形式化規格說明，這可以通過使用數學上精确的形式化邏輯語言來定義需求。

由 于形式化規格說明具有很強的嚴密性和精确度，是以，所使用的形式化語言隻有極少數軟體開發人員才熟悉，更不用說客戶了。雖然結構化的自然語言具有許多缺 點，但在大多數軟體工程中，它仍是編寫需求文檔最現實的方法。包含了功能和非功能需求的基于文本的軟體需求規格說明已經為大多數項目所接受。圖形化分析模 型通過提供另一種需求視圖，增強了軟體需求規格說明。

軟體需求規格說明不僅是系統測試和使用者文檔的基礎，也是所有子系列項目規劃、設計和編碼的基 礎。它應該盡可能完整地描述系統預期的外部行為和使用者可視化行為。除了設計和實作上的限制，軟體需求規格說明不應該包括設計、構造、測試或工程管理的細 節。許多讀者使用軟體需求規格說明來達到不同的目的：

客戶和營銷部門依賴它來了解他們所能提供的産品。

項目經理根據包含在軟體需求規格說明中描述的産品來制定規劃并預測進度安排、工作量和資源。

軟體開發小組依賴它來了解他們将要開發的産品。

測試小組使用軟體需求規格說明中對産品行為的描述制定測試計劃、測試用例和測試過程。

軟體維護和支援人員根據需求規格說明了解産品的某部分是做什麼的。

産品釋出組在需求規格說明和使用者界面設計的基礎上編寫客戶文檔，如使用者手冊和幫助螢幕等。

教育訓練人員根據需求規格說明和使用者文檔編寫教育訓練材料。

軟體需求規格說明作為産品需求的最終成果必須具有綜合性：必須包括所有的需求。開發者和客戶不能作任何假設。如果任何所期望的功能或非功能需求未寫入軟體需求規格說明，那麼它将不能作為協定的一部分并且不能在産品中出現。

我見過有一個項目突然接到測試人員發出的錯誤災難的報告。結果是他們測試的是老版本的軟體需求規格說明，而他們覺得錯誤的地方正是産品所獨有的特性。他們的測試工作是徒勞的，因為他們一直在老版本的軟體需求規格說明中尋找錯誤的系統行為。

在編寫軟體需求規格說明，希望讀者牢記以下的建議：

對節、小節和單個需求的号碼編排必須一緻。

在右邊部分留下文本注釋區。

允許不加限制地使用空格。

正确使用各種可視化強調标志（例如，黑體、下劃線、斜體和其它不同字型）。

建立目錄表和索引表有助于讀者尋找所需的資訊。

對所有圖和表指定号碼和辨別号，并且可按号碼進行查閱。

使用字處理程式中交叉引用的功能來查閱文檔中其它項或位置，而不是通過頁碼或節号。

為了滿足軟體需求規格說明的可跟蹤性和可修改性的品質标準，必須唯一确定每個軟體需求。這可 以使你在變更請求、修改曆史記錄、交叉引用或需求的可跟蹤矩陣中查閱特定的需求。由于要達到這一目的，用單一的項目清單是不夠的，是以，我将描述幾個不同 的需求辨別方法，并闡明它們的優點與缺點。可以選擇最适合你的方法。

(1) 序列号最簡單的方法是賦予每個需求一個唯一的序列号，例如SRS-13。當一個新的需求加入到商業需求管理工具的資料庫之後，這些管理工具就會為其配置設定一 個序列号（許多這樣的工具也支援階層化編号）。序列号的字首代表了需求類型，例如SRS代表“軟體需求說明”。由于序列号不能重用，是以把需求從資料庫中 删除時，并不釋放其所占據的序列号，而新的需求隻能得到下一個可用的序列号。這種簡單的編号方法并不能提供任何相關需求在邏輯上或層次上的差別，而且需求 的辨別不能提供任何有關每個需求内容的資訊。

(2) 階層化編碼這也許是最常用的方法。如果功能需求出現在軟體需求規格說明中第3 . 2部分，那麼它們将具有諸如3.2.4.3這樣的辨別号。辨別号中的數字越多則表示該需求越詳細，屬于較低層次上的需求。即使在一個中型的軟體需求規格說 明中，這些辨別号也會擴充到許多位數字，并且這些辨別也不提供任何有關每個需求目的的資訊。如果你要插入一個新的需求，那麼該需求所在部分其後所有需求的 序号将要增加。删除或移去一個需求，那麼該需求所在部分其後所有需求的序号将要減少。但其他地方的引用将混亂，對于這種簡單的階層化編号的一種改進方法是 對需求中主要的部分進行階層化編号，然後對于每個部分中的單一功能需求用一個簡短文字代碼加上一個序列号來識别。例如，軟體需求規格說明可能包含“第 3.2.5部分—編輯功能”，并将此部分編寫成子子產品文檔，然後配置管理。

有時，你覺得缺少特定需求的某些資訊。在解決這個不确定性之 前，可能必須與客戶商議、檢查與另一個系統的接口或者定義另一個需求。使用“待确定”（to be determined, TBD或采用漢語拼音略寫DQD）符号作為标準訓示器來強調軟體需求規格說明中這些需求的缺陷。通過這種方法，你可以在軟體需求規格說明中查找所要澄清需 求的部分。記錄誰将解決哪個問題、怎樣解決及什麼時候解決。把每個TBD編号并建立一個TBD清單，這有助于友善地跟蹤每個項目。

在繼續 進行構造需求集合之前，必須解決所有的TBD問題，因為任何遺留下來的不确定問題将會增加出錯的風險和需求返工。當開發人員遇到一個TBD問題或其它模糊 之處時，他可能不會傳回到原始需求來解決問題。多半開發者對它進行猜測，但并不總是正确的。如果有TBD問題尚未解決，而你又要繼續進行開發工作，那麼盡 可能推遲實作這些需求，或者解決這些需求的開放式問題，把産品的這部分設計得易于更改。

編寫優秀的需求文檔沒有現成固定的方法，最好是根據經驗進行。從過去所遇到的問題中可使你受益匪淺。許多需求文檔可以通過使用有效的技術編寫風格和使用使用者術語而不是計算機專業術語的方式得以改進。

你在編寫優秀的需求文檔時，希望讀者還需牢記以下幾點建議：

保持語句和段落的簡短。

采用主動語态的表達方式。

編寫具有正确的文法、拼寫和标點的完整句子。

使用的術語與詞彙表中所定義的應該一緻。

需求陳述應該具有一緻的樣式，例如“系統必須..”或者“使用者必須..”，并緊跟一個行為動作和可觀察的結果。例如，“倉庫管理子系統必須顯示一張所請求的倉庫中有存貨的庫存清單。”

為了減少不确定性，必須避免模糊的、主觀的術語，例如，使用者友好、簡單、有效、、最新技術、優越的、可接受的等。當用客說“使用者友好”或者“快”時，你應該明确它們的真正含義并且在需求中闡明使用者的意圖。

避 免使用比較性的詞彙，定量地說明所需要提高的程度或者說清一些參數可接受的最大值和最小值。當客戶說明系統應該“處理”、“支援”或“管理”某些事情時， 你應該能了解客戶的意圖。由于需求的編寫是階層化的，是以，可以把頂層不明确的需求向低層詳細分解，直到消除不明确性為止。

文檔的編寫人員不應該把多個需求集中在一個冗長的叙述段落中。在需求中諸如“和”，“或”之類的連詞就表明了該部分集中了多個需求。務必記住，不要在需求說明中使用“和/或”，“等等”之類的連詞。

8．需求分析的過程

需 求擷取是在問題及其最終解決方案之間架設橋梁的第一步。擷取需求的一個必不可少的結果是對項目中描述的客戶需求的普遍了解。一旦了解了需求，分析者、開發 者和客戶就能探索出描述這些需求的多種解決方案。參與需求擷取者隻有在他們了解了問題之後才能開始設計系統，否則，對需求定義的任何改進，設計上都必須大 量的返工。把需求擷取集中在使用者任務上—而不是集中在使用者接口上—有助于防止開發組由于草率處理設計問題而造成的失誤。

需求擷取、分析、 編寫需求規格說明和驗證并不遵循線性的順序，這些活動是互相隔開、增量和反複的。當你和客戶合作時，你就将會問一些問題，并且取得他們所提供的資訊（需求 擷取）。同時，你将處理這些資訊以了解它們，并把它們分成不同的類别，還要把客戶需求同可能的軟體需求相聯系。然後，你可以使客戶資訊結構化，并編寫成文 檔和示意圖。下一步，就可以讓客戶代表評審文檔并糾正存在的錯誤。這四個過程貫穿着需求開發的整個階段。

由于軟體開發項目群組織文化的不 同，對于需求開發沒有一個簡單的、公式化的途徑。下面列出了1 4個步驟，你可以利用它們指導你的需求開發活動。對于需求的任何子集，一旦你完成了第十三步，那麼你就可以很有信心地繼續進行系統的每一部分的設計、構 造，因為你将開發出一個好的産品:

1. 定義項目的視圖和範圍。

2. 确定使用者類。

3. 在每個使用者類中确定适當的代表。

4. 确定需求決策者和他們的決策過程。

5. 選擇你所用的需求擷取技術。

6. 運用需求擷取技術對作為系統一部分的使用執行個體進行開發并設定優先級。

7. 從使用者那裡收集品質屬性的資訊和其它非功能需求。

8. 詳細拟訂使用執行個體使其融合到必要的功能需求中。

9. 評審使用執行個體的描述和功能需求。

10. 如果有必要，就要開發分析模型用以澄清需求擷取的參與者對需求的了解。

11. 開發并評估使用者界面原型以助想像還未了解的需求。

12. 從使用執行個體中開發出概念測試用例。

13. 用測試用例來論證使用執行個體、功能需求、分析模型和原型。

14. 在繼續進行設計和構造系統每一部分之前，重複6~1 3步。

需 求擷取可能是軟體開發中最困難、最關鍵、最易出錯及最需要交流的方面。需求擷取隻有通過有效的客戶—開發者的合作才能成功。分析者必須建立一個對問題進行 徹底探讨的環境，而這些問題與産品有關。為了友善清晰地進行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對需求問題的全面考察需 要一種技術，利用這種技術不但考慮了問題的功能需求方面，還可讨論項目的非功能需求。确定使用者已經了解：對于某些功能的讨論并不意味着即将在産品中實作 它。對于想到的需求必須集中處理并設定優先級，以避免一個不能帶來任何益處的無限大的項目。

需求擷取是一個需要高度合作的活動，而并不是客戶所說的需求的簡單拷貝。作為一個分析者，你必須透過客戶所提出的表面需求了解他們的真正需求。詢問一個可擴充的問題有助于你更好地了解使用者目前的業務過程并且知道新系統如何幫助或改進他們的工作。

需 求擷取利用了所有可用的資訊來源，這些資訊描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之 間采用了更多的交流方式。與單個客戶或潛在的使用者組一起座談，對于業務軟體包或資訊管理系統（MIS）的應用來說是一種傳統的需求來源。

在 每一次座談讨論之後，記下所讨論的條目，并請參與讨論的使用者評論并更正。及早并經常進行座談讨論是需求擷取成功的一個關鍵途徑，因為隻有提供需求的人才能 确定是否真正擷取需求。進行深入收集和分析以消除任何沖突或不一緻性。盡量了解使用者用于表述他們需求的思維過程。充分研究使用者執行任務時作出決策的過程， 并提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。

當進行需求擷取時，應避免受不成熟的細節的影響。在對切合的客 戶任務取得共識之前，使用者能很容易地在一個報表或對話框中列出每一項的精确設計。如果這些細節都作為需求記錄下來，他們會給随後的設計過程帶來不必要的限 制。你可能要周期性地檢查需求擷取，以確定使用者參與者将注意力集中在與今天所讨論的話題适合的抽象層上。向他們保證在開發過程中，将會詳盡闡述他們的需 求。

在一個逐次較長的描述過程中，重複地詳述需求，以确定使用者目标和任務，并作為使用執行個體。然後，把任務描述成功能需求，這些功能需求可以 使使用者完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和使用者對品質的期望。雖然最初的螢幕構思有助于描述你對需求的了解，但 是你必須細化使用者界面設計。