需求開發與管理是軟體項目中一項十分重要的工作，據調查顯示在眾多失敗的軟體項目中，由於需求原因導致的約佔到45%，因此，需求工作將對軟體項目能否最終實現產生至關重要的影響。雖然如此，在項目開發工作中，很多人對需求的認識還遠遠不夠，從本人蔘與或接觸到的一些項目來看，小到幾十萬元，大到上億元的軟體項目的需求都或多多少的存在問題，有的是開發人員本身不重視原因、有的是技術原因、有的是人員組織原因、有的是溝通原因、有的是機制原因，以上種種原因都表明做好軟體需求開發是一項系統工作，而不是簡單的技術工作，只有系統的瞭解和掌握需求的基本概念、方法、手段、評估標準、風險等相關知識，並在實踐中加以應用，才能真正做好需求的開發和管理工作。 本文將通過介紹關於軟體需求的基本知識和個人在實際工作中總結的一些經驗，協助讀者瞭解軟體需求，學習需求開發的一些基本方法，避免因需求原因而導致的項目失敗。 1 什麼是軟體需求和需求工程 1.1 軟體需求的定義 在IEEE軟體工程標準詞彙表(1997年)中定義軟體需求為： （1）使用者解決問題或達到目標所需的條件或能力。 （2）系統或系統組件要滿足合約、標準、規範或其它正式規定文檔所需具有的條件或能力。 （3）一種反映上面(1)或(2)所描述的條件或權能的文檔說明。 實通俗的講，“需求”就是使用者的需要，它包括使用者要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程式或系統開發工作的說明，表現形式一般為文檔形式。 1.2 需求工程的定義 需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。需求開發是指從情況收集、分析和評價到編寫文檔、評審等一系列產生需求的活動，分為四個階段：情況擷取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反覆的。需求管理是軟體項目開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。 2 需求分析的風險 由於需求分析的參與人員、業務模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風險。這些風險主要表現在： （1）使用者不能正確表達自身的需求。在實際開發過程中，常常碰到使用者對自己真正的需求並不是十分明確的情況，他們認為電腦是萬能的，只要簡單的說說自己想幹什麼就是把需求說明白了，而對業務的規則、工作流程卻不願多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與使用者交流，協助他們梳理思路，搞清使用者的真實需求。 （2）業務人員配合力度不夠。有的使用者日常工作繁忙，他們不願意付出更多的時間和精力向分析人員講解業務，這樣會加大分析人員的工作難度和工作量，也可能導致因業務需求不足而使系統無法使用。 （3）使用者需求的不斷變更。由於需求識別不全、業務發生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命週期都可能發生變化，因此，我們要認識到，軟體開發的過程實際上是同變化做鬥爭的過程，需求變化是每個開發人員、專案管理人員都會遇到的問題，也是最頭痛的問題，一旦發生了需求變化，就不得不修改設計、重寫代碼、修改測試案例、調整專案計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。 （4）需求的完整程度。需求如何做到沒有遺漏？這是一個大問題，大的系統要想窮舉需求幾乎是不可能的，即使小的系統，新的需求也總會不時地冒出來。一個系統很難確定明確的範圍並把所有需求一次性提出來，這會導致開發人員在項目進展中去不斷完善需求，先建立系統結構再完成需求說明，造成返工的可能性很大，會給開發人員帶來挫折感，降低他們完成項目的信心。 （5）需求的細化程度。需求到底描述到多細，才算可以結束了？雖然國家標準有需求說明的編寫規範，但具體到某一個需求上，很難給出一個具體的指標，可謂仁者見仁，智者見智，並沒有定論。需求越細，周期越長，可能的變化越多，對設計的限制越嚴格，對需求的共性提取要求也越高，相反，需求越粗，開發人員在技術設計時不清楚的地方就越多，影響技術設計。 （6）需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產生了不同的理解；另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使使用者和開發人員等項目參與者產生不同的期望，也會使開發、測試人員為不同的理解而浪費時間，帶來不可避免的後果便是返工重做。 （7）忽略了使用者的特點分析。分析人員往往容易忽略了系統使用者的特點，系統是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育程度和經驗水平不盡相同。如果忽略這些的話，將會導致有的使用者對產品感到失望。 （8）需求開發的時間保障。為了確保需求的正確性和完整性，項目負責人往往堅持要在需求階段花費較多的時間，但使用者和開發部門的領導卻會因為項目遲遲看不到實際成果而焦慮，他們往往會強迫項目儘快往前推進，需求開發人員也會被需求的複雜和善變折騰的筋疲力盡，他們也希望儘快結束需求階段。 3 如何做好需求工作 需求分析是軟體項目開發中最困難的一項工作，它不僅要求分析人員具有豐富的需求分析經驗和良好的專業素質，還要求分析人員具有良好的學習能力、公關能力、語言能力和組織能力。在實際工作中分析人員要面對不同的單位、不同的部門、不同的人員、不同的文化、不同的關係、不同的管理水平等等不同的情況，面對如此紛繁複雜的環境，如何做好需求分析工作？首先需要建立一個有效工作機制，只有建立了工作機制，才能保證需求工作按照既定方案執行，需求開發和管理的參與者才會在一種有序的狀態下工作。其次才是充分運用工作機制和個人能力去擷取問題、分析問題、編寫需求文檔和進行需求管理。 3.1 建立需求分析工作機制需考慮的幾個因素 （1）抓住決策者最迫切和最關心的問題，引起重視。使用者方決策者對項目的關心重視程度是項目能否順利開展的關鍵，決策者的真實意圖也是使用者方的最終需求，因此，在開發過程中要利用一切機會瞭解決策者關心的問題，同時也要讓他們瞭解項目的情況。在諸如談判、專題彙報、協調會議、領導視察、階段性成果示範等過程中用簡短明確的語言或文字抓住領導最關心的問題，引導他們瞭解和重視項目的開發，當決策者認識到項目的重要性時，需求分析工作在人力、物力、時間上就有了保障。 （2）建立組織保障，明確的責任分工。項目開發一般都會成立相應的項目組或工程組，目前，常見的組織形式是：產品管理組、品質與測試組、程式開發組、使用者代表組和後勤保障組，各組的主要分工是：產品管理組負責確定和設定項目目標，根據需求的優先順序確定功能規格，向相關人員通報項目進展。程式管理組負責系統分析，根據軟體開發標準協調日常開發工作確保及時交付開發工作單位，控制項目進度。程式開發組負責按照功能規格要求交付軟體系統。品質與測試組負責保證系統符合功能規格的要求，測試工作與開發工作是獨立並行的。使用者代表組負責代表使用者方提出需求，負責軟體的使用者方測試。後勤保障組負責確保項目順利進行的後勤保障工作。 （3）建立良好的溝通環境和氛圍。分析人員與使用者溝通的程度關係到需求分析的品質，因此建立一個良好的溝通氛圍、處理好分析人員與使用者之間的關係顯得尤其重要，一般情況，使用者作為投資方會有一些心理優勢，希望他們的意見得到足夠的重視，分析人員應該充分的認識到這一點，做好心理準備，盡量避免與他們發生爭執，因為我們的目的是協助使用者說出他們的最終需要。在溝通時分析人員應注意以下幾個方面：1）態度上要尊重對方，但不謙恭。謙恭可能會讓使用者一時感到滿意，但對長期合作並沒有好處，尤其是在發生衝突的時候，使用者會習慣性地感到自己的優勢，而忽略分析人員地意見。2）分析人員要努力適應不同使用者的語言表達方式。每個人都有自己的表達方式，所以優秀的分析人員應該是一個優秀的“傾聽者”，他們能很快的適應使用者的語言風格，理解他們的意思。3）善於表達自己，善於提問。分析人員在開口前應該先讓對方充分表達他的意思，在領會了後，自己再說，盡量不要搶話。4）工作外的交流有助於增進理解，加強溝通。 （4）需求品質控制要制度化需求的變化是軟體項目不可避免的事實，因此需求品質控制是一項艱苦的工作，要保證該項工作的順利實施，就必須有制度保證，這個制度可以在項目品質控制方案中制定，該方案主要是具體化、定量化的描述使用者要求，形成全面、一致、規範的軟體需求分析規格說明書，明確需求分析規格說明書的工作程式和要素，規範開發活動，為後續軟體設計、實現、測試、評審及驗收提供依據。在方案中要明確項目組各部門關於需求品質控制的職責，制定需求分析的工作程式，包括編製需求分析工作計劃、編製《需求分析說明書》、《需求分析規格說明書》的評審和確認、《需求分析規格說明書》修改控制、確定需求品質控制的品質記錄文檔規範等內容。 3.2 需求開發與管理的一些方法 需求開發是一項複雜的工作，使用的方法也很多，不同的開發方式有不同的方法，這裡簡單介紹一些相關的方法： （1）繪製關聯圖：繪製系統關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。 （2）可行性分析：在允許的成本、效能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。 （3）需求優先順序：確定使用執行個體、產品特性或單項需求實現的優先順序別。以優先順序為基礎確定產品版本將包括哪些特性或哪類需求。 （4）系統原型：當使用者自身對有的需求不十分清楚時，我們可以建立一個系統原型，使用者通過評價原型更好地理解所要解決的問題。。 （5）圖形分析模型：繪製圖形分析模型是編製軟體需求規格說明重要手段。它們能協助分析人員理清資料、業務模式、工作流程以及他們之間的關係，找出遺漏、冗餘和不一致的需求。這樣的模型包括資料流圖、實體關聯圖、狀態變換圖、對話方塊圖、對象類及互動作用圖。 （6）資料字典：資料字典是對系統用到的所有資料項目和結構的定義，以確保開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項目，確保客戶與開發小組是使用一致的定義和術語。 （7）品質功能調配：品質功能調配是一種進階系統技術，它將產品特性、屬性與對客戶的重要性聯絡起來。該技術提供了一種分析方法以明確哪些是客戶最為關注的特性。它將需求分為三類：期望需求、普通需求、興奮需求。 需求管理的目的就是要控制和維持需求事先約定，保證項目開發過程的一致性，使使用者得到他們最終想要得產品。需求管理的方法主要包括以下一些方面： 1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。 2）進行需求變更影響分析。評估每項需求變更，以確定它對專案計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。通過這些分析將有助於需求變更控制部門做出更好的決策。 3）建立需求基準版本和需求控製版本文檔。確定需求基準，這是項目各方對需求達成一致認識時刻的一個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。 4）維護需求變更的記錄。將需求變更情況寫成文檔，記錄變更日期、原因、負責人、版本號碼等內容，及時通知到項目開發所涉及的人員。為了盡量減少困惑、衝突、誤傳，應指定專人來負責更新需求。 5）跟蹤每項需求的狀態。可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）儲存在資料庫中，這樣可以在任何時候得到每個狀態類的需求數量。 6）衡量需求穩定性。可以定期把需求數量和需求變更（添加、修改、刪除）數量進行比較。過多的需求變更"是一個警示訊號"，意味著問題並未真正弄清楚。 4 需求分析評價標準 如何判斷需求規格說明的好壞，不同的軟體工程規範都有自己的一套標準，這裡向大家介紹一個比較常見的NASA SEL推薦方法，它是由美國國家航空和航天局軟體工程實驗室開發的五大常用國際軟體工程規範之一，它對軟體需求過程的評價標準是：清晰、完整、一致、可測試。 （1）清晰：目前大多數的需求分析採用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中採用的語言做某些限制。例如盡量採用主語＋動作的簡單表達方式。需求分析中的描述一定要簡單，千萬不要採用疑問句、修飾這些複雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是電腦術語。需求分析最重要的是和使用者溝通，可是使用者多半不是電腦的專業人士，如果在需求分析中使用了行話，就會造成使用者理解上的困難。 （2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟體開發過程中，最糟糕的事情莫過於在軟體開發接近完成時發現遺漏了一項需求。但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在使用者那裡。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最後的需求評審。 （3）一致：一致性是指使用者需求必須和業務需求一致，功能需求必須和使用者需求一致。在需求過程中，開發人員需要把一致性關係進行細化，比如使用者需求不能超出預前指定的範圍。嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。 （4）可測試：一個項目的測試從什麼時候開始呢？有人說是從編碼完成後開始，有人說是編碼的時候同時進行單元測試，編碼完成後進行系統測試，這些結論都不完全正確。實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟體始終圍繞著使用者的需要，保證軟體系統是成功的。 |
