時間：2022-05-31 06:13:56
開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇項目需求分析，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。
2 什么是需求分析
結構化軟件開發一般分為分析、設計、開發、測試、驗收與運行等階段。開發前，會進行前期的可行性研究；在運行開始以后，還要進行后期維護。需求分析是結構化開發中的重要階段。通常情況下，國內軟件開發公司在做歐美和日本的項目時，對前期的可行性研究參與得較少，一般都是對方已經做完可行性研究，國內軟件開發公司從需求分析開始做起，直到軟件開發后的運行和維護。所謂需求分析，是指對要解決的問題進行詳細的分析，弄清楚客戶的需求，包括需要輸入什么數據，要得到什么結果，最后應輸出什么，等等。可以說，軟件工程當中的需求分析就是確定要計算機做什么。
3 需求分析的重要性
從需求分析的定義上，就可以看出需求分析在軟件開發過程中的重要性了。需求分析做得不對，后面的步驟做得再好，也只能是南轅北轍，無法滿足客戶的要求。研究表明，改正產品付諸應用后所發現的一個需求方面的缺陷，比在需求階段改正這個錯誤要多付出大約100倍的成本。而另一項研究發現，在需求開發階段發現的一個錯誤，平均僅需要花30分鐘修復，但若在系統測試時發現則需要5-17個小時來修復。
需求工程的成功與否直接關系到系統給的命運，需求工程絕對不是軟件開發的前期任務，而應該在整個系統的生命周期里都扮演著重要角色。在需求工程階段解決和根除需求引起的問題可以大大降低生產和維護的成本，提高用戶的滿意度。在軟件開發的過程中，需求工程階段是了解用戶需求的最佳時期，但很大一部分用戶不知道、不了解需求工程，以至于在和他們交流的時候，他們都不能準確完整的說出自己的需求，因而對于從事需求工程的人員來說，能夠正確的理解用戶的需求觀點，利用一些方法和技巧來啟發用戶闡述清楚自己的需求是很重要的。需求工程作為了解并實現軟件開發者的目標的重要手段，有著不可替代的作用。
比如一個失敗的案例：由于和客戶簽訂了合同，5個月必須交付軟件，開發時間緊迫，導致項目計劃時做需求分析的時間只給了2周時間（理由是客戶的文檔已經提供好了，照著做即可）。結果，由于前期對客戶文檔理解得不是很清楚，導致開發進行到3個月的時候發現需求上有爭議。在和客戶確認后得出結論：如果要滿足客戶的要求，則需要對整體架構進行修改。雖然最后按期交付了軟件，但是整個項目組最后兩個月每天都在加班，包括周末，而且軟件質量也沒有得到客戶的充分認可。
再如我們在了解客戶需求的同時，應該盡量了解客戶為什么要這么做，幫客戶一起想需求，以便我們開發的軟件能夠更好地為客戶服務。每天開完會后，我們應該把客戶的需求整理好，發給同事進行研究分析，建立簡單的基礎模型并研究技術可行性。需求分析結束后，保持每周至少3次電話會議與客戶進行溝通，隨時了解客戶的需求。最后正因為在前期階段進行了這種細致的需求分析，項目組在很少加班的情況下，不但按時交付了項目，并且得到客戶的充分認可。
4 軟件需求分析的任務
軟件工程的發展來源于信息需求對它的推動，現在互聯網技術和應用越來越成熟，信息的獲取也逐漸變得簡單和完整，但是由于資源的開放性、系統與系統的相互滲透性、用戶的變動性讓需求變得多目的、多變化，增加了軟件制作的難度，但同樣帶來了巨大的用戶市場。需求的獲取同樣也是困擾軟件工程的絆腳石。需求與資源的搭配不合理，就會影響軟件工程的發展。未來適應變化多端的用戶需求，必須讓軟件也隨之變化。要滿足多樣化的信息需求，提取合適的信息需求建立模式，就要有相應的系統對需求信息進行分析和總結，通過程序化的模式來制定切實可行的軟件方案。
國項目中，在前期分析時軟件開發的核心技術人員和測試人員就已經進入項目組，每天技術人員會對分析的結果提出技術實現的難點以及改進的方法，筆者在隨后的會議上就會和客戶進行討論，盡量在滿足客戶需求的同時，使用更簡單可行的技術，這樣就為以后的開發奠定了基礎，使開發時的工作量大大減少。測試人員也在需求時提出從測試角度看到的問題，同樣在需求分析階段得到解決，節省了大量的開發時間。
需求工程在未來發展中會有如下幾個方面的著重考慮：（1）縮小需求工程在理論研究階段取得的成果同實際應用中得到的效果的差距，通過得到的結論來更好的設計軟件；（2）規范需求工程的各種機制，可以有需求工程規格數據的搜集、整理、制作、實現以及維護，也可以有需求工程的問題的解決辦法；（3）保證需求工程有較高的質量。這一點是需求工程最為關鍵的要求，質量的高低直接影響了未來實現效果的好壞。需求工程就是對未知問題進行探索、處理的過程。未來必然會朝著對象具體化、分析自動化的方向發展。
5 進行需求分析的注意事項
5.1 需求分析是分析人員與用戶共同的責任
用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人員則要認真了解用戶的要求，細致地進行調查分析，把用戶做什么的要求最終轉換成一個完全的、精細的軟件邏輯模型，并寫出軟件的需求規格說明，準確地表達用戶的要求。在一些項目中，由于時間緊迫，一些模糊問題沒有及時澄清，導致最后返工，影響了項目進度。
5.2 需求分析階段研究的對象是軟件項目的用戶要求
需要注意的是，必須理解用戶的各項要求，但又不能全盤接受所有的要求。在一些項目中，針對客戶提出的需求，了解客戶的意圖后，發現技術上實現有很大難度。我們了解到這個需求對客戶來說不是十分重要，于是和客戶商量出一個折中的解決方案，繞過技術難點，并且沒有降低客戶滿意度。
5.3 主動積極了解客戶業務和相關知識
求討論集中于業務需求和任務，因此要使用術語。客戶應將有關術語教給分析人員，而客戶不一定要懂得計算機行業的術語。由于通常情況下客戶對計算機術語了解不多，需求分析人員應該盡量將計算機術語轉化成通俗易懂的語言，這樣便于和客戶溝通。而對于客戶方面的術語，一方面不懂的時候一定要問；另一方面也要多學習。
論文摘要:計算機軟件項目管理中的需求分析是提高軟件質量的基礎也是決定一個軟件項目成敗的關鍵。本文介紹了在需求分析研究中探索出的一些有效措施。
眾觀國內計算機軟件業的發展，除遠不如歐美等西方發達國家外，與人均GDP不及我國的印度相比也相距甚遠，軟件業的劣勢正嚴重制約著我國IT業的發展。我國軟件業的劣勢表現在自主開發的成熟軟件不多，而開發的大量軟件工程項目(如ERP等)存在缺陷或完全開發失敗。目前，國家正在加大對軟件工程的研究和對軟件工程人才的培養。根據資料顯示，屬于需求分析造成軟件設計的錯誤和缺陷約占軟件失敗的6400，而屬于程序代碼的錯誤僅占軟件失敗的360a，數據表明需求分析是提高軟件質量的基礎也是決定一個軟件項目成敗的關鍵。通過對軟件項目管理知識的系統學習并結合近年來自己參與部分軟件項目實施的經驗，介紹在需求分析研究中探索出的一些有效措施。
1盡快熟悉項目用戶方干系人全貌
項目用戶方干系人，指所有可能受到項目結果重大影響的人，即項目的風險承擔者，他可能是項目的受益者，也可能是項目的受害者。因此，應當從項目的啟動開始，需求分析員及其項目成員就要分清項目用戶方干系人包含哪些人和組織，通過溝通協調對他們施加影響，驅動他們對項目的支持，調查并明確他們的需求和愿望，減小其對項目的阻力，以確保項目獲得成功。
有些項目在做需求調查時，由于受進度要求等客觀因素影響，需求分析員與建設單位的技術部門交流較多，向業務管理部門和實際使用者調查不夠深入，造成軟件試用后不得不再對需求做較大調整，“從頭再來”的部分比例很高，大大超過進度要求時間。因此，熟悉項目用戶方干系人全貌是進行需求調查的第一步，也是需求調查的基礎。在定制開發項目的項目用戶方干系人中，最重要的是建設單位中的人事組織、業務關系。最好是能夠用組織結構圖畫出相關單位的組織結構;還應當在相關單位組織結構圖基礎上畫出全體項目用戶方干系人結構圖，以便更好更全面地進行需求調研分析;用責任矩陣確定各部分的調研對象;建立調研對象通訊錄以保證調研及分析期間及時的溝通。
2采取正確的需求獲取方法
軟件開發項目的目的就是要實現項目用戶方的需求，項目用戶方的需求包含明確的和隱含的，也可以分為NEED， WANT， WISH等不同的層次。如果對項目所有用戶方干系人沒有進行足夠的溝通和影響，使其盡可能地參與項目，則會出現客戶方相關責任人不明確或對范圍和需求責任心不強，提出的需求具有隨意性，項目前期對需求的確認不夠積極，或者是多個用戶代表各說各話、昨是今非，項目后期需求變化隨意等現象，這就會造成項目范圍的蔓延，進度的拖延，成本的擴大，甚至項目的完全失敗。
各種用戶對系統具有不同的要求，如一個沒有經驗的用戶關心系統是否簡單易用，對于高級用戶則關心產品的易用性和高效性。因而需要對用戶進行分類，每一個用戶類將有自己的一系列功能和非功能要求。在項目中，要盡早為產品確定并描述不同的用戶類，這樣就能從每一個重要的用戶類代表中獲取不同的需求。
項目需求具有雙面性(用戶與開發商)和多面性(項目中各干系人)，因此，項目經理和系統集成者應了解用戶干系人需求，用戶干系人也應了解技術方面的需求，兩者缺一不可。正確的需求獲取需要了解需求的來源、用戶的分類、用戶的代表性、用戶需求誰說了算數等因素。開發人員和項目經理要有足夠的耐心聆聽用戶的講述，要足夠詳細地了解每一個細節。項目管理者要善于將需求分類、歸類，善于將需求文檔化，并有所查詢標記。
3可視化需求調研，引導各種客戶挖掘他們的需求
有的客戶因為自己缺乏計算機知識，無法提出完整準確、隱含的或潛在的需求。若這些需求不能滿足將導致用戶的不滿。因此需求調研分析人員應善于想用戶所想，不但要確定明確的需求，還要善于用啟發的方式與用戶探討隱含的或潛在的需求，并結合各種調研分析技術挖掘超出客戶期望的令人興奮的需求。這就要求需求調研分析員要盡快完整地熟悉相關業務，從而能夠站在用戶的立場看待軟件需求，想用戶所想，做好業務與計算機之間的橋梁。利用可視化需求調研的方法可以很好地啟發用戶深人挖掘潛在的需求。可視化需求調研就是使用圖表等工具來啟發引導用戶清楚地敘述需求，并且使需求更加全面完善。
對于高層領導，可以提供系統總體框架圖;對于業務管理人員，可以用業務流程圖來描述新舊系統的業務流程;對于客戶中的技術人員，可以用數據流圖、實體關系圖或UMI中的各種圖形對系統進行各種角度的描述;而對于業務管理人員、客戶中的技術人員、以及各層次各流程中的用戶，畫出用戶界面圖來進行需求挖掘，是個比較有效的溝通方式。
這里特別說明一下用戶界面的重要性。用戶界面的設計按理來說是軟件設計的責任，當然客戶自己對界面有特別提出要求的除外。但是，如果把它提前到需求調研時與客戶進行討論，則可以大大改善需求調研的效果。因為這時客戶對于將來的系統還沒有一個形象上的概念，或者有一個模糊的預想的概念需要表述、驗證、明晰化、完善化，以筆者的經驗，畫出用戶界面草圖與客戶進行討論，可以大大激發他們提供更為準確全面的需求。原來收集資料，描述業務，說明系統模型到了山窮水盡的時候，這種方法可以達到柳暗花明又一村的效果。
4詳細描述各項業務，以便讓所有客戶確認
盡可能全面詳細地調查并且描述原有系統和用戶希望將來系統具有的各項業務的流程，并將這些業務流程文檔化后與客戶進行討論，對描述錯誤或不準確不精確的進行修改，最終讓客戶進行確認。從近年來開發的軟件看，對業務處理過程了解的完整性和準確性非常重要。雖然對數據來說都是SIDUT(查增刪改傳)，但具體業務都是分為若干步驟，每個步驟都有其業務名稱，同一步驟可能對多個數據集進行不同操作，需要調查了解清楚才能設計出適合用戶業務特點和習慣的軟件，使開發出來的軟件更受歡迎。當然在進行軟件概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務節點工作作為獨立的對象，充分考慮他們與其他各種業務對象的接口，在流程之間通過業務對象的相互調用實現其業務流程，這樣，在業務流程發生有限的變化時，就能夠比較方便地修改系統程序而實現新的需求。
對于各項業務的調查可以通過對以下資料的收集整理分析來完成，這些資料來自各種各樣的項目用戶方干系人:遵循的標準、組織發放的工作手冊、作業流程、有關業務的上級通知、有關業務的辦事指南、辦理業務時需要填寫的登記表、各種相關的統計報表及通過其他途徑收集的類似系統的介紹、技術資料等等。
5對項目用戶方干系人的愿望進行平衡
不同的項目用戶方干系人其愿望和追求的目標往往相差甚遠，因此對項目用戶方干系人的愿望進行平衡可能是非常重要而又相當困難的事情。例如:我曾在參與的某醫院計算機管理系統項目中，遇到醫院管理層希望能夠采集盡可能多的信息項以便對數據進行多種多樣的統計分析，同時為了對信息進行有效控制而增加一些審批流程;而門診、藥房等對外辦公的基層窗口則因為客流速度的壓力希望減少信息項的輸人量;甚至有些不良的基層部門由于害怕建立透明度高的信息系統會影響他們的利益而消極地應付，即所謂反需求;而客戶的客戶(就診的病人)則希望相關機構能夠簡化工作流程，加快辦事速度，增加診斷情況和就診費用的透明度;甚至項目組本身因為技術、資源、進度等原因，需要對一些功能進行優先級排序和取舍。雖然不是所有人的需求都是可以滿足的，特別是消極的反需求是不能接受的，但他們的需求都是應當考慮全面并進行平衡的。
如果不同的用戶方干系人有不一致的需求，那么必須決策出滿足哪一類用戶方干系人的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助于決定哪一個用戶類所占份額更大。如果系統分析人員提出的需求與開發者所想要開發的系統發生沖突時，通常由于系統分析人員作為客戶的人，市場需求具有更重的分量，但是，系統分析人員不能一味地遷就客戶需求。
不同的用戶方干系人可能都要求產品按照他們各自的喜好來設計。運用項目的業務目標來決定哪些是你最關心的客戶，非核心客戶的需求可以安排在下一個版本中開發。當開發者想像的產品與客戶需求沖突時，通常應該由客戶作出決策，然而，不要陷人“客戶總是對的”的陷阱中去，現實中，客戶并不總是對的。
6強調實現項目需求的層次遞進性
了解該系統或者該項目用戶所能夠提供的最小的工程費用。當預計經費不能支持時，應當考慮將項目分期實施。在系統上、技術上對用戶進行引導性建議，使用戶了解集成商所要進行的工作，了解集成商是為了幫助用戶實現他的需要、達到用戶的目的，而不僅僅是為了賺錢，用戶更了解集成商，也更了解自己的系統，有利于以后的項目合作、工程實施和系統維護。
分析用戶曾用系統模式、數據結構和庫模式，看是否保持、共用、轉換，這涉及保護用戶投資的問題。根據現在工作業務流情況確定現有的工作模式，還應兼顧將來可能會發生的變化、擴展、新規定，及與同國際接軌可能的帶來的變化。考查工程實施環境是否有保證，尤其是網絡工程，必須在需求調查時充分了解用戶領域的實施環境，當不具有實施環境時，要求進行配套設計和環境改造。
7編寫需求文擋和進行需求評審與其他項目小組成員協作完善系統需求
文檔資料是集成商重要的財富，貫穿于系統集成和項目開發的整個過程，其中包括法律文檔、技術文檔、資料文擋。文擋要求完整性、一致性、可修改性、可跟蹤性。
關鍵詞：軟件工程；需求分析與管理
中圖分類號：TP311文獻標識碼：A文章編號：1007-9599 (2010) 15-0000-01
The Requirements Analysis and Management of Software
Huang Degui
(Communications Information Branch,Zhanjiang Port(Group)Co.,Ltd.,Zhanjiang524019,China)
Abstract:In the process of software development requirements analysis and management,there are some problems.This paper analyzes the problems and issues reference for these recommendations and solutions.
Keywords:Software engineering;Requirements analysis and management
在軟件項目開發過程中，需求分析與管理十分重要。但在實際的軟件項目開發的需求分析與管理過程中存在一些問題，如果不重視這些問題，往往導致項目開發進度延期、超出項目預算甚至項目開發失敗。
在軟件工程理論中，需求分析是指構建一個新的系統或者完善現有系統時，確定系統的目標、范圍、功能需求和非功能性需求等方面所涉及的工作。
需求分析是軟件工程的一個關鍵過程，也是軟件項目開發的一個關鍵階段。軟件需求分析人員需要準確、清晰和形象的表達和描述用戶的真實需求。需求分析階段的工作是否準確和充分、提交的軟件需求說明書是否完善和規范、需求管理的方法是否正確將直接影響和決定整個項目開發是否能夠按照時間進度和在項目預算范圍內完成。
在項目開發過程中，經常出現如下情況：軟件需求分析人員描述的用戶需求不完整、用戶需求經常發生變化、軟件需求分析人員與系統設計人員的溝通障礙、開發人員邊做需求分析邊做開發、用戶需求管理混亂、缺少專業的需求分析與管理工具等。這些情況的出現使整個項目管理風險加大、系統代碼返工率高、項目團隊士氣日益低下和用戶對項目開發進度的抱怨越來越多，最終可能導致整個項目開發失敗。
軟件需求分析人員描述的用戶需求不完整主要原因：一種情況是沒有專職的軟件需求分析人員，兼職的軟件需求分析人員同時擔當該模塊的設計及開發，導致需求分析沒有真正從業務的角度來考慮，而是從技術實現的角度考慮。有的即使有專職的軟件需求分析人員，該軟件需求分析人員也不具備該行業的業務知識和經驗，對行業術語不了解，有的甚至聘用剛剛畢業的學生去做需求分析，導致整個需求分析不準確甚至出現偏差。另外一種情況是專職的軟件需求分析人員沒有系統的學習和掌握軟件需求分析的基本方法、原則和技巧，了解的業務需求不能準確直觀的表達和描述，編制的軟件需求說明書過于簡單和形式化，導致項目開發的其他人員不能很好的理解用戶需求，有的甚至要重新做軟件需求分析。
為詳細和準確的描述用戶需求，需要注意以下幾個方面：
首先需要由專職的人員擔任需求分析工作，而且軟件需求分析人員需要系統的學習和掌握需求分析的基本方法、原則和技巧。例如獲取業務需求常用的方法有用戶訪談、速記、談話錄音、會議紀要等；其中用戶訪談的要點包括確定訪談的時間、訪談的對象、設計用戶訪談計劃并提前發送給用戶等；速記要求軟件需求分析人員能夠快速準確的記錄用戶描述的業務需求和業務流程。談話錄音和會議紀要是為了更準確記錄用戶描述的業務需求，便于分析和理解用戶需求；軟件需求分析人員最好具備該行業的業務經驗和知識或者聘請該行業的業務專家指導，這樣有助于軟件需求分析人員準確分析和理解行業術語、行業業務需求和行業業務流程。
其次，描述的軟件需求說明書內容應該包括系統的目標、范圍、功能需求、非功能性需求和系統界面原型等方面。非功能性需求主要包括系統界面的可用性、易用性、操作便捷、時間效率高、出錯率低和操作系統需要的專業領域知識少等方面；系統界面原形是指使用專業界面原形工具（Axure等）或者直接使用開發工具（Visual Studio等）編制系統的初始用戶界面，便于軟件需求分析人員、系統設計人員和開發人員更直觀和形象的與用戶溝通和明確需求。非功能性需求和系統界面原形在需求分析階段非常重要，我們在項目開發過程中應該注重非功能性需求和系統界面原形。
最后，對于軟件需求分析人員編制的軟件需求說明書要做好需求驗證工作，參加需求驗證工作的成員應該包括項目組所有成員、該行業的業務專家和最終用戶。在需求驗證會議上提供的需求驗證材料應該簡單、清晰、直觀和明確，不能籠統的提供一些復雜的業務流程及繁瑣的文字說明。在需求驗證會議上可以通過情景模擬和系統界面原形的方式演示。情景模擬是根據不同業務角色模擬整個業務辦理的情況。系統界面原形能讓用戶切身感受到系統的界面效果，便于直觀、形象的溝通和交流業務細節和業務流程。
在項目開發過程中，用戶需求發生變化的情況經常出現。我們不能避免和逃避用戶需求變化情況的出現，但應該控制和管理用戶需求變化，應該有需求變更的流程、需求變更的團隊、需求變更的平臺、需求變更的影響分析以及固定的需求變更周期。對于用戶提出的需求變更，我們首先應該做好詳細的記錄，然后將需求變更的記錄通過需求變更的流程提交給需求變更團隊評估和確認，最終在需求變更的平臺中反映出來，同時要做好需求變更的影響分析報告并及時反饋給用戶。需要注意的是對于需求變更我們要有固定的需求變更周期，不能用戶有需求變更馬上要求項目團隊及時更改系統，這樣會加大項目管理的風險和影響項目團隊的士氣。
[關鍵詞] 需求分析 需求變更 需求控制
一、問題的提出
什么是需求分析?
要知道需求變更是什么,首先要知道什么是需求分析。
需求分析是指理解客戶需求,就軟件功能與客戶達成一致,估計軟件風險和評估項目成本代價,最終形成開發計劃的一個復雜過程。需求分析的成果形成需求說明書。
什么是需求變更?
根據軟件工程思想定義,需求說明書一般要經過論證,如果在需求說明書經過論證以后,需要在原有需求基礎上追加和補充新的需求,或對原有需求進行修改和削減,均屬于需求變更。
二、需求變更的原因及影響
1.需求變更原因
一方面是用戶:他們是項目需求的提出者。一個十分常見的現象是用戶提出需求以后,在軟件開發過程中用戶改變了需求,這只能迫使開發工作返工,丟棄一些無法修正的部分。無疑這會造成一定的損失,但又無法完全避免。要求用戶一次性把需求講清楚,并且不允許此后需求有任何變更,這是不現實的。只能盡量減少需求變更,降低它所造成的影響。
二是系統因素:在系統內部,如計算機硬件、系統軟件或數據的變更要求與其相適應。
三是外部環境因素:與軟件運行相關的工作制度或法規、政策的變更,或是業務要求變更導致的需求變更。
四是需求分析階段工作缺陷:需求調研、分析、定義和評審工作不夠充分,致使需求規格說明中隱含著問題,在開發過程中才有所發現。或者需求開發中開發人員與用戶溝通不夠充分,如未能如實獲得用戶的潛在需求等。
軟件需求一旦出現變更,它可能要涉及到一些相關的代碼和文檔的修改,為此要把這一變更通知到所有相關人員。提出需求變更有可能在開發的任何階段,并且隨著項目的進展,越晚的需求變更引起的損失越大。
2.需求變更給軟件的開發工作帶來的影響
需求變更對軟件開發的影響是多方面的,概括的看,包括以下三個方面:
(1)增加項目的人員、費用開支,影響開發進度。需求變意味著原先的需求調研、分析的結果與預期的軟件實現存在偏差,需要進行需求變更。這無疑要增加項目的人員、費用的開支,并對開發進度造成影響。更有甚者,如果變更頻繁,可能對項目造成較大影響,嚴重時可能直接導致項目的失敗。
(2)影響軟件質量。在一個復雜的軟件系統中,需求之間具有一定的聯系,相關需求可構成需求鏈。如果由于需求變更導致需求鏈的某些環節脫節,就可能引起一些難以察覺的錯誤。當需求變更沒能及時修改項目的設計、開發文檔時,這些錯誤一般難以被測試人員發現,將直接影響系統質量,嚴重時可導致系統崩潰。
(3)影響開發者與用戶之間的合作關系。需求變更的實施是用戶和開發者相互協作的過程。開發者和用戶在是否采用變更問題上常常產生分歧,如果沒有恰當處理,影響雙方的互信,從而影響項目開發進程。同時需求變更也會在項目開發人員之間產生分歧,影響合作關系。
三、采取的對策
1.首先是預防
盡量做好需求分析工作,以期減少需求變更的頻次,為此在需求分析階段著重處理好以下問題,力圖使需求分析的結果更接近目標。
(1)培養正確的需求意識。優秀軟件產品建立在優秀的需求基礎之上,而高質量的需求又來源于客戶與開發人員之間有效的交流與合作。因此,雙方的參與者都需要認識到:要想獲得成功,自己需要什么,合作方又需要什么。只有這樣,才能建立融洽的合作關系。因此,培養正確的需求意識是雙方都需要努力的,而開發人員在這個階段應該發揮更加積極主動的作用。
首先,需求分析人員應該接受一定的正規培訓,以提高與人溝通的能力、緩解矛盾的能力、善于傾聽和詢問的技巧,以及收集整理資料的能力等。在參與具體項目時,分析人員也應主動學習一些項目所涉及的具體應用領域的基本知識,以更好地理解用戶的需求。
其次,開發單位應該對那些不想花時間在需求分析上的用戶明確指出:如果用戶不能充分地支持并參與,項目很可能會失敗;開發單位還可以通過學習一些前車之鑒的真實案例警告用戶:低質量的需求分析可能導致嚴重的后果。通過對用戶代表和管理人員的培訓,使他們真正理解需求分析的重要性和忽略需求帶來的風險,并對計算機系統有一個大體的了解,這樣用戶才能夠主動地參與需求分析。
同時,正因為不可能一次就完全了解用戶的需求,而且在系統開發過程中還需要不斷地請用戶參與,因此與用戶的溝通是需要貫穿始終的。需求分析中所采取的一些策略可能會讓用戶覺得意外和難以接受。因此,需求分析人員需要對用戶解釋一些做法的必要性和合理性,以得到用戶最大的支持與合作。
(2)從業務需求入手。用戶認識到了需求分析的重要性,但可能仍然不知道從何處入手表達自己的需求。這時可以從業務需求入手,任何企業對自己的經營運作目標應該是比較清楚的,這樣的經營背景讓用戶不僅有話說,也讓開發者有章可循。需求分析不可以完全與它所處的背景相脫離,只有當系統真正置身于它的社會和組織環境中,它的需求才能清晰地反映出來。
(3)充分利用需求來源。有了以上需求背景,就比較容易做到有的放矢了。需求分析人員可以直接與系統未來的操作者探討他們希望有什么樣的軟件;觀察系統的潛在用戶當前的日常工作以獲取有價值的信息;系統的使用者可能有很多,可以將他們分類以簡化需求;最后一定要與真正的決定者達成協議:對于有沖突的需求如何權衡,對于直接用戶的眾多需求如何取舍等。
同時,用戶往往對計算機期望過高,認為計算機可以解決當前存在的所有問題,因此會提出很多的功能需求,并且希望在很短的時間內看到成效。但是,由于技術、人力等資源的限制,并不一定能夠在設定的時間期限內滿足用戶所有的期望,這時就應該盡早確定出交付的產品應具備的最重要功能,即設定需求的優先級。
在這個階段,可以采用UML中的用例圖幫助用戶和需求分析人員之間的交流。一個用例圖描述用戶可以用軟件產品執行的一個任務。它不是從軟件的性能和系統的行為方面出發,而是從用戶到底能夠用這個軟件產品干什么入手。這樣的方式用戶比較熟悉,容易溝通;而且不會在需求分析的一開始就陷入過于細節化的設計,也有助于避免分析人員添加一些與所需任務無關的自認為很好的功能。
(4)提供選擇方案。由于用戶對軟件系統缺乏經驗,或者由于用戶的運作機制還未完善,或者由于其他種種原因,用戶可能仍然不能對一些需求做出明確的說明,收集整理的需求中可能仍然存在一些不確定因素。這時可提出幾份比較詳細的方案。附帶不同做法的優點,供用戶選擇或者啟發用戶確定需求。
如果需求分析做得好,文檔清晰且又有客戶簽字,那么后期客戶提出的變更就超出了合同范圍,需要另外收費。這個時候,開發方一定要據理力爭,此時這并非要刻意賺取客戶的錢財,而是不能讓客戶養成經常變更的習慣,否則后患無窮。
2.分級管理客戶需求
軟件開發項目中,“客戶永遠是對的”和“客戶是上帝”并不完全的正確,因為在已經簽定的項目合同中,任何新需求的變更和增加除了影響項目的正常進行以外,還影響到了客戶的投入收益,所以有的時候項目經理反倒應該為客戶著想。
對于項目中的需求變更,可以實行分級管理,以達到對需求變更的控制。
一級需求變更是關鍵性的需求,這種需求如果不滿足,意味著整個項目不能正常交付使用,前期工作也會被全部否定。這個級別的需求是必須滿足的,否則就意味著否定自已的項目成員和成員的所有努力,所以定為“Urgent”。
二級需求變更是后續關鍵性需求,它不影響前面工作內容的交付,但不加以滿足,新的項目內容無法提交或繼續,所以是“Necessary”。一般新模塊關鍵性的基礎組件,屬于這個級別。
三級需求是后續重要的需求,如果不被滿足會令整體項目工作的價值下降,為了體現項目價值,也是開發人員自已的技術價值的證明,所以定為“Needed”。一般性的重大的有價值的全新模塊開發,屬于這個級別。
以上三個等級是應該實施的,但時間性上可以作優先級的排列。
四級需求是改良性需求,沒有滿足這類需求并不影響已有功能的使用,但如果實現了則會更好,定級為“Better”。界面和使用方式的需求,一般在這個檔次。
五級需求是可選性需求,更多的是一種設想,以及一種可能,通常只是客戶的的一種個人喜好而已,定級為“Maybe”。
對于四級需求,如果時間和資源條件都允許的話,不妨做下去。對于五級需求,正如對它的描述一樣做與不做是“Maybe”。
3.加強需求變更的控制
在需求分析階段工作完成后,需求變更仍可以會發生,因此就要加強對需求變更的控制,主要有以下原則:
(1)建立需求基線。需求基線是需求變更的依據。在開發過程中,需求確定并經過評審后(用戶參與評審),可以建立第一個需求基線。此后每次變更并經過評審后,都要重新確定新的需求基線。
(2)制訂簡單、有效的變更控制流程,并形成文檔。在建立了需求基線后提出的所有變更都必須遵循這個控制流程進行控制。同時,這個流程具有一定的普遍性,對以后的項目開發和其他項目都有借鑒作用。
(3)成立項目變更控制委員會(CCB)或相關職能的類似組織,負責裁定接受哪些變更。CCB由項目所涉及的多方人員共同組成,應該包括用戶方和開發方的決策人員在內。
(4)需求變更一定要先申請然后再評估,最后經過與變更大小相當級別的評審確認。
(5)需求變更后,受影響的軟件計劃、產品、活動都要進行相應的變更,以保持和更新的需求一致。
(6)妥善保存變更產生的相關文檔。
這六大原則看起來簡單,但真正實施起來有難度,還需要依據理論知識配合開發項目組的實際工作情況,在實踐中不斷摸索總結。
四、總結
軟件項目的需求變更是對軟件產品的質量、成本、工期帶來巨大的影響。通過預防性措施和加強需求變更的控制與管理,將需求變更的頻次大幅度降低,從而為軟件項目的順利實施打下堅實基礎。
參考文獻:
[1]王 莉 吳潔明:軟件項目中的需求變更管理的研究[J].計算機技術與發展,2007,17(1):120～121
[2]王 強:軟件開發項目中的需求變更管理[J].電腦知識與技術(學術交流),2007,(11)
隨著計算機技術的發展，我國逐漸在軟件工程理論中取得了很大的成就。對于軟件需求分析取得的結果也是軟件項目開發的重點，軟件開發項目的成本其實取決于軟件需求的分析。由此可見，提高軟件需求分析質量不僅能夠促進軟件項目的發展，更是提高計算機軟件技術的重要手段。本文就軟件需求分析的任務與要點進行分析，并針對存在的問題提出具體措施。
【關鍵詞】計算機技術 軟件技術 軟件需求分析 存在的問題
計算機技術與信息技術的飛速發展，不僅給人們的工作生活帶來了方便，更促進了經濟的發展，使得其被廣泛運用到各個行業中。計算機技術的發展帶來的不僅是硬件方面的技術提升，各種軟件也逐漸趨于多元化。隨著人們對于計算機軟件的需求越來越高，軟件產品的需求分析質量直接關系到軟件成品的質量。下文就軟件需求分析的任務和基本特點進行分析，就怎樣提高軟件需求分析質量展開討論。
1 軟件需求分析任務分析。
1.1 軟件工程概述
IEEE將軟件工程定義為能夠系統的、規范的、可度量化的工程方法運用到軟件開發、運行以及維護等全過程中去的方法。軟件工程由方法、工具以及過程三部分組成，所謂方法就是指完成軟件工程項目的一種技術手段，是支持整個軟件生命周期的手段。而軟件開發的方法必須遵循一定的方法和步驟，軟件開發模型是軟件開發過程的一種概括。現代軟件開發模型可以分為以軟件需求確定為基本條件的瀑布模型、處于軟件開發初期，卻只能提供基本去修采用的迭代式、漸進式開發模型以及以形式化開發方法為前提的變換模型三種類型。
1.2 軟件需求分析的任務
所謂軟件需求分析就是指客戶對目標軟件產品在功能、行為、性能以及設計約束上的期望，軟件需求分析就是對這些問題或者涉及到的信息、功能建立模型，將客戶的需求進一步精確化、完全化。軟件需求分析的主要任務就是借助當前系統的邏輯模型對目標系統進行邏輯模型建立，并解決需求的具體問題。
1.3 軟件需求分析的重要性
總的來說，軟件需求分析對軟件產品起著決定性的作用，軟件的開發必須滿足客戶的要求，客戶的要求必須由軟件分析來挖掘，并根據客戶的需求來完善軟件的性能、功能以及設計。此外，軟件需求分析更是對軟件的后期開發具有一定的引導作用，可以讓軟件項目人員明確好開發的方向并加以實施，通過合理的軟件需求分析，才能更好的將軟件的功能、性能總體概括出來成為具體的規格說明，為軟件開發指明方向。
2 提高軟件需求分析質量的控制要點分析
2.1 軟件開發成本的控制
軟件開發也是決定軟件開發質量的重要因素，包括管理成本、人力成本、設備成本以及環境等成本內容。在軟件開發的時間過程中，軟件開發項目的風險是產生需求變化最主要的原因。對于軟件需求者來說，軟件開發和需求分析是一個漫長的過程，如果超過了預期的時間，很可能帶來開發成本的上升。因此，為了控制軟件開發的成本，提高軟件成品的質量，則需要在軟件需求確定、人員正確分配的基礎上探索新的方法，創造新的標準化流程。
2.2 軟件需求分析的流程改造
盡管人們對軟件需求分析工作的重要性有所認識，但在這方面的研究還少。事實上，軟件需求分析可以分為軟件開發和軟件管理兩大環節，且都是為人服務的。所以軟件需求分析有三大重點要素，分別是界面、說明和函數關系。改變傳統的軟件工程理論生產順序，將驗收標準與操作使用手冊提前制定，這樣一來，既徹底明確了用戶和開發者之間的責任，使得軟件開發的目標更加明確，又能將需求分析與后續的開發階段進行分離，以減少用戶在開發過程中投入的人力、降低軟件開發對專業人員的依賴。更是為后期的外包創造了條件，且降低了對需求分析人員的高要求。
2.3 人員分配策略分析
實際上，人員分配策略對于軟件開發成本的影響非常明顯，高質量的人才對于成本的要求就越高，而合適的人員才能發揮最佳的作用后，有效降低開發成本，兩者是互相作用的。針對人員分配中存在的問題，加以改進，以確定更適應的需求方法，從需求分析階段起就應針對性的進行人員分配策略改造，在保證軟件開發質量的基礎下，降低總體開發成本。與此同時，按照現有的軟件需求來確定軟件工程理論進行軟件生產，最終交付合格的產品，不僅減少了需求分析的人力成本，更提高了軟件生產的效率。
3 結語
總的來說，軟件需求分析是軟件開發整個過程中非常重要的環節，完善的軟件需求分析不僅是降低軟件開發成本的重要措施，更是促進軟件產品獲得更大經濟收益的手段。顯然，提高軟件需求分析質量是順利進行軟件開發工作的必要策略。
參考文獻
[1]楊毅，楊杰.一種提高軟件需求分析質量的方法[J].計算機系統應用，2014（05）：16-20.
[2]王蘭. 提高軟件需求分析質量的探討[J]. 電腦知識與技術，2013，23：5270-5272.
[3]鄧蓉蓉.基于敏捷建模方法的軟件需求分析研究[D].武漢理工大學，2009.
[4]徐賽華. 軟件需求分析研究[J].吉林師范大學學報（自然科學版），2006（01）：104-105+110.
作者單位
在進行培訓需求分析預測以后，對培訓需求分析預測的情況進行整理和匯總，形成書面報告。
培訓需求分析報告不但作為某一培訓項目開發前的培訓需求分析預測工作的總結材料，而且還是企業總體培訓計劃制定前的調研報告。
一、培訓需求分析報告的基本內容
1、標題：
2、分析預測工作概況。此次培訓需求分析預測的組織領導、工作目的、起止時間、接觸的組織和人員（包含數量）、采用的方法、工具等等。
3、分析預測的主要內容：
（1）企業的情況分析。企業面臨的外部背景、市場競爭的形勢、本行業的發展狀況；企業內部面臨的問題和改革情況，做出較為全面細致的分析。分析盡量與培訓需求分析預測的相關性強一些。
（2）企業員工基本素質狀況分析。對于企業員工素質的分析，應根據崗位任職資格和能力要求，結合企業生產、經營的實際需要，從員工隊伍的年齡、文化結構、管理人員與操作人員比例、技術登記結構、崗位能力勝任程度等方面入手，重點分析出問題和差距。
（4）對培訓的認知程度分析。領導對培訓的重視程度、各部門的配合程度、員工的認可和需求的程度。
（5）培訓資源條件分析。包括企業內外可利用的教師、教材、設施、工具和企業培訓經費支持情況等。
4、分析預測的具體成果：
通過對以上幾個方面內容的分析，應當主要回答以下問題：
（1）在制約企業發展的諸多因素中，哪些是因員工素質和能力方面的差距所致？其中哪些是通過培訓能夠解決的差距。
（2）解決以上差距需要開發哪些培訓項目？其中哪些培訓項目是最緊迫的？
（3）每一培訓項目又要具體說明以下問題：
①為什么進行培訓？（培訓目的）
②誰需要培訓（培訓對象及其目標人群）
③培訓的深度和廣度（培訓的目標）
④培訓什么（培訓內容）
⑤怎樣培訓好（培訓方式、時間、考核方式）
（4）企業，特別是企業領導對培訓的態度。
（5）企業具有的培訓資源
（6）可利用的外部資源
（7）項目運行可能出現的障礙和問題
5、其他相關建議和說明。
6、報告撰寫時間及執筆人、負責人等。
二、撰寫培訓需求分析報告應注意哪些問題
1、報告中各項情況的分析和說明，必須有出處、有依據，不能主觀臆造。
2、報告內容要全面，基本上涵蓋以上6項內容。
【關鍵詞】軟件工程 軟件需求 需求工程 需求開發 需求管理
【中圖分類號】TP311.5 【文獻標識碼】A 【文章編號】2095-3089（2015）06-0181-02
軟件工程師所需解決的問題往往十分復雜，了解問題的性質可能是非常困難的，尤其當系統是全新的時候。
1.綜述
軟件工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟件工程第一個也是很重要的一個階段，這個階段的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。本文以企業人事信息管理系統為例詳細介紹了需求工程的構成和進行方法。
2.需求的標準
定義需求標準有所不同，但在思想上是相同的，都是為了保證項目的順利進行。一般的標準為：明確（Clear）、完整（Complete）、一致（Consistent）、可測試（Testable），還有可跟蹤、可修改等等。
明確：目前大多數的需求分析采用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性。所以對需求分析中采用的語言應該做某些限制盡量采用主語+動作的簡單表達方式。還有，不要使用計算機術語。需求分析最重要的是和用戶溝通，可是用戶多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成用戶理解上的困難。
完整：需求的完整性是非常非常重要的，要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各方各面，貫穿了整個過程，從最初的計劃制定到最后的需求評審。
一致：用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。嚴格的遵守不同層次間的一致性關系，就可以保證最后開發出來的軟件系統不會偏離最初的實現目標。
可測試：需求的幾項標準都是為了保證需求的可測試性，只有系統的所有需求是可以被測試的，才能夠保證軟件始終圍繞著用戶的需要，保證軟件系統是成功的。
需求工程分為了需求開發和需求管理兩個階段：下面就以這兩個階段說明：
3.需求開發
需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。以下列出和講解分析常規的步驟，當然應按照項目的大小和特點等實際情況我們應該自己確定合適的步驟。
3.1需求獲取：
這是該階段的一個最重要的任務。以下為獲取用戶需求需要執行的活動。
了解客戶方的所有用戶類型以及潛在的類型。然后，根據他們的要求來確定系統的整體目標和系統的工作范圍。
對用戶進行訪談和調研。交流的方式可以是會議、電話、電子郵件、小組討論、模擬演示等不同形式。需要注意的是，每一次交流一定要有記錄，對于交流的結果還可以進行分類，便于后續的分析活動。例如，可以將需求細分為功能需求、非功能需求（如響應時間、平均無故障工作時間、自動恢復時間等）、環境限制、設計約束等類型。
需求分析人員對收集到的用戶需求做進一步的分析和整理。
需求分析人員將調研的用戶需求以適當的方式呈交給用戶方和開發方的相關人員。大家共同確認需求分析人員所提交的結果是否真實地反映了用戶的意圖。
3.2需求分析
需求分析是軟件定義時期中很重要的一個階段，它的基本任務是準確地回答“系統必須做什么？”這個問題。在很多情形下，分析用戶需求是與獲取用戶需求并行的，主要通過建立模型的方式來描述用戶的需求，為客戶、用戶、開發方等不同參與方提供一個交流的渠道。這些模型是對需求的抽象，以可視化的方式提供一個易于溝通的橋梁。用戶需求的分析與獲取用戶需求有著相似的步驟，區別在于分析用戶需求時使用模型來描述，以獲取用戶更明確的需求。
用于需求建模的方法有很多種，最常用的包括數據流圖（DFD）、實體關系圖（ERD）和用例圖（Use Case）三種方式。DFD作為結構化系統分析與設計的主要方法，已經得到了廣泛的應用，DFD尤其適用于MIS系統的表述。DFD使用四種基本元素來描述系統的行為，過程、實體、數據流和數據存儲。DFD方法直觀易懂，使用者可以方便地得到系統的邏輯模型和物理模型，但是從DFD圖中無法判斷活動的時序關系。
ERD方法用于描述系統實體間的對應關系，需求分析階段使用ERD描述系統中實體的邏輯關系，在設計階段則使用ERD描述物理表之間的關系。需求分析階段使用ERD來描述現實世界中的對象。ERD只關注系統中數據間的關系，而缺乏對系統功能的描述。如果將ERD與DFD兩種方法相結合，則可以更準確地描述系統的需求。
3.3編寫規格說明書
項目視圖和范圍文檔包含了業務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使用實例派生出的功能需求文檔，還要編寫產品的非功能需求文檔，包括質量屬性和外部接口需求。軟件需求規格說明闡述一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件，它不僅是系統測試和用戶文檔的基礎，也是所有子系列項目規劃、設計和編碼的基礎。它應該盡可能完整地描述系統預期的外部行為和用戶可視化行為。
采用軟件需求規格說明模版：采用需求規格說明書模板在你的組織中要為編寫軟件需求文檔定義一種標準模板。該模板為記錄功能需求和各種其它與需求相關的重要信息提供了統一的結構。注意，其目的并非是創建一種全新的模板，而是采用一種已有的且可滿足項目需要并適合項目特點的模板。
3.4需求驗證
需求分析階段的工作結果是開發軟件系統的重要基礎，大量統計數字表明，軟件系統中15%的錯誤起源于錯誤的需求。為了提高軟件質量，確保軟件開發成功，降低軟件開發成本，一旦對目標系統提出一組要求之后，必須嚴格驗證這些需求的正確性。一般說來，要按以下步驟進行需求驗證：
1）審查需求文檔；2）依據需求編寫測試用例；3）編寫用戶手冊；4）確定合格的標準。
4.需求管理
需求開發的結果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規格說明及相關分析模型。經評審批準，這些文檔就定義了開發工作的需求基線。這個基線在客戶和開發人員之間就構筑了計劃產品功能需求和非功能需求的一個約定。需求約定是需求開發和需求管理之間的橋梁，需求管理包括在工程進展過程中維持需求約定集成性和精確性的所有活動。
5.企業人事管理系統
5.1企業人事管理系統概述
企業人事管理系統是針對企業人事方面的大量業務處理工作而開發的管理軟件。根據用戶的要求，實現人員基本情況管理、工資管理、和考勤管理等幾個方面的功能。用戶通過輸入工資、考勤、職工履歷等基本信息，由系統自行生成相應的統計數據及各類統計報表以供用戶查詢、打印。
5.2系統功能分析
系統開發的總體任務是實現企業人事信息關系的系統化、規范化和自動化。
系統功能分析是在系統開發的總體任務的基礎上完成的。經過按照以上分析過程進行分析，分析出企業人事信息管理需要完成功能。
6.總結
以上詳細介紹了軟件需求分析過程。軟件工程中包含需求、設計、編碼和測試四個階段，其中需求工程是軟件工程第一個也是很重要的一個階段，要想做好一個項目，必須先做好需求分析，需求工程分為了需求開發和需求管理兩個階段：需求開發又分為需求獲取、需求分析、編寫規格說明書和需求驗證。需求管理就是對需求變更控制的過程。通過介紹企業人事信息管理系統的需求分析階段，更好地說明了需求分析過程。
關鍵詞：軟件項目；需求管理；意識；溝通
隨著計算機和信息技術的發展，軟件的需求越來越復雜，規模越來越大，而且隨著軟件企業的日益壯大，軟件需求管理已成為日常軟件開發中不可或缺的組成部分。在軟件項目的開發過程中，需求管理貫穿了軟件項目的整個生命周期，是軟件項目管理中一項十分重要的工作，據調查顯示在許多失敗的軟件項目中，由于需求原因而導致的約占到四至六成，因此，需求管理做得好壞直接影響到軟件質量的高低，甚至軟件項目的成功與否。
需求管理是每個軟件項目開發的基礎，是一種用于查找、記錄、組織和跟蹤系統需求變更的系統化方法，可用于獲取、組織和記錄系統需求并使客戶和項目團隊在系統需求變更上保持一致。目前，軟件工程仍然是一種新興的工程領域，它遠遠沒有其他傳統工程領域那么規范，其開發過程缺乏成熟的理論和統一的標準。因此，軟件需求管理具有相當的復雜性和特殊性，當然仍存在著各種問題，下面將針對需求管理的相關問題進行探討。
1.意識問題
在許多軟件企業中，從事需求管理的人員大多是技術骨干，在需求管理方面的培訓較少或不夠系統，未能掌握需求管理的常用工具及方法，在實際的需求分析中主要依靠個人現有知識經驗，需求管理隨意性和盲目性較大。其中部分需求管理人員都沒有意識到自己是從事需求管理的角色，而是局限于軟件技術的分析，造成需求管理計劃不周、任務不均、安排不明、資源浪費。
目前軟件企業中，很少有專門從事需求管理的專業人員，被任命為需求管理的人員往往都是具體負責軟件開發的技術人員，而這些技術人員在溝通、技能以及專業知識方面與專業軟件需求管理人員仍有很大的差距，因此造成在軟件開發時并不清楚究竟該做什么，但卻在一直忙碌不停地開發。這個現象，已經成為國內軟件業的頑疾。
需求的復雜性以及不確定因素的存在，加之意識上的不重視，使需求管理人員對需求分析認識不足，認為需求分析做得再好也不如實際變化快，導致做需求分析走過場而留于形式，造成需求分析與實際情況脫節，無法獲知真實有效的需求。因此，加強需求管理人員意識的培養，提高需求分析的技能是更好地做好需求管理工作的基礎。
2.溝通問題
在軟件需求調研過程中，很多客戶都不能正確表達自身的需求，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認為只要簡單的說說自己意圖就是把需求說明白了，而對業務的規則、工作流程卻談及甚少，也講不清楚。更有甚者，在調研過程中參與度不高，對需求的確認不夠積極，提出的要求也較隨意；或者多個用戶代表各說各話，昨是今非但又要求項目盡早交付。這些情況往往會增加需求調研的工作難度，分析人員需要花費更多的時間和精力與用戶盡心溝通，幫助他們梳理思路，搞清用戶的真實需求。
客戶溝通是需求管理中的劑，在需求管理過程中與客戶的溝通很重要，因為它直接決定著最終軟件產品是否滿足客戶的要求，在很大程度上決定著項目的成敗。在溝通時，雙方對需求的認識要一致，不能模棱兩可。
建立良好的溝通環境和氛圍。需求管理人員與用客戶溝通的程度關系到需求分析的質量，因此建立一個良好的溝通氛圍、處理好需求管理人員與客戶之間的關系顯得尤其重要。通常情況下，客戶作為投資方會有一些心理優勢，希望他們的意見得到足夠的重視，分析人員應該充分的認識到這一點，做好心理準備，盡量避免與他們發生爭執，因為我們的目的是幫助用戶說出他們的最終需要。
在溝通時需求管理人員應注意以下幾個方面：
（1）和具體業務執行者的溝通。要盡量深入他們的實際工作，了解軟件項目需要解決的實際問題的關鍵點。做一個優秀的傾聽者，以最快的速度適應客戶的語言風格，理解他們要表達的意思。以及使用不同的溝通手段和溝通工具來和客戶溝通，比如片界面或者文檔規格說明書等等，爭權把軟件開發語言和客戶語言能夠很好的在表述上達到一致，切忌自以為是，答非所問。
（2）和決策者的溝通。項目產品基本定型和相對完整的產品需求，需要經過客戶決策者的認可，以確認項目建設思路和方向沒有偏離，利于投入更多的資源來細化和付諸開發實現。和客戶決策者要定期匯報溝通項目進展，及時修正項目目標偏離，爭權客戶更大力度的協調配合，裁定項目范圍需求便捷，貫穿始終。
3.管理問題
需求管理工作應該是需求全生命周期的管理，從用戶原始需求的提出，到最終形成軟件產品后客戶對需求實現情況的驗證以形成閉環流程。因此我們需要跟蹤和了解到需求狀態的演變過程。大型的項目軟件生命周期模型較為復雜，一個需求的實現會經過用戶需求，軟件需求，總體設計，詳細設計，開發和單元測試，集成測試，系統測試和驗收測試多個環節，在這個過程中需要建立需求追蹤以確認需求和中間階段產生的工作產品的一致性。
變更管理是需求管理的另外一個重點，對于軟件項目來的需求而言，客戶會經常性地提出需求變更要求，主要原因有：客戶對系統功能理解的分歧。在前期需求調研時，需求分析人員的知識、業務水平與客戶的溝通交流情況等因素會造出雙方在功能理解上的分歧，隨著軟件項目開發的進行，這種分歧會導致需求的變更；客戶業務邏輯發生改變。客戶在競爭激烈的市場環境中隨著市場發展情況的變化而調整自己的業務邏輯，從而對軟件項目需求提出新的變更要求。各種原因導致需求的不斷變更，使其始終困擾著軟件需求管理人員。
為此就要引進規范而又專業的管理機制，使得需求管理更加規范。需求管理的重要性則體現在項目計劃的嚴肅性和可執行性，以保證項目目標的實現。通過引入了需求變更管理后，使軟件項目需求文檔成為大家都共同承諾和作為依據參考的文檔，這個文檔需要在設計，開發，測試等多種角色之間充分傳遞和共享。另外通過需求管理工作，使每個人意識到變更對項目的影響和變更的代價，從而促進需求開發質量的提高。
對軟件需求管理中存在的常見問題進行了淺顯的分析，軟件需求管理涵蓋了意識、技術和管理等多方面的知識，對軟件項目開發的成敗有著 非常重要的意義，它是一個軟件項目成功與否的關鍵因素之一。在軟件開發過程中，要樹立既要注重技術，又要注重管理的意識，努力提高需求管理的水平。
參考文獻：
[1]吳艷艷，周長倫﹒軟件項目管理中的需求管理[J]﹒信息技術與信息化研究與探討，2008.
[2]陳俊霞，王衛東﹒軟件項目管理的若干問題探討[J]﹒現代計算機，1999.
【關鍵詞】電子政務軟件 信息系統 軟件項目
1 電子政務信息系統的特殊性
受到廣泛認可的聯合國經濟社會理事會的對電子政務進行定義，即政府為了提高公共服務效率、增強政府的透明度、改善公共管理的質量，利用信息通信技術（ICTs）手段應用組織公共管理的方式，建立良好的政府之間、政府與社會、社區以及政府與公民之間的關系，提高公共服務的質量，贏得廣泛的社會參與度。這在一定程度上說明電子政務系統涉及的用戶角色多，情況復雜。需要處理政府、社會、公民三者之間關系，不用用戶立場不同對系統的要求不同，這就要求對所用用戶的需求進行收集匯總，然后進行整理確定最終的需求。
2 軟件需求分析的過程
軟件需求分析過程包括四個環節。可以分為系統可行性研究，需求導出和分析，需求描述，需求有效性驗證。軟件系統的需求通常分為功能需求和非功能需求。
（1）功能需求包括對系統應該提供的服務、如何對特殊收入做出反應，以及系統在特定條件下的行為的描述。在某些情況下，功能需求可能還需明確聲明系統不應該做什么。
（2）非功能需求對系統提供的服務或功能給出的約束。包括時間約束、開發過程的約束和所受到的標準的約束。非功能需求經常適用于整個系統而不是個別的系統功能或服務。
3 電子政務軟件需求分析方法
軟件需求的方法很多，通常包括：面談、問卷調查、小組討論、情景串聯、參與觀察業務流程、用例等。選擇那種方法需要根據具體應用實際情況而定，綜合考慮選擇哪些方法對系統開發最為有效，但不能盲目套用。下面將重點闡述在電子政務軟件需求中用例分析的方法和快速原型分析方法。
3.1 用例分析方法
用例是一種需求發現技術，這種技術起先是在面向對象方法中被引入的。現在已經成為統一建模語言的一個基本特征。一個最簡單的形式是，一個用例識別在一個交互中所參與的所有角色并命名該交互類型。然后還會附加一些描述系統交互的額外信息。這些信息可能是文本描述或是一個或多個圖形化模型，例如UML序列圖或狀態圖。
用例通過一個高層用例圖記錄下來。用例的集合代表所有將會在系統需求中出現的交互。過程中的角色可能是人，也可能是其他系統，用人形圖標來表示。每一個交互類用一個命名的橢圓來表示。用例和交互類之間用線相連。也可以選擇把箭頭添加在連線一端，代表交互的開始方向。
在電子政務軟件的需求收集過程中，傳統的面談、問卷調查過程，由于客戶的計算機水平、對需求的理解、表達程度都參差不齊，有些客戶只有朦朧的感覺，當然說不清楚具體的需求，有些客戶心里非常清楚想要什么但卻說不明白等多種原因，引起分析人員理解錯誤。特別是因為分析人員對于政府最初運作流程不熟悉，在與具體使用客戶交流時就會引起某些誤解，語言上表達一樣但實際并不是一致。采用用例的圖形表達方式，就能夠在一定程度上解決對文字描述的理解歧義。用例圖采用圖形的方式描述系統的交互，比較直觀，能夠讓用戶與分析人員交流更明確更順暢。
3.2 快速原型分析方法
在傳統的軟件工程方法學中，一貫強調的是自上而下的分階段開發方式，在各個階段具體開發之前必須對所開發項目需求進行嚴格意義上的定義。具體實踐表明，在系統未建立起來之前很難僅僅依靠分析就確定出一套完整、有效的需求應用，并且這樣預先定義的需求也無法適應用戶需求的不斷變化。因此，快速原型分析方法應運而生，其自頂而下的開發模式是目前應用十分廣泛的開發模式。
快速原型模型在功能上等價于最終系統的一個子集。瀑布模型的缺點就在于不夠直觀，快速原型法就解決了這個問題。一般來說，根據客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。在得到用戶的需求之后，原型將被拋棄。因為原型開發的速度很快，設計方面是幾乎沒有考慮的，如果保留原型的話，在隨后的開發中會為此付出極大的代價。在快速原型模型中，原型最重要的目的是為了確定用戶的真正需求。從某種程度上，可以將快速原型理解為需求分析的一種更直觀的方式，也是業界比較認可和取得良好效果的一種方式。
快速原型分析的顯著特點是增進軟件分析人員與客戶對需求的理解，將比較模糊的且具有不確定性的軟件需求明確化，同時快速原型分析方法有利于更好發掘客戶的潛在需求，將盡量降低需求變更頻率，有效地控制軟件的開發成本，保證軟件項目最終取得成功。
4 結束語
電子政務信息系統需要處理的數據越來越復雜，對其進行的需求分析也變得越來越重要。在電子政務信息系統的開發過程中，如何使軟件系統需求過程更加合理有效，是提高電子政務信息系統質量的關鍵。本文通過對電子政務信息系統中軟件需求分析的詳細闡述，來說明軟件需求分析是軟件設計實現的基礎，直接關系整個軟件項目成敗。如果能科學地進行需求分析，采用合適的技術及方法避免可能引起需求分析缺陷的問題，獲取用戶完整的需求規格說明書，能夠為后面的設計階段打下良好的基礎。
參考文獻
[1]阮俊杰.軟件開發方法與管理教程[M].北京：海洋出版社，2003.
關鍵詞：系統集成；項目管理；問題；對策
中圖分類號： N945 文獻標識碼： A 文章編號：
一、大型信息系統集成項目管理問題
（一）項目范圍管理欠缺。缺少正確的項目定義和范圍核實是導致項目失敗的主要因素。因此，項目管理最重要也是最難做的一項工作就是確定項目的范圍。
范圍是指項目的任務是什么，包含兩方面的含義：一是產品范圍，即產品或服務所包含的特征或功能；二是項目范圍，即為交付具有規定特征和功能的產品或服務所必須完成的工作。簡單地說，就是產品范圍決定項目范圍。目前，在大型信息系統集成項目范圍管理中主要存在兩方面的問題：
1、項目范圍界定不清。引起這個問題的主要根源是項目需求分析不完整。造成需求分析不完整的具體原因如下：
（1）項目初期客戶對自身需求不清晰。在這個階段，客戶一般會要求項目承包方替他們設想需求。這種情況下的需求分析存在一定的主觀性，并不能完全表達用戶真正的需要，可能為項目未來實施埋下隱患。
（2）項目實施過程中客戶需求自身發生變動。隨著項目進展深入，客戶方人員對信息系統的認識會逐步加深，以及自身業務水平的提高，他們會在項目實施的不同階段對項目的需求提出新的要求和需求變更。
（3）需求分析人員和客戶對需求的理解有誤。由于雙方人員各自的專業背景和行業背景不同，對事物的認識角度不同，往往會發生對同一個問題的理解產生一定程度的偏差。
（4）缺少客戶業務部門參與。一般來說，系統集成項目是由客戶的業務部門提出具體需求，由信息技術管理部門組織實施，最終供業務部門使用。業務部門參與不足，就可能產生需求分析偏差；業務部門不理解、不認可等問題。
2、項目范圍變更失控。在項目范圍管理過程中，出現變更失控的原因有以下幾個：
（1）項目團隊成員對項目變更管理不夠重視，直接導致當范圍變化發生的時候不能及時地反饋給項目經理。
（2）項目范圍蔓延的問題。是指一個項目接受了很多小的變化，當這些小的變化都聚合到一起的時候，項目團隊才意識到項目范圍已發生重大變更。
（3）項目的變更控制缺少統一的流程和標準。這個問題會直接導致項目變更管理自身的失控，無法起到有效控制項目實施的作用。
（二）項目團隊疏于管理。一般來說，參與大型系統集成項目的人員中并不缺少精通技術和業務的人才，但能夠有效調動、合理使用這些人員，共同實現項目目標并不是一件容易的事情。實際上不良的項目團隊管理直接導致了項目的最終失敗。究其根源在于“重視技術，疏于管理”，這主要體現在溝通不良、合作意識差、分工不夠細致和項目成員流動等方面。
（三）項目風險管理落后。目前，雖然風險管理已經在國內大型信息系統集成項目的管理中開始采用，但是因為在具體實踐中還存在的一些問題，阻礙了項目風險管理在大型信息系統集成項目中的合理應用。
1、缺乏風險意識。缺乏項目風險意識，對項目風險管理的必要性和重要性缺乏足夠的認識，這正是影響風險管理合理運用的主要問題。
2、風險識別的偏差。進行有效的項目風險管理，必然要從風險識別開始，如果這個階段的工作不到位，勢必會影響到后續的風險分析評估，進而造成應對措施失誤等問題。
3、風險評估客觀性差。風險評估也可稱為風險量化，是指確定風險發生的概率與后果。目前國內項目風險評估的方法大部分采用專家預測法。這種專家主觀性判斷得到的數據可能存在不真實、不可靠的問題，這就可能給后面的決策埋下隱患。
二、大型信息系統集成項目管理策略
（一）項目范圍管理
1、真實需求的獲取。最終用戶真實需求的獲取就是需求分析的過程，它是一個項目的基石。一般來說，需求分析的過程分為四個階段：挖掘需求、引導需求、證實需求和確認需求。
（1）挖掘需求。在收集用戶零散的信息后，在了解用戶業務流程以及結合專業知識的基礎上，找出這些信息之間的邏輯關系并且用常識性的語言表述出來。
（2）引導需求。挖掘需求階段后，需要與用戶溝通，引導用戶，使雙方對需求的理解達到一致。
（3）證實需求。在雙方對需求理解一致的基礎上，形成一份完整、可操作的、真實表達用戶需要的需求分析說明書。
（4）確認需求。這一階段的目的就是通過證實需求階段收集的信息，確認用戶的真實需要，審核完成需求分析說明書。
2、利用 WBS 分解項目。工作分解結構（WBS）是指把主要可交付成果分成較小的、便于管理的組成部分，直到可交付成果定義明晰到足以支持各項項目活動（計劃、實施、控制和收尾）的制定。
使用WBS的最大優點是可以監控以及預測成本、進度等不同的項目信息，并且給所有的項目參與者提供了一個均可與之做對比的一致基準。WBS有以下四個原則：
（1）“四十小時原則”。四十小時原則是指處于WBS 層次最末端的工作可以在七個工作日內完成，這樣可以把任務執行檢查的周期控制在一個星期內，從而大幅度地提高了任務分解的可靠性和任務執行的及時性。
（2）最末端的工作可以由某個具體的人或者某個團隊完成。最末端的工作需要明確責任人或者資源。如果某個任務雖然可以在一周內完成，但是執行該任務的資源卻大于一個人，則應該按照每個人的任務再進行分解，直到明確每個人或者每個團隊具體的任務和職責。
（3）最末端的工作不應有較高的風險。例如，解決某個技術難題的任務，或許這項任務可以在一周內完成，但是在執行該任務過程中存在較大的風險，能否解決不確定因素過多，因此需要將該任務按照解決問題的步驟進一步分解，通過進一步的細化，很大程度上降低了該任務的風險。
3、范圍的驗證。項目范圍驗證不應該僅僅發生在項目結項的時候，這樣做往往會流于形式。比較理想的做法是在項目各個階段，至少是里程碑的階段，由項目需求分析小組的成員（特別是用戶方代表）、項目經理、該階段可交付成果的負責人組成評估小組，由階段工作成果的負責人進行宣講，評估小組一起進行評審和驗證。
（二）項目團隊管理
1、項目經理的選擇。對于大型項目的項目經理要具備以下能力：有管理經驗，是一個精明而且講究實際的管理者；擁有成熟的個性，具有個人魅力；具備良好的人際關系，尤其是能夠處理好與項目各干系方的關系；有一定的技術背景。
2、項目小組的構成。一個大型信息系統集成項目團隊可以分為需求分析組、設計組、開發組、商務組、實施組等若干個項目組，每個項目組還可以細分成若干個子項目小組。
根據大型信息系統集成項目的特點，在構建每個項目小組時，應考慮以下兩點因素：（1）適度地安排不同的人員去做不同的工作，做到人盡其能；（2）加強項目人才梯隊培養，在人員發生變動時可以“無縫”交接。
3、項目團隊的成長。借用著名心理學家 B.W.塔克曼的團隊管理理論，項目團隊的成長一般需要經過四個階段，即形成階段：促使個體成員轉變成項目團隊成員；震蕩階段：團隊成員之間的相互磨合；正規階段：形成團隊，形成合力；表現階段：積極工作，向目標沖刺。根據項目實際進展情況，其他階段的激勵方式也可以同時被很好地采用。當然，足夠的物質激勵是不可缺少的最有效的激勵方式。實質上，“以人為本”的理念要貫穿于從項目團隊組建開始的全部工作中，以項目團隊成員為本，從項目團隊成員的角度上去思考問題，可以很快地增強團隊凝聚力和團隊效率。
（三）持續改進的項目風險管理方法。持續改進思想主要針對：一是對可能會出現風險的部分持續評估；二是決定哪類風險最主要，并且進行重要程度描述；三是實施處理風險的策略。持續改進的風險管理具有以下優點：能夠在問題發生前預防、改進產品質量，使得資源更好地被利用、增進團隊合作，為投資決策設立預期目標，并且提供解決方案。
參考文獻：
[1] 左美云. 信息系統項目管理. 北京：清華大學出版社，2008.
[2]劉曉紅，徐玖平. 項目風險管理. 北京：經濟管理出版社，2008.
金融業的發展與計算機軟件工程之間存在著高度融合，作為金融業的重要組成，郵政銀行與市場上的工商企業存在一定的差別，是一個特殊企業，因此，在軟件工程項目的要求及開發原則上具有獨特的要求。郵政銀行信息工程項目建設要注重質量管理、成本管理及風險管理，保障郵政銀行借助軟件工程項目，達到預期的經營目標。
1郵政儲蓄銀行軟工工程項目的基本目標及原則
郵政銀行的信息系統要采用科學先進的項目設計思路和項目架構，集中處理郵政銀行的資金儲蓄及現金匯兌業務，信息系統要具備可操作性、高性能、伸縮性強的特點。此外，除了能夠有效處理銀行業務需求外，在系統的擴展性及維保的便捷性上，也要具備相當大的彈性空間，以促進郵政銀行發展目標的達成。郵政銀行軟件信息系統項目要遵循先進性、安全性、前瞻性、可擴展性、可維護性及經濟適用性等原則，強化信息系統項目的質量。
2郵政儲蓄銀行軟工工程項目的開發管理過程
（1）需求分析。根據用戶準確要求，找準市場定位，是進行需求分析的基礎。需求分析的目的，在于保證軟件開發的準確到位，以節約時間和成本，提高系統利用率。需求分析的主要內容為需求的符合程度、項目系統的安全性、穩定性、可擴展性及容錯性等，在此基礎上形成完整一致、可控性強的文檔，以滿足郵政銀行的各項業務需求。由于軟件用戶在軟件的功能性上有著一個較為清晰化的框架，對軟件要處理哪些數據有著明確的需求，因此，在對軟件投入研發前，要和用戶及時交流溝通，以便軟件在使用中達到高效完美的最佳效果[1]。（2）概要設計需求分析階段，只是根據用戶需求大體劃分出目標系統的類型，并沒有設計到具體設計思路，如使用何種編程語言，運用哪個操作平臺等，而概要設計階段，就是著重對這些要素進行甄選[2]。要實現概要設計與需求分析的有效銜接，根據具體情況選擇合適的開發方式，需求變化幅度較小的，選擇采用瀑布式開發模型，以形成較完整的分析文檔，需求變化幅度較大的，采用更穩妥的設計方式，以便及時返回上一級進行修繕。郵政銀行信息系統項目設計，要依據設計文檔整體要求，對整體系統項目及各個子系統項目加以編碼，形成開發文檔。（3）細致設計。細致設計階段可以采用成熟度模型（CMM），這一模型涵蓋了軟件工程，硬件工程和系統工程三個環節，并細分了各自環節的等級，各等級中又有對應的過程域。細致設計環節著重對分析模型進行詳細校驗修改，因為編程環境的改變，或為了細致定義軟件界面，需要對相關類結構進行修改。詳細設計的過程主要是根據概要設計的脈絡，對軟件體系結構作細化處理，設計各軟件單元外部接口、輸入輸出、算法、流程邏輯、占用資源比、性能表現、單元調試與測試等方面，從而完成對整體數據庫的詳細設計。通過對這些環節的細致設計，對軟件的系統性能，邏輯集中系統是否健壯、安全進行分析驗證，以滿足郵政業務開展需求。（4）編碼單元測試和聯合測試。軟件開發人員以特定軟件開發工具為基礎，通過操作每個軟件單元及數據庫定義的形式，在相應語言開發工具的配合下，正確研發，調測系統，從而更貼合軟件用戶需求。郵政銀行信息系統項目要借助工具模擬運營后的業務最高峰值時的系統承壓能力、穩定能力及性能表現能力，以便有效處理郵政銀行的各類業務。測試的內容有穩定性測試、容災測試、異常測試及雙機切換測試等。測試中要注意軟件單元的集中性，做到將模塊、硬件及網絡其他資源有機結合，測試結果與需求不符時，要適時地返回修改[3]。此外，對系統的功能、性能，也需進行測試，以保證軟件的運行需求得以滿足，最后形成測試報告。（5）試運行和后期維護。挑選試用范圍，開發人員與試用用戶對系統運行情況進行記錄，以便分析總結試運行中出現的問題。試用人員要接受開發人員的相關培訓。后期維護涉及到軟件系統的升級變更，此時就要進行性能回歸測試，驗證業務更新后系統的邏輯性能能否及時跟進，避免因性能不佳致使銀行業務的滯后及癱瘓。此外，在銀行業務增加時，要選取郵政銀行典型業務開展綠燈測試，確保業務在軟件系統上的兼容性、可操作性。
3結語
信息化時代，計算機軟件工程與郵政銀行的業務發展結合得越來越緊密，同時，軟件工程項目的安全可靠也是郵政銀行系統穩定安全的技術保障。郵政銀行要著力提高軟件工程項目的應用管理，通過設計檢驗的規范化、科學化，不斷提高軟件運行的精準度，從而在金融市場競爭中占得先機。
作者：張倩 單位：中國郵政儲蓄銀行
論文關鍵詞：軟件項目；軟件過程；CMM；KPA
1．引言
項目管理(PM，projectmanagement)是指利用現有的知識、方法和技術手段，有效地計劃、調度、控制和跟蹤項目的開始、執行、直止終止的過程，是項目順利實現的有效手段。軟件項目管理則是在項目管理的基礎上，結合軟件產品的實際，利用工程的概念和方法來開發與維護軟件，對成本、風險、時間、質量、過程、配置等進行分析、管理、控制，最終目的是為了讓軟件項目的整個生命周期都在管理者的控制范圍內，以預定成本按期、按質完成軟件的開發并交付用戶使用。目前，軟件產品已廣泛應用于各個領域，但是很多軟件項目的成功率并不高．雖然有些公司根據軟件工程理論建立了一些軟件開發管理規范．但并沒有從根本上提高軟件項目管理問題，這就導致軟件產品質量不穩定甚至是項目的失敗，同時也損害了用戶的利益。本文結合我國軟件項目管理的特點并經實踐應用．以提高軟件質量、降低成本、加強軟件項目的可控性為目標，通過對CMM的研究和改進，給出了一個基于CMM加強軟件項目管理的實踐模式，在這個模式中對目前CMM中的KPA做適當的裁減，定義了6個關鍵過程域和3個工作組。
2．軟件項目管理中目前存在的問題
影響軟件項目成功率的因素主要是軟件質量問題，而在整個軟件項目的實施過程中需求不明確、跟蹤和監督不力、缺乏客觀的軟件評審和軟件配置以及風險管理意識不足等都阻礙著軟件質量的提高。
2．1需求不明確
需求管理是軟件項目管理中非常關鍵的一個步驟．需求分析的完整與否可以降低軟件質量、延長項目周期、加大成本。由于用戶對計算機系統認識的不足，對于系統的需求往往比較模糊，遺漏甚至是錯誤的問題經常出現(包括管理流程、業務流程、數據或報表的分析處理等)，但這些問題往往沒有暴露給開發人員，而是隨著項目的進展才逐漸明確。對于開發人員來說，需求的變更意味著軟件產品的部分內容必須重新開發，而對于整個軟件項目管理而言，勢必要重新分配資源、調整計劃、估算成本等等，導致軟件產品質量下降。
2.2跟蹤和監督不力
跟蹤和監督主要針對過程而言，也是項目管理中最容易被忽視的環節。軟件項目過程由多個任務構成，大部分任務都有前置任務和后置任務，這就要求項目管理者要嚴格跟蹤和監督每一個任務。任務的完成主要從時間進度和質量兩方面來衡量，還要充分考慮因客戶方引起的一些客觀因素(更改需求分析等)。項目管理者雖然制定了具體的項目進度內容，但如果缺乏有效的跟蹤和監督機制，對于每一個階段所要完成的任務疏于評價，就會影響下階段軟件產品的質量，有時甚至是軟件產品的重新開發，最終影響整個軟件項目。
2．3缺乏客觀的軟件評審
客觀的軟件評審是軟件產品質量的直接保障，軟件評審一直貫穿于整個軟件項目的過程中，對軟件產品的評審應有客戶使用人員和軟件業中的同行來進行。客戶使用人員對軟件產品做階段性的評審可以及時發現軟件產品功能方面的不足，同行評審可以從軟件業的規范及標準去發現問題．軟件評審可以降低軟件開發的成本提高軟件產品的質量。大多情況下項目管理者沒有做任何階段性的評審，通常只是在軟件產品開發基本完成之后來組織評審，果發現了很多問題，但要修改已經非常困難．要花費很長的時間甚至從頭再來。
2．4軟件配置混亂
軟件配置是指軟件產品在各個階段各種版本的文檔、程序及數據的集合，貫穿于整個軟件項目的始終。隨著軟件產品開發的進行，由于各種客觀原因，其中的預算、設計方案、進度等內容都有可能需要大大小小的更改(這些改動可能是合理的)，整個改變的過程對軟件項目的參與人員來說必須是可視的，以便提高軟件的可靠性和質量，而這一切都應該有正確的軟件配置來控制如果失去正確的軟件配置管理，那么針對軟件產品發生的任何更改或者是維護都會給軟件項目帶來混亂甚至是失敗。
2．5風險管理意識不足
風險管理是軟件項目中防止失敗的一種重要手段，軟件項目不同的階段存在著不同的風險，并且風險會隨著項目的進展而變化，目前國內的軟件企業大都不注意軟件項目的風險管理。除了社會環境風險、商業風險等這些客觀風險之外．可控的軟件項目風險主要指技術風險。技術風險主要是指與軟件項目本身相關的的技術因素變化帶來的風險，如果在一定的條件下達不到技術條件能夠實現的目標，不但延緩項目的進度而且會增加項目的成本．繼而使整個項目受到影響。
3．通過過程管理加強軟件項目管理的實踐模式
利用cMM fCapabilityMaturityModeforSoftware)的核心思想把軟件項目管理看作一個軟件過程，并根據這一原則對整個軟件項目的開發和管理進行過程監控，監督發現過程中影響項目的關鍵問題并予以解決。軟件過程是指軟件開發人員開發和維護軟件及相關產品的一套行為、方法、實踐及變換過程，包括軟件開發過程和軟件管理過程。CMM把軟件開發機構按照不同開發水平劃分為5個級別。每個等級被分解為幾個KPA(關鍵過程域)，KPA是指在某個成熟度等級應重點關注的區域，也是達到此成熟度等級必須解決的關鍵點。①初始級，無過程意義。軟件過程是無序的、隨機的、缺乏總計劃，無預見性，大多數活動是應付危機，經常超期超支，成功取決于個人。②可重復級，具備基本的項目管理。KPA分別是：需求管理、軟件項目計劃、軟件跟蹤與監督、軟件子合同管理、軟件質量保證、軟件配置管理；③已定義級，已定義軟件過程。已將軟件管理和軟件工程兩方面的過程文檔化、標準化，并綜合成該組織的標準軟件過程。KPA分別是：組織過程焦點、組織過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調、同行評審；④可管理級，過程可度量。已收集了軟件過程和產品質量的詳細度量方法，軟件過程和產品均可被定量地理解和控制。KPA分別是：定量過程管理、軟件質量管理；⑤優化級，過程控制。通過過程的量化反饋以及新技術、新方法促使過程不斷改進。KPA分別是：缺陷預防、技術更新預防、過程更改管理。
CMM只是一個過程改進的框架．并沒有給出具體實施的辦法。在該模式中對目前CMM中的KPA做適當裁減．定義了6個關鍵過程域：軟件項目計劃(SPP)、需求管理(RM)、軟件項目跟蹤和監督(SPTO)、軟件質量保證(SQA)、軟件配置(SCM)、同行評審(PR)，設置了三個工作組：軟件項目過程組(SPPG)、軟件工程組(SEG)、軟件質量保證組(SQAG)。通過工作組對關鍵過程域的操作來加強軟件項目的管理。
3．1定義KPA
3.1.1軟件項目計劃(SPP)
軟件項目計劃是為要實施的軟件項目編制軟件過程活動的安排，包括進度控制、成本控制、質量控制、風險控制等，也是實施CMM2的核心此階段在安排過程活動的同時開展項目設計的前期工作，設計和界定在整個項目中各階段所需的開發、質量、跟蹤、評審、風險、成本等工作。項目計劃是指導項目過程的具體措施，要在有軟件項目實施經驗的人員領導下投人大量的時間和人力資源來完成。制定項目計劃應注意7個問題。①在科學論證的基礎上制定過程，充分調動人員積極性合理地確定項目組的參加人員；②對軟件項目各程中的任務進行分解，明確項目的里程碑和檢查點；③正確估計軟件項目中的軟件資源、硬件資源、人力資源及其它費用；④正確估計各方面因素帶來的風險并制定應對措施；⑤制定項目實施過程中的跟蹤和監督措施；⑥確定軟件的評審和測試方法；⑦詳細的文檔資料。
3．1．2需求管理(RM)
需求分析主要包括面向用戶的用戶需求和面向開發人員的系統需求．是整個軟件工程的第一步．也是非常關鍵的一個環節。需求分析主要針對用戶的業務流程、系統功能、性能、數據分析進行嚴格的定義．是設計一個軟件應用系統的起點與基本依據，通過它來評判軟件產品是否能夠解決用戶問題，也是項目成功與否的標準。就目前國內現狀來講，一般簽定軟件項目合同的用戶是主管信息技術的負責人，它所關心的可能是整個系統的目標需求，用戶方中層管理人員關心的是業務流程需求．終端操作人員則注重軟件本身的易操作性和功能特性，因此．面向用戶的需求一定要和用戶多方人員多溝通、交流．最終通過雙方有關部門人員的論證以文檔資料的形式確定下來。任何一個需求分析因客觀原因可能存在著需求更改的現象，對于這種情況一定要注意需求更改的可控性．要建立需求的基準版本和更改版本控制文檔資料．使受需求變化影響的產品與需求變更一致。但要注意在更改需求的同時要衡量需求的穩定性，如果一個需求的變更比較頻繁，意味著本項目并沒有真正了解用戶想要解決的實際問題。可以說需求分析的完整性和變更可控性直接影響到軟件過程的改進，它可以降低軟件質量、加大軟件開發的成本、甚至是導致項目的失敗。軟件工程組(SEG)中要明確定義一個需求管理員。
3．1．3軟件項目跟蹤和監督(SPTO)
軟件項目的跟蹤和監督始終貫穿于整個軟件項目的過程中，是項目得以控制的前提和條件、是軟件質量的根本保障，其目的是增加軟件過程中進度、成本、工作量、質量、風險等內容的可視性，也是實施CMM2的核心。除去市場、法律等不可控制因素外，根據項目計劃對項目進展的有關情況及影響項目實施的相關因素進行及時、客觀、準確的信息采集，將采集到的需求、成本、進度、風險等內容形成文檔并建立一個項目跟蹤信息平臺。項目負責人定期召集軟件過程人員、開發人員、質量保證人員、用戶方有關人員召開開放式的例會，例會的主要內容是檢查項目進展、數據的分析、認識的偏差、資源的搭配、相關的風險等問題并討論確切的解決辦法，通過跟蹤和監督使項目始終處于可視化的受控狀態。
3.1.4軟件質量保證(SQA)
軟件質量保證是與軟件產品滿足規定的和隱含的需要能力有關的特征或特性的組合。對用戶來講主要體現在軟件產品的有效性、一致性、完整性、可靠性和可操作性等方面，對于軟件產品本身來講體現在軟件產品的可移植性、易維護性、健壯性、可重用性等方面。具體實踐中．軟件質量保證應在軟件項目計劃、需求分析、跟蹤和監督、軟件配置和軟件評審的相互配合下完成．軟件質量保證要做到以事先預防和跟蹤為主，事后糾偏為輔。
3．1．5軟件配置(SCM)
軟件配置是針對軟件產品的跟蹤和控制活動．貫穿于整個軟件項目的過程中．目的是建立和維護在整個生命周期內軟件產品的完整性和一致性，使整個軟件產品的演進過程處于可控的狀態，繼而提高軟件的可靠性和質量。在實踐應用中主要做到五個子項的配置①配置項的標識。標識做到唯一性。便于跟蹤和管理。②版本管理。對整個軟件過程中的文件和目錄提供有效的跟蹤手段。③變更控制。保持并傳遞修改信息。④配置審計。確定整個項目生產周期中產品在技術和管理上的完整性。⑤系統整合。把系統的不同部分集成后完成一組特定的功能。
3．1．6同行評審(PR)
同行評審是根據預定的規范和標準對軟件產品進行評審。評審的結果是衡量軟件產品質量的依據。在整個軟件過程中對詳細設計和軟件綜合測試作為兩個關鍵評審點來進行評審，評審的過程中注意要結合本軟件項目的具體要求和標準。
3．2組的定義
在具體的實踐應用中設置了三個組，在降低了人員成本的同時提高了軟件過程改進能力和軟件質量。
軟件項目過程組(SPPG)組織具體的項目實施活動，管理并協調整個軟件項目的過程，主要完成SPP和SPTO。
軟件工程組(SEG)負責軟件工程的需求分析、概要設計、詳細設計、編碼、測試、維護工作。
軟件質量保證組(SQAG)主要完成SPTO、SCM、PR、SQA等工作。
4．實踐模式效率評估
4．1開發時間
軟件開發由需求分析、概要設計、詳細設計、編碼、軟件測試、項目維護和軟件集成幾部分內容組成，在需求分析和設計階段采用CMM框架實施過程管理所花費的時間要多于沒有實施過程管理花費的時間。首先對項目做大量分析，論證項目的可行性。然后在和用戶做良好溝通、反復論證的基礎上做需求分析，形成文檔資料。這種模式下花費在需求分析和設計上的時間大約占項目總開發時間的40％，但這兩個階段完成了數據流程、算法描述、詳細的規格說明等內容，為代碼編寫、軟件測試、軟件維護等后續內容的工作節省了時間，軟件項目的開發周期大大縮短。經過評估，采用該實踐模式實施軟件過程管理的軟件項目開發周期比沒有實施軟件過程管理的軟件項目開發周期縮短20％。
4．2開發質量
采用CMM標準通過軟件過程管理加強軟件項目管理的實踐模式使軟件質量明顯提高、需求分析周密、代碼錯誤率明顯降低、軟件產品完整性好、功能齊全、維護量下降，軟件項目最終得以順利實現。
