如何進行軟件需求分析

關鍵字：軟件需求分析1．概念
需求的定義包括從用戶角度（系統的外部行為），以及從開發者角度（一些內部特性）來闡述需求。
關鍵的問題是一定要編寫需求文檔。我曾經目睹過一個項目中途更換了所有的開發者，客戶被迫與新的需求分析者坐到一起。系統的分析人員說：“我們想與你談談你的需求?！笨蛻舻牡谝环磻闶牵骸拔乙呀泴⑽业囊蠖几嬖V你們前任了，現在我要的就是給我編一個系統”。而實際上，需求并未編寫成文檔，因此新的分析人員不得不從頭做起。所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話，你就確信你已明白用戶的需求，那完全是自欺欺人。
需求的另外一種定義認為需求是“用戶所需要的并能觸發一個程序或系統開發工作的說明”。有些需求分析專家拓展了這個概念：“從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等”。這些定義強調的是產品是什么樣的，而并非產品是怎樣設計、構造的。而下面的定義則從用戶需要進一步轉移到了系統特性：
需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。
從上面這些不同形式的定義不難發現：并沒有一個清晰、毫無二義性的“需求”術語存在，真正的“需求”實際上在人們的腦海中，這個人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對。系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識。
任何文檔形式的需求（例如如下將要描述的需求規格說明書）僅是一個模型，一種描述。

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

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

 

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

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：獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功。但這不僅要求你要清晰地告知開發人員關于系統“做什么”所需的所有信息，而且還要求開發人員能通過交流了解清楚取舍與限制。一定要明確說明你的假設和潛在的期望。否則，開發人員開發出的產品很可能無法讓你滿意。

原文轉自：http://www.anti-gravitydesign.com