前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇項目需求分析范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

項目需求分析范文第1篇

2 什么是需求分析

結構化軟件開發一般分為分析、設計、開發、測試、驗收與運行等階段。開發前，會進行前期的可行性研究；在運行開始以后，還要進行后期維護。需求分析是結構化開發中的重要階段。通常情況下，國內軟件開發公司在做歐美和日本的項目時，對前期的可行性研究參與得較少，一般都是對方已經做完可行性研究，國內軟件開發公司從需求分析開始做起，直到軟件開發后的運行和維護。所謂需求分析，是指對要解決的問題進行詳細的分析，弄清楚客戶的需求，包括需要輸入什么數據，要得到什么結果，最后應輸出什么，等等?？梢哉f，軟件工程當中的需求分析就是確定要計算機做什么。

3 需求分析的重要性

從需求分析的定義上，就可以看出需求分析在軟件開發過程中的重要性了。需求分析做得不對，后面的步驟做得再好，也只能是南轅北轍，無法滿足客戶的要求。研究表明，改正產品付諸應用后所發現的一個需求方面的缺陷，比在需求階段改正這個錯誤要多付出大約100倍的成本。而另一項研究發現，在需求開發階段發現的一個錯誤，平均僅需要花30分鐘修復，但若在系統測試時發現則需要5-17個小時來修復。

需求工程的成功與否直接關系到系統給的命運，需求工程絕對不是軟件開發的前期任務，而應該在整個系統的生命周期里都扮演著重要角色。在需求工程階段解決和根除需求引起的問題可以大大降低生產和維護的成本，提高用戶的滿意度。在軟件開發的過程中，需求工程階段是了解用戶需求的最佳時期，但很大一部分用戶不知道、不了解需求工程，以至于在和他們交流的時候，他們都不能準確完整的說出自己的需求，因而對于從事需求工程的人員來說，能夠正確的理解用戶的需求觀點，利用一些方法和技巧來啟發用戶闡述清楚自己的需求是很重要的。需求工程作為了解并實現軟件開發者的目標的重要手段，有著不可替代的作用。

比如一個失敗的案例：由于和客戶簽訂了合同，5個月必須交付軟件，開發時間緊迫，導致項目計劃時做需求分析的時間只給了2周時間（理由是客戶的文檔已經提供好了，照著做即可）。結果，由于前期對客戶文檔理解得不是很清楚，導致開發進行到3個月的時候發現需求上有爭議。在和客戶確認后得出結論：如果要滿足客戶的要求，則需要對整體架構進行修改。雖然最后按期交付了軟件，但是整個項目組最后兩個月每天都在加班，包括周末，而且軟件質量也沒有得到客戶的充分認可。

再如我們在了解客戶需求的同時，應該盡量了解客戶為什么要這么做，幫客戶一起想需求，以便我們開發的軟件能夠更好地為客戶服務。每天開完會后，我們應該把客戶的需求整理好，發給同事進行研究分析，建立簡單的基礎模型并研究技術可行性。需求分析結束后，保持每周至少3次電話會議與客戶進行溝通，隨時了解客戶的需求。最后正因為在前期階段進行了這種細致的需求分析，項目組在很少加班的情況下，不但按時交付了項目，并且得到客戶的充分認可。

4 軟件需求分析的任務

軟件工程的發展來源于信息需求對它的推動，現在互聯網技術和應用越來越成熟，信息的獲取也逐漸變得簡單和完整，但是由于資源的開放性、系統與系統的相互滲透性、用戶的變動性讓需求變得多目的、多變化，增加了軟件制作的難度，但同樣帶來了巨大的用戶市場。需求的獲取同樣也是困擾軟件工程的絆腳石。需求與資源的搭配不合理，就會影響軟件工程的發展。未來適應變化多端的用戶需求，必須讓軟件也隨之變化。要滿足多樣化的信息需求，提取合適的信息需求建立模式，就要有相應的系統對需求信息進行分析和總結，通過程序化的模式來制定切實可行的軟件方案。

國項目中，在前期分析時軟件開發的核心技術人員和測試人員就已經進入項目組，每天技術人員會對分析的結果提出技術實現的難點以及改進的方法，筆者在隨后的會議上就會和客戶進行討論，盡量在滿足客戶需求的同時，使用更簡單可行的技術，這樣就為以后的開發奠定了基礎，使開發時的工作量大大減少。測試人員也在需求時提出從測試角度看到的問題，同樣在需求分析階段得到解決，節省了大量的開發時間。

需求工程在未來發展中會有如下幾個方面的著重考慮：（1）縮小需求工程在理論研究階段取得的成果同實際應用中得到的效果的差距，通過得到的結論來更好的設計軟件；（2）規范需求工程的各種機制，可以有需求工程規格數據的搜集、整理、制作、實現以及維護，也可以有需求工程的問題的解決辦法；（3）保證需求工程有較高的質量。這一點是需求工程最為關鍵的要求，質量的高低直接影響了未來實現效果的好壞。需求工程就是對未知問題進行探索、處理的過程。未來必然會朝著對象具體化、分析自動化的方向發展。

5 進行需求分析的注意事項

5.1 需求分析是分析人員與用戶共同的責任

用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人員則要認真了解用戶的要求，細致地進行調查分析，把用戶做什么的要求最終轉換成一個完全的、精細的軟件邏輯模型，并寫出軟件的需求規格說明，準確地表達用戶的要求。在一些項目中，由于時間緊迫，一些模糊問題沒有及時澄清，導致最后返工，影響了項目進度。

5.2 需求分析階段研究的對象是軟件項目的用戶要求

需要注意的是，必須理解用戶的各項要求，但又不能全盤接受所有的要求。在一些項目中，針對客戶提出的需求，了解客戶的意圖后，發現技術上實現有很大難度。我們了解到這個需求對客戶來說不是十分重要，于是和客戶商量出一個折中的解決方案，繞過技術難點，并且沒有降低客戶滿意度。

5.3 主動積極了解客戶業務和相關知識

求討論集中于業務需求和任務，因此要使用術語?？蛻魬獙⒂嘘P術語教給分析人員，而客戶不一定要懂得計算機行業的術語。由于通常情況下客戶對計算機術語了解不多，需求分析人員應該盡量將計算機術語轉化成通俗易懂的語言，這樣便于和客戶溝通。而對于客戶方面的術語，一方面不懂的時候一定要問；另一方面也要多學習。

項目需求分析范文第2篇

關鍵詞：水利；集成項目設計；需求分析

中圖分類號：TV512 文獻標識碼：A 文章編號：1006-8937（2013）08-0158-02

隨著我國的經濟發展速度的加快，各種基礎建設步伐也逐年加快，在水利建設中的投資也空前巨大。而在水利工程投資項目中，自動化系統的投入作為一股新興行業受到廣泛關注。越來越多的大型泵站、水閘項目為了實現對工程的實時監控和信息管理，提高工程的運行管理水平，要求投入自動化系統以確保水工建筑物的安全使用，并提高工程效益。

這就要求有一大批素質高、善管理、會經營、懂技術的項目管理人才參與其中。怎樣管理好工程，在建設施工中節省資金、降低損耗、節省勞動力以保證項目質量目標、進度目標如期實現。要實現這些目標，項目經理以及其所在的項目組首先要做的就是做好需求分析，弄清系統該做什么，不做什么，嚴格為業主把好關，為系統的成功實施打好基礎。基礎打的牢不牢就像一棟大樓的地基一樣，對整個工程的實施至關重要，是項目實施成敗的關鍵一步。

水利工程自動控制系統項目同一般的信息系統集成項目的過程一樣，分為啟動階段、計劃階段、實施階段、收尾階段。啟動階段是正式認可一個新項目的存在，或者是對一個已經存的項目讓其繼續進行下一階段工作的過程。其中需求分析屬于啟動階段的工作范疇，是新項目啟動階段的主要工作環節。

在具體項目中，需求的來源通常來自于以下幾個方面。

1 合同制約因素

當業主招標書后，其內部定義的所有制約因素，就成為界定需求分析范圍的重要考慮因素。也是項目組編制投標文件，中標后簽定合同的重要依據。當項目完成后，合同條款就成為驗收審核的重要標準，項目經理要考慮的就是一切按合同完成功能。

例如在一項水閘自動化項目招標書中提出：自動化系統投運后，要具備測量和數據處理功能，其中包括：檢測顯示所有設備的開關狀態；測量顯示上、下游水位和閘門的啟閉高度；測量各電量及電動機的電流等值；在引水或排澇工況下，根據設定的水位條件，自動進行開關閘預告；在開閘運行中自動計算瞬時流量、日平均流量、每閘次的引排水量。

項目組在前期需求分析的過程中就必須把這些功能以及實現這些功能需要設計的硬件、軟件資源全部考慮進去。

2 業主客戶要求

每一個項目都具有其獨特性，使用者在使用過程中都會有一些特殊的要求，而這些功能往往是在合同中不曾涵蓋的。這就需要在項目的前期啟動過程中，與用戶先行進行溝通，了解他們是否有什么具體要求。但由于很多情況下用戶前期對項目理解不夠，往往在初期無法提出具體需求，隨著項目的日趨推進，業主對整個項目有了一定直觀的了解后，可能需求也隨之增加。這些增加的可能性越大項目風險就會越大，因為很多需求是偏離整個項目的最終目的的。我們在需求分析的時候就要充分考慮到哪些需求是相對固定的，哪些可能會是產生變動的，考慮到他的可變性和可增加性，這樣前期功能設計的時候不會因為后面的變動和增加而影響整個工程。這一部分的需求往往難以把握，這就需要項目組成員根據歷史資料和豐富實戰經驗進行先期考慮。

3 歷史資料和實戰經驗

在項目范圍界定期內，應該考慮以前項目計劃的有關歷史資料。大多數同類型工程項目都有其特定的規律，項目組完全可以根據以前類似項目界定工作范圍。

例如每個水閘自動化項目中都需要相應的報表，以實現對閘門的實時查詢和歷史查詢。但假如在自動化項目具體的招標書中并沒有具體實際的要求，項目組成員不能對這個方面不予考慮，而是要依據以往工程所做的報表，總結出大致報表的規律。如報表可分為兩大類：事件類和數據類。事件類是指運行事件和重要的系統操作，如全部的報警記錄、閘門啟閉記錄、手動命令等。數據類是采集的實時水位和閘門開度，計算的實時流量、引排水量，存儲的每日8時流量、8時水位、最位和最低潮位等各特征值，為生成各種報表、曲線和圖形所用。中央控制室配有打印機，可定時或實時打印各類報表。總結后把大致規律與本工程相結合，總結出適合本工程的幾類報表，先行把各類資源考慮進去。否則當工程交付時，用戶提出再進行功能追加，勢必會造成工期延誤，影響整個項目的順利進展。

但是畢竟不是每個分析人員都是專業而合格的，所以需求分析報告不一定很完善，會存在或多或少的缺陷。為避免這種情況的發生，需求分析必須經過項目組內部成員和業主的共同審核，討論達成一致后雙方共同簽字，確認。

在多個工程具體實施中，發現在此階段可能出現的問題如下：

①需求分析過于籠統，只關注到面上，沒有關注到點上。往往開發出來的東西在具體的細節上和客戶的理解有誤差，并且無法嚴格界定是否屬于需求變更。

②需求報告沒有獲得業主的評審，因為業主早期對項目的不確定，如果只有我方評審通過，不去向業主仔細的分析和解釋，只求客戶簽字，就會在后期造成隱患。因為很多時候具體用戶在自動化系統未投入運行階段對其認知非常模糊，有時甚至要到系統投運后才能有完全深刻的理解。雖然業主簽字即能夠給日后出現問題時劃清我們的責任，但是卻不能保證業主的滿意，不能保證項目實施成功。

③需求分析中含有技術實施上有難度的功能。很多時候，客戶的想法在實際實施過程中是不現實的，一味的求全和盲目按照客戶的設想，勢必造成整個項目實施過程中受阻。此時，項目經理要做的就是與客戶進行協調磋商，分析具體的性價比，建議用更為簡便的方法來替代。例如曾有客戶要求在一個閘門自動控制系統中加入對閘門土建方面以及鋼結構方面的檢測數據，而要滿足這項功能需要購置大量相應設備與自動化項目進行整合，這樣前期設備采購成本和后期系統通訊調試工作量都大幅提高。而此項工作完成后，僅僅是在幾年甚至是十幾年后才有可能發揮起真正作用，這是與一個自動化項目的生命周期是不相吻合的。故與用戶協商后，建議過一段時間后請專職水利勘測人員進行檢測，達到最高性價比。

④項目的完成度受業主預算的限制。當前大部分項目都是經過論證、概預算、招投標等多步發展最終確認的。在項目投入上是有上限的，在此情況下，項目的功能完成度將受影響，畢竟功能越多越完善，相應的軟硬件開發成本就越高。如果一味追求功能多，將勢必損失質量。這種局限性需要事先告知客戶并得到理解。

⑤此項工作的繁瑣枯燥，勢必造成思想上的倦怠，使需求分析最后虎頭蛇尾。需求分析是一項反復的工作，需要和業主之間不斷的商討和確認，不斷的被駁回和不斷的修改。大部分的客戶雖然安排專人負責這項工作，但是該負責人大多數情況下都是相關部門領導，本身對項目細節就不是非常理解，特別當他被很多其它的事務纏身，無心細看需求報告，他很可能會倉促簽字認可，造成對設計沒有完全理解和認可。

參考文獻：

[1] 柳純錄，劉明亮，高章舜.信息系統項目管理師教程[M].北京：清華大學出版社，2008.

項目需求分析范文第3篇

[關鍵詞]項目策劃人才；社會需求；調查分析

項目策劃，本身是一種思維過程，兼具建設性和邏輯性。該過程主要體現在總結所有可能對決策造成影響的決定，使其起到指導、控制未來的作用，以便借此實現方案的目標?，F如今，項目策劃的受關注度越來越高，而該類人才的社會需求，也在與日俱增。筆者針對此進行簡單的調查和分析。

1.項目策劃人才的社會需求調研設計

筆者于2015年春季，采用調查問卷、電話訪談、座談會、企業調研、網絡查詢等形式完成調查，共發放300份調查問卷，回收270份，有效問卷259份，問卷的有效率在96%左右。本次調研，主要在各個單位的策劃部、大型慶典策劃場所等，就體育、旅游、公關、文化、房地產等領域的項目策劃人才展開調查，調查覆蓋面較廣。

2.項目策劃人才的社會需求特征

此次調研中，被調研到的民營企業占了大多數，這些企業從事項目策劃的人員并不多，往往不超過十人。通過反饋到的問卷，筆者發現有近七成的企業，在一年內打算招收項目策劃方面的人才，項目策劃人才的需求量明顯呈遞增趨勢。還有部分企業，對項目策劃人的工作經驗頗為關注。

2.1人才素質需求特征

調查結果表明，項目策劃相關單位，對員工往往涉及專業素養、職業道德素質及其他素質的需求。這些素質中，排在前三位的依次是認真負責的工作態度（21.2%）、吃苦耐勞的意志品質（19.6%）以及市場調研的能力（16.8%）。多數企業認為，首先，道德層面的素質是最重要的，其次才是學習能力、專業技能水平等職業素質。

2.2人才崗位需求特征

調查結果表明，項目策劃人才的工作崗位一般分為兩種：技術類崗位和營銷推廣類的崗位。其中，技術類崗位最典型的是策劃師，其范圍非常廣泛，最典型如婚禮策劃師、旅游策劃師、房地產策劃師等；營銷推廣類的崗位，典型如市場營銷專員。在所有崗位中，房地產策劃師占比高居榜首，筆者認為這可能和如今的房地產發展狀況有一定關系。其次是網絡營銷、網站建設方面的策劃師，占的比例也較大。

2.3人才能力需求特征

調查結果表明，近五成企業，需要復合型人才擔任項目策劃職務，28%左右的企業更看重信息收集整理、整合資源的能力；26%左右的企業更看重推廣項目的能力，如溝通、組織能力等；22%左右的企業更看重專業技術。

3.項目策劃人職業素養方面的能力要求

3.1市場調研能力

對于項目策劃人才而言，市場調研能力至關重要。策劃人的靈魂在于其能夠將發展的機遇進行準確的預測并善于把握，抓住機會引領整個市場的潮流。市場調研能力，即策劃人分析市場現狀，進而針對未來的趨勢進行預測的能力，它對策劃工作人員未雨綢繆、深謀遠慮的戰略眼光，有著非常高的要求。市場調研能力強弱與策劃結果息息相關。

3.2整合能力

整合能力不可或缺。項目策劃人才并非比別人更加聰明，他們只是善于將不同的資源要素進行整合，針對各方面的力量加以協調形成合力，以達到策劃的目標。整合能力，即策劃人按照策劃本身的需要，將零散的策劃資源進行整合的能力。它包含了收集策劃資料、找尋策劃人才、制定策劃方案等，即對人、事、物的統籌和安排。對于項目策劃人才，特別是策劃經理人而言，其整合能力會對策劃的結果產生直接的影響。

3.3洞察能力

洞察能力，即策劃人對客觀現象，進行正確、全面、深入分析的能力。項目策劃人才的洞察能力，關系到策劃的結果質量如何。項目策劃人才，要具備全面分析的能力，善于統觀全局，并且能夠通過現象抓牢事物的本質，還要著眼于未來的發展，對未來的形勢進行科學的預見。這樣，才能夠保證項目策劃的強針對性。對項目策劃人才洞察力的要求，往往是“觀察別人沒有注意到的東西”，因此，項目策劃人員要善于從曾經的、現在的信息資料中，尋找重要素材。

例如，一家公司欲進行廣告宣傳，為此尋找暢銷的報紙或者雜志。公司苦于無法打探到報紙或雜志的真實發行量，也就無從判斷那種報紙雜志是否暢銷，是否值得在其上面登出廣告。公司策劃部門結合過往的信息資料，細致觀察報紙和雜志是否擺上了街邊的書報小攤，若擺上了即為暢銷，街邊的書報攤幾乎不會賣不暢銷的書報。就這樣，公司據此選擇了登廣告的報刊，抓住了市場機會。

3.4創新能力

現在很多企業的項目策劃離不開創新。項目策劃展現了思考問題的智慧程度，其本身即是思維的革新。真正的策劃決不能失去了創新元素。典型如婚禮策劃師，在營造婚禮的浪漫情境中，創意和想象力非常重要。

3.5執行能力

項目策劃不是紙上談兵，策劃人在進行細致縝密的構思后，就要采取實際行動。有時候，執行能力如何，甚至會成為項目策劃方案是否取得成功的關鍵因素。更何況，項目策劃不僅僅是做出一個策劃方案，還要將切實可行的執行方式與流程設計出來，特別是在基層工作的項目策劃者，必要時要做好監理、指揮工作，甚至要親自執行。

4.針對項目策劃人才培養的建議

社會對項目策劃類的人才，有著越來越大的需求。與此同時，社會對項目策劃人才素質方面的要求也更高。正因為此，針對如今社會的需求，將現有的教育管理模式進行改革，使項目策劃人才能更切合社會發展的需要，具有非常重要的現實意義。

4.1明確培養目標

現有研究成果指出，單純的管理型項目策劃人才，已難以滿足社會需求，目前階段項目策劃人才培養亟待改革?，F階段社會需要的，是善于策劃、通曉資源整合、極具創新精神和項目推廣能力的項目策劃人才。實際調查顯示，在項目策劃類人才的進修課程中，管理學高居榜首，其次是市場營銷。筆者認為，課程設置中應該增加社會性、實踐性強的課程數目，減少理論課，因為項目策劃主要面向市場推廣，在這個推廣過程中，實踐是必不可少的。

4.2改革培養方式

項目策劃，有著很強的實踐性，因此對每位策劃者而言，資源與信息的整合能力、對問題的發現能力、市場調研能力、分析決策能力、洞察能力非常重要。也正因為此，組織機構要讓策劃者從理論知識環境走入實際策劃環境中，讓他們在特定事件下，擬定策劃方案，從而對策劃者的實戰能力進行系統培養。策劃者個人也要積極參與實訓，通過有效的實訓提高自己對信息的整合能力以及對趨勢的分析與判斷能力。可以選擇一些熱點問題讓策劃者去解決，從而鍛煉其應變能力。

4.3提高該類人才的綜合素質

對項目策劃者而言，擁有較高的綜合素質很重要。良好的團隊精神、法制觀念、品德修養，是項目策劃人才必備的綜合素質。人際交往與溝通能力，關系到項目的推廣效果，因此這也是項目策劃人才不可或缺的能力。所以在針對項目策劃人員進行培養時，除了針對其專業素質進行培養外，綜合素質也不能忽視。

項目需求分析范文第4篇

關鍵詞：軟件工程；需求分析與管理

中圖分類號：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等）編制系統的初始用戶界面，便于軟件需求分析人員、系統設計人員和開發人員更直觀和形象的與用戶溝通和明確需求。非功能性需求和系統界面原形在需求分析階段非常重要，我們在項目開發過程中應該注重非功能性需求和系統界面原形。

最后，對于軟件需求分析人員編制的軟件需求說明書要做好需求驗證工作，參加需求驗證工作的成員應該包括項目組所有成員、該行業的業務專家和最終用戶。在需求驗證會議上提供的需求驗證材料應該簡單、清晰、直觀和明確，不能籠統的提供一些復雜的業務流程及繁瑣的文字說明。在需求驗證會議上可以通過情景模擬和系統界面原形的方式演示。情景模擬是根據不同業務角色模擬整個業務辦理的情況。系統界面原形能讓用戶切身感受到系統的界面效果，便于直觀、形象的溝通和交流業務細節和業務流程。

在項目開發過程中，用戶需求發生變化的情況經常出現。我們不能避免和逃避用戶需求變化情況的出現，但應該控制和管理用戶需求變化，應該有需求變更的流程、需求變更的團隊、需求變更的平臺、需求變更的影響分析以及固定的需求變更周期。對于用戶提出的需求變更，我們首先應該做好詳細的記錄，然后將需求變更的記錄通過需求變更的流程提交給需求變更團隊評估和確認，最終在需求變更的平臺中反映出來，同時要做好需求變更的影響分析報告并及時反饋給用戶。需要注意的是對于需求變更我們要有固定的需求變更周期，不能用戶有需求變更馬上要求項目團隊及時更改系統，這樣會加大項目管理的風險和影響項目團隊的士氣。

項目需求分析范文第5篇

[關鍵詞] 需求分析 需求變更 需求控制

一、問題的提出

什么是需求分析?

要知道需求變更是什么,首先要知道什么是需求分析。

需求分析是指理解客戶需求,就軟件功能與客戶達成一致,估計軟件風險和評估項目成本代價,最終形成開發計劃的一個復雜過程。需求分析的成果形成需求說明書。

什么是需求變更?

根據軟件工程思想定義,需求說明書一般要經過論證,如果在需求說明書經過論證以后,需要在原有需求基礎上追加和補充新的需求,或對原有需求進行修改和削減,均屬于需求變更。

二、需求變更的原因及影響

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)