什麼是軟體需求？軟體需求是什麼意思？

 

什麼是軟體需求？軟體需求是什麼意思？   　　對大多數人來說，若要建一幢數百萬元的房子，他一定會與建房者詳細討論各種細節，他們都明白完工以後的修改會造成損失，以及變更細節的危害性。然而，涉及到軟體開發，人們卻變得“大大咧咧”起來。軟體項目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”(Leffingwell 1997)。可許多組織仍在那些基本的項目功能上採用一些不合規範的方法，這樣導致的後果便是一條鴻溝(期望差異)—開發人員開發的與使用者所想得到的軟體存在著巨大期望差異。 　　在軟體工程中，所有的風險承擔者(stakeholder)(這個詞很有意思，原義是賭金保管者。我看過很多的翻譯，有翻譯成涉眾的，也有的翻譯成參與者的，但是我想他的主要意思就是和這個項目有密切相關利益的人)都感興趣的就是需求分析階段。這些風險承擔者包括客戶、使用者、業務或需求分析員(負責收集客戶需求並編寫文檔，以及負責客戶與開發機構之間聯絡溝通的人)、開發人員、測試人員、使用者文檔編寫者、專案管理者和客戶管理者。這部分工作若處理好了，能開發出很出色的產品，同時會使客戶感到滿意，開發人員也倍感滿足、充實。若處理不好，則會導致誤解、挫折、障礙以及潛在品質和業務價值上的威脅。因為需求分析奠定了軟體工程和專案管理的基礎，所以所有風險承擔者最好是採用有效需求分析過程。    軟體需求的定義

IEEE軟體工程標準詞彙表(1997年)中定義需求為：(1)使用者解決問題或達到目標所需的條件或權能(Capability)。(2)系統或系統組件要滿足合約、標準、規範或其它正式規定文檔所需具有的條件或權能。(3)一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 

需求的層次　　下面這些定義是需求工程領域中常見術語的定義說明。　　軟體需求包括三個不同的層次—業務需求、使用者需求和功能需求—也包括非功能需求。業務需求( business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與範圍文檔中予以說明。使用者需求(user requirement) 文檔描述了使用者使用產品必須要完成的任務，這在使用執行個體(use case)文檔或方案指令碼(scenario)說明中予以說明。功能需求(functional requirement)定義了開發人員必須實現的軟體功能，使得使用者能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給使用者提供處理能力並滿足業務需求。軟體需求各組成部分之間的關係。作為補充，軟體需求規格說明還應包括非功能需求，它描述了系統展現給使用者的行為和執行的操作等。它包括產品必須遵從的標準、規範和合約；外部介面的具體細節；效能要求；設計或實現的約束條件及品質屬性。所謂約束是指對開發人員在軟體產品設計和構造上的限制。品質屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對使用者和開發人員都極為重要。值得注意的一點是，需求並未包括設計細節、實現細節、專案計劃資訊或測試資訊。需求與這些沒有關係，它關注的是充分說明你究竟想開發什麼。Frederick Brooks在他1987年的經典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分說明了需求過程在軟體項目中扮演的重要角色：開發軟體系統最為困難的部分就是準確說明開發什麼。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向使用者、面向機器和其它軟體系統的介面。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，並且以後再對它進行修改也極為困難。為什麼這麼說呢，因為在大多數的軟體系統中，終端使用者可能都不清楚他的需求是什麼，這是千真萬確的。如果你的使用者告訴你需求就是這些了，不要相信他，繼續刨根問底，直到你們都筋疲力盡了。雖然聽上去有些不可思議，但這是教訓之談，在我從事的項目之中，沒有一個使用者在軟體接近完成的時候打電話對我說，我看了你們的軟體，我想我必須改動一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼症。     需求風險下面列出了在做需求分析時一些很危險的做法，如果你發現你的一些做法與之相似，那麼，給自己一些時間，好好思考一下，這些做法會對你的軟體產生致命的影響。1. 無足夠使用者參與客戶經常不明白為什麼收集需求和確保需求品質需花費那麼多功夫，開發人員可能也不重視使用者的參與。究其原因：一是因為與使用者合作不如編寫代碼有意思；二是因為開發人員覺得已經明白使用者的需求了。在某些情況下，與實際使用產品的使用者直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的使用者在項目早期直接參与到開發隊伍中，並一同經曆整個開發過程。最重要的就是使用者必須要重視他的軟體，必須讓他明白：如果失敗，他的損失最大(當然你的損失也不小，但這時候你必須讓他重視這項工作)。如果使用者不夠重視，想辦法解決，否則你就不用再繼續了。2. 使用者需求的不斷增加在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算範圍。這使得問題更難解決。實際上，問題根源在於使用者需求的改變和開發人員對新需求所作的修改。要想把需求變更範圍控制到最小，必須一開始就對項目視圖、範圍、目標、約束限制和成功標準給予明確說明，並將此說明作為評價需求變更和新特性的參照架構。說明中包括了對每種變更進行變更影響因素分析的變更控制過程，有助於所有風險承擔者明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個程式難以理解和維護。插入補丁代碼使模組違背強內聚、松耦合的設計原則，特別是如果項目組態管理工作不完善的話，收回變更和刪除特性會帶來問題。如果你儘早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，並能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利於減少因變更導致品質的下降。最糟糕的莫過於使用者覺得如果不再加點什麼功能就對不起自己。我曾經看過一個資料倉儲的一期工程，在設計階段沒有很好的定義範圍，當我向專案管理者提出這個問題的時候，他認為都已經說好了，合約上也寫清楚了，並沒有加以重視。可是最後，使用者提出的修改意見已經遠遠超出了範圍，項目時間也延長了一倍。整個的項目群組成員疲憊不堪，可是卻不斷的接到使用者投訴說項目失敗。3. 模稜兩可的需求模稜兩可是需求規格說明中最為可怕的問題(Lawrence 1996)。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。模稜兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，並且使測試者與開發人員所期望的不一致。一位系統測試人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多測試案例並重做許多測試。模稜兩可的需求帶來不可避免的後果便是返工—重做一些你認為已做好的事情。返工會耗費開發總費用的40%，而70%～85%的重做是由於需求方面的錯誤所導致的(leffingwell 1997)。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正瞭解需求文檔，這樣二義性就不會直到項目後期才被發現，那時再發現的話會使得更正代價很大。　　4. 不必要的特性　　“畫蛇添足”是指開發人員力圖增加一些“使用者欣賞”但需求規格說明中並未涉及的新功能。經常發生的情況是使用者並不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應確信：你明白為什麼要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使使用者完成他們業務任務的核心功能。時刻記住：軟體成功的標準是是否解決使用者的問題，而不是它有多Cool的功能。　　5. 過於精簡的規格說明　　有時，客戶並不明白需求分析有如此重要，於是只作一份簡略之至的規格說明，僅涉及了產品概念上的內容，然後讓開發人員在項目進展中去完善，結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明。這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況(McConnell 1996)，不過商業應用大多都不是這種情況。在大多數情況下，這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作)，也會給客戶帶來煩惱(他們無法得到他們所設想的產品)。　　6. 忽略了使用者分類　　大多數產品是由不同的人使用其不同的特性，使用頻繁程度也有所差異，使用者受教育程度和經驗水平也不盡相同。如果你不能在項目早期就針對所有這些主要使用者進行分類的話，必然導致有的使用者對產品感到失望。例如，菜單驅動操作對進階使用者太低效了，但含義不清的命令和快速鍵又會使不熟練的使用者感到困難。 7. 不準確的計劃“上述是我對新產品的看法，好，現在你能告訴我你什麼時候能完成嗎？”許多開發人員都遇到這種難題。對需求分析缺乏理解會導致過分樂觀的估計，而當不可避免的超支發生時，會帶來頗多麻煩。據報道，導致需求過程中軟體成本估計極不準確的原因主要有以下五點：頻繁的需求變更、遺漏的需求、與使用者交流不夠、品質低下的需求規格說明和不完善的需求分析(Davis 1995)。對不準確的要求所提問題的正確響應是“等我真正明白你的需求時，我就會來告訴你”。基於不充分資訊和未經深思的對需求不成熟的估計很容易為一些因素左右。要作出估計時，最好還是給出一個範圍(如最好的情況下，很可能的，最壞情況下)或一個可信賴的程度(我有9 0 %的把握，我能在8周內完成)。未經準備的估計通常是作為一種猜測給出的，聽者卻認為是一種承諾。因此我們要儘力給出可達到的目標並堅持完成它。 什麼是優秀的需求討論軟體需求的文章有很多，對於需求的標準也不盡相同，這裡我想用NASA的軟體開發過程中的概念，軟體需求過程的標準是：清楚(Clear)、完整(Complete)、一致(Consistent)、可測試(Testable)，此外還有其他的概念，如可跟蹤的、可修改的等等。清楚：目前大多數的需求分析採用的仍然是自然語言（因為如果採用形式化語言的話，和使用者的溝通將成為一個大問題，這意味著客戶在開發軟體之前必須先進行形式化語言培訓，這是不現實的）。自然語言對需求分析最大的弊病就是它的二義性。所以我們不得不對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。說白了，需求分析中的描述讓人看上去像是剛學習寫作的小孩子就對了，千萬不要採用疑問句、修飾這些華麗的表達方式。除了語言的二義性之外，主意不要使用行話，就是電腦術語。需求分析最重要的是和使用者溝通，可是使用者多半不是電腦的專業人士，如果在需求分析中使用了行話，就會造成使用者理解上的困難。打個比方，如果你要做一個銀行的信用卡系統，你就可以這樣描述軟體需求：銀行的卡部管理信用卡，每張信用卡只屬於一個帳戶。信用卡有卡號、餘額。一張信用卡有多筆的交易記錄。完整：再也沒有什麼比軟體開發接近完成是發現遺漏了一項需求更糟的事情了。需求的完整性是非常非常重要的，想象一下遺漏需求而不得不返工，這簡直就是惡夢。可是令人遺憾的是，需求的遺漏是很經常發生的事情，不僅僅是你的問題，更多的問題發生在使用者那裡，他們不知道該做些什麼。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計劃制定到最後的需求評審。至於完整性的詳細討論，我們會在下面的章節中討論，現在你只需要拚命的想象缺乏完整性的壞處，直到你出了一身的冷汗。出了嗎？好，那我們繼續。一致：一致性也是一個比較大的概念，很難用幾句話講清楚。還記得我們在開始的時候提到的需求的層次嗎？簡單的來說，就是使用者需求必須和業務需求一致，功能需求必須和使用者需求一致。嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。在實現過程中，我們還必須把一致性關係細化。比如說使用者需求不能超出先前指定的範圍。 可測試：大家覺得一個項目的測試從什麼時候開始呢？有人說從編碼完成後開始。更清楚一點的說是編碼的時候同時進行單元測試，編碼完成後進行系統測試。這些都沒有錯。但是實際上測試是從需求分析過程就開始了。需求分析是測試計劃的輸入和參照。這就要求需求分析是可測試的。什麼是可測試呢？“我們要用新的系統完成報表自動化處理”，你覺得這個需求是可測試的嗎？當然不是，報表包括哪些？自動化處理的標準是什嗎？這些在需求中都沒有說明。因此這項需求是無法測試的，就是不具有可測試性。說到這裡，大家可能就會明白之前的需求的幾項標準都是為了保證需求的可測試性的。事實就是這樣，只有系統的所有需求是可以被測試的，才能夠保證軟體始終圍繞著使用者的需要，保證軟體系統是成功的。