項目需求分析精選(九篇)

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的項目需求分析主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：項目需求分析范文

關鍵詞：科研軟件；需求分析；開發模型；質量保障

0引言

隨著科研機構、高校承擔的國家大型科學工程項目越來越多，在這些大型科學工程中，軟件起到不可或缺的作用。如中國科學院高能物理研究所承擔的硬X射線調制望遠鏡項目［1］、BESIII項目［2］中的數據采集軟件、探測器和數據監測軟件是獲得物理成果的基礎，而模擬軟件和分析軟件則直接關系到物理成果的處理和精度。這類軟件項目有較深的物理學背景，需要使用一些物理分析和設計方法，實現手段必須符合領域特點。例如，數據存儲在粒子物理實驗和空間天體物理實驗中的要求不同，前者主要采用ROOT［3］格式，而后者則以FITS［4］格式為主，開發所用的常見庫和工具也因數據存取格式不同而不同。此外，該類軟件應用面較窄，僅限于某一科研領域，其開發很難由軟件公司承擔，因為軟件公司必須投入大量的學習成本，而產品應用又受局限。因此，這類軟件的開發一般由科研院所、高校自行承擔。然而，目前我國軟件整體實力與創新性還不強，人才結構也需要改善［5］，一些從事基礎研究的機構，軟件人才緊缺，且缺乏軟件開發管理經驗，造成軟件質量不高。科研機構從事軟件開發的科研人員學習能力強，熱衷于追求新技術，如果在方法上給予指導，可幫助其開發出高質量的軟件。依托大型工程培養所需的軟件人才，不僅有利于大型工程項目的實施，而且還能為國家培養大批軟件人才。本文結合該類軟件項目的特點和科研機構現狀，探討其軟件開發特點，并提出流程管理和質量保障措施。

1科研領域軟件開發及其特點

1．1軟件項目特點

（1）軟件提出者。一般是項目科學家、顧問，他們具有較強的科學洞察力，也能較好地把握軟件開發方向，但他們大多只關注宏觀問題，而非技術細節，對軟件不是很了解，不能用計算機語言和思維描述項目，也無法很好地理解和描述實現流程、細節，因此不能準確估計軟件開發難度和工作量。

（2）軟件開發者。一般為青年職工和學生，他們熟悉軟件開發，但往往不能完全理解項目目標，也不能深刻理解其物理過程，理解過程中往往思維局限性大，缺乏方向。

（3）軟件測試者。多數情況下單元測試由開發者承擔，集成或系統測試由其他人員完成，部分由用戶完成。與開發人員相比，測試人員往往物理基礎較好，掌握基本測試方法，但是沒有建立起完整的測試體系，而且將軟件測試當作“副業”，測試以功能實現為主，對軟件細節不了解。

（4）用戶。用戶一般是物理工作者，他們熟悉研究領域的物理要求，但不能用計算機語言描述需求，往往需求不實際或不夠明確。他們對軟件要求較高，要求通過物理測試對軟件性能和輸出結果精度進行測試。如通過運行大數據量檢查軟件內存和時間消耗，以促進開發者進行算法優化等。

1．2軟件項目開發特點

（1）軟件需求不夠明確。科研領域軟件項目一般都涉及到探測器和數據，涉及領域較廣，而且需求不斷變化。無論是軟件提出者還是用戶，往往難以用計算機思維或語言清楚描述問題；軟件開發者對項目物理目標，特別是物理過程缺乏深刻理解，不能很好地理解軟件功能細節及需求。比如，對于一些數據分析軟件，提出者或用戶難以描述出軟件需要完成的功能，而開發者對數據處理流程中進行的數據轉換、修正、數據結構重組也缺乏深刻理解。

（2）人員結構較為單一。軟件開發中通常一人需要承擔多種角色，包括軟件需求分析員、設計者和開發者，甚至測試者。這樣的職位設定，人員分工不明確，難以深入把握某一領域（比如測試）的特點和方法，從而影響了整個軟件開發過程。

（3）軟件實現細節難以把握。此類軟件一般涉及復雜的物理過程，需要用一定的物理方法解決，但方法并不唯一，不同方法會對結果帶來一定影響，而且不同類型數據所依賴的方法也不同。軟件開發中還有些研究性課題，只能以接口形式存在于軟件中，但預留接口時往往設計較為簡單，考慮的情況過于理想，難以滿足實際需求。然而，如果設計時考慮得比較復雜，接口較多，又往往缺乏必要的軟件技術和經驗，不能有效把握細節。

（4）硬件頻繁改動增加軟件開發風險。軟件依賴于硬件，設計初期軟件是在理想的硬件設計狀態下運行，但如果硬件發生變更或者運行影響因素增加，軟件也隨之變動，從而加大開發風險。

（5）軟件測試及評估缺乏專業水平。由于開發者、測試者與用戶的專業測試能力都比較欠缺，難以涉及到核心質量問題，往往無法全面對軟件作出專業評估。

（6）人員管理難度大。科研機構、高校一般熱衷于科學研究而不是工程項目本身，因此難以兼顧兩方面工作。軟件提出者和管理人員往往對軟件工程缺乏深入了解，難以對開發工作作出客觀評價，因此對軟件開發的進度和質量帶來一定影響。

（7）軟件不確定性因素多。隨著工程實施，軟件提出者、用戶會不斷改變、增加需求，加上開發者及測試者缺乏相關經驗，代碼開發不規范、開發人員流動性強等增加了軟件開發的不穩定性。另外，為降低開發成本和難度，開發人員通常會引入現成的工具，這可能給軟件開發帶來隱患。然而，面向某一科研領域的軟件開發項目也有自身的優勢。如和大型專業軟件相比，所需的項目功能不是特別多，部分開發平臺具有可移植性，開發人員綜合素質較高，學習能力強，英語基礎較好。此外，很多工程與國外合作開發，可參考國外成熟軟件，并方便引進一些免費的軟件框架和平臺，如Gaudi［6］框架、天文分析工具庫Ftool［7］等。

2軟件開發流程管理

2．1確定軟件開發模型

科研機構，尤其是一些缺少經驗的團隊，習慣采用瀑布模型進行開發，主要由于該模型分階段，且各階段間存在因果關系，比較符合思維模式。但它會產生大量文檔，到開發后期會凸顯軟件開發缺陷。適合科研領域的開發模型有迭代式模型［8－9］（需求變更驅動型）、增量模型（功能驅動型）及快速原型開發［10］等。對于科研軟件而言，模型選擇需綜合考慮軟件框架穩定性和開放性、構件獨立性以及項目組開發經驗等。比如對于需求不明確、流程不清晰、算法不確定的項目（如數據處理軟件、分析軟件和標定軟件等）采用迭代模型或者快速原型開發較好。此外，采用一種模型為主，其它模型為輔，也會得到很好的效果。

2．2加強開發流程控制

無論采用何種開發模型，開發人員必須在每一次開發或迭代中完整實現需求分析、設計、編碼和測試等步驟。各階段的評審或項目報告尤為重要，項目前期要確保軟件開發人員準確理解項目需求以及軟硬件環境；中期階段要確保開發流程和方法可靠；后期要通過測試確保軟件運行符合要求。

2．3需求分析中注重物理分析

科研軟件中一般涉及大量數據操作，而且過程比較復雜，一些原始數據要經過轉換、重建、標定及修正等步驟，而且處理不一定是線性的，即相鄰數據之間可能有關聯。這些功能和性能需求不容易明確，需要著重把握。軟件中還可能涉及一些物理算法（比如圖像修正、頻率分解等），因此在需求分析中需要著重進行物理分析，包括流程梳理、特殊方法和條件選擇等。

2．4采用串行開發方式

科研機構人員結構比較單一，往往多項工作并行執行，給軟件開發質量提升及人才培養帶來不利影響，可將相關性比較強的軟件以串行方式開發，數據產品生成軟件和數據分析軟件可以依次開發。

2．5提高開發人員的主觀能動性

軟件開發過程中，保障軟件項目負責人在經費使用及績效考核中的話語權，組建凝聚力強的研發團隊，對軟件開發的進度、質量進行考核。

3軟件質量保障措施

（1）加強開發過程中的溝通。科研項目的不確定性帶來軟件開發需求的變動，用戶往往只注重項目需求功能滿足，而不關心軟件的實現細節，所提出的功能或接口可能不切實際，因此需要加強與用戶的溝通，明確軟件開發目標。

（2）充分調動開發人員積極性。科研機構軟件開發人員往往是科研項目的幕后工作者，其工作成果容易被科研項目成果所掩蓋，所以充分調動軟件開發人員的工作積極性尤為必要。一方面，為其提供成果展示平臺，尤其是展示創新性成果，如將開發中的文檔整理成冊等；另一方面，在基金申請、職稱評定等方面提供支持。科研機構職稱評定主要依據取得的科研成果，由于工作內容不同，如采取同樣的評審條件，軟件開發人員與其他研究人員在同一層次上競爭將缺乏競爭力。可能導致部分人員不愿意從事軟件開發工作，或者開發軟件的同時還從事其它研究，從而影響軟件開發進度和質量。因此，需要根據軟件開發人員工作的特殊性，通過有效的激勵措施調動其積極性。

（3）培養既懂管理又懂技術的項目負責人。優秀的軟件工程項目負責人不僅是一個好的軟件設計師，對軟件實現細節能夠很好的掌控，還是一名優秀的管理者，能科學配置資源。

4結語

面向科研領域的軟件具有較深的行業背景，其設計方法、實現手段有很強的領域依賴性。本文從科研領域特點及軟件提出者、開發者、測試者、用戶的角度出發，探討了其需求難以明確、人員結構較單一且管理難度大的特點。在軟件開發管理過程中，需要采用合適的軟件開發模型，注重流程管理，充分調動開發人員的工作積極性。

參考文獻：

［1］LITIPEI，WUMEI．ThehardX－raymodulationtelescopemission［J］．Physics，2008，37（9）：648－651．

［2］LITIPEI．HXMT：achinesehigh－energyastrophysicsmission［J］．NuclearPhysicsB，2007（166）：131－139．

［3］BESCOLLABORATION．PreliminarydesignreportoftheBESIIIDetector［Z］．2003．

［4］TheROOTTeam．ROOTuser＇sguide［EB／OL］．https：／／root．cern．ch／drupal／content／users－guide．

［5］WELLSDC，GREISENEW，HARTENRH．FITS：aflexibleim－agetransportsystem［J］．A＆AS，1981，（44）：363－370．

［6］APrimerontheFITSDataFormat［EB／OL］．http：／／fits．gsfc．nasa．gov／fits＿primer．html．

［7］劉麗梅．中國軟件產業市場競爭力分析［M］．北京：對外經濟貿易大學，2007．

［8］BARRANDG．Gaudi－asoftwareconfigurationmanagementtool［C］．ProceedingofCHEP2000，2000．

［9］FTOOLS．Ageneralpackageofsoftwaretomanipulatefitsfiles［EB／OL］．http：／／heasarc．gsfc．nasa．gov／docs／software／ftools／ftools＿menu．html．

［10］張海籓．軟件工程導論［M］．北京：清華大學出版社，2005．

［11］師迎海，何雪慧．迭代式軟件開發模型研究及應用［J］．微處理機，2015（1）：55－57．

第2篇：項目需求分析范文

論文摘要:在云技術架構下,建立強大的多媒體教學資濠庫。這樣可以集中整合各方優秀的教學資源,建最好的和最豐富的教學課庫,讓各奏學生均可找到適合自己,而且自己感的課程和課件。建立了多媒體教學資涎庫后,既可以垴小東西部教育差距,又能保障教育資濼的均衡發展。

大部分教師(尤其大學教師)的工作應該相應的從向學生灌輸知識,轉向引導學生學習知識,找到激活學生學習智門的鑰匙。

放在云架構內的這些教學資源,隨著不斷的更新、增加,必將成為一筆極大的資源財富,不僅可以供在校學生學習使用,也可以提供給全社會需要再學習、需要更新知識的人士使用,為全社會形成一種不斷學習的氛圍,提供一個強大的資源保障。

一旦形成全社會不斷學習的風氣,社會就會和諧,文明程度的程度就會不斷提高,人們的創新意識和能力就有了源動力,人們就會從更多的追求物質財富轉而進入追求精神財富。

前文我們探討了利用“云技術+多媒體技術改革現有的教學模式”,話題意猶未盡,還想進一步探討一些教學模式改革的細節。當然我們暫且討論的教學對象為大學以上的學生,或部分高中生,因為絕大部分高中生的教學活動還是基本圍繞著高考指揮棒在轉。

在云技術架構下,建立強大的多媒體教學資源庫。這樣可以集中整合各方優秀的教師資源、教學設備資源,建最好的和最豐富的教學課程庫,讓各類學生均可找到適合自己,而且自己感的課程、課件和學習參考資料。

制作這些課程資源可以分工,高層次教師撰寫課程內容,配套各類教師,可以有的整合內容、有的應用多媒體素材加工制作課件、有的制作各類課程教程、而有的則準備相關參考資料以及考試題庫系統等教學資源。

這時的教學資源就不是屬于某個學校、某個團體、某個局部組織,而是屬于國家或全人類的資源,為全人類所共享。

這樣,可能有人會擔心是否教師或相應的人員都要下崗了呢?否!

大部分教師(尤其大學教師)的工作只是從向學生灌輸知識,轉向引導學生學習知識。大部分長期從事教學工作的教師深有體會,好學生不完全是教出來的,而且通過老師啟發性的引導,激活了他們的興趣,或打開了他們的智門,使他們自己要學習,只有激活了學習者的源動力,才能使他們朝著一個一個目標不斷攀登。

那么,教師教學要包括哪些內容呢?我認為教師的教學工作應該圍繞中如何能激活學習者的興趣和以如何能打開他們的智門為衡量指標。方法可以各不相同,因為人是個性化的,當然方法也應該因人而異,當然可以對個性相近的學生采用類似的方法,但還是需要有微調。

具體做法可以不斷摸索。教師可以組織學生開展各種開發、創新活動,可以組織各種競賽活動,可以組織學生參與各種專題討論活動,讓每個學生均有機會表達自己的想法和觀點,很多思想的火花是在交流中產生的,是在實踐過程中綻放的,所以要多提供一些機會讓學生經歷各種活動的鍛煉,活動的過程是最能鍛煉人能力的,如果省略了過程,結果也是不豐實的。

我們提倡多開展各種創新活動來鍛煉學生的能力,而現在學生這方面的鍛煉機會太少,應該增加相應的比例。那么是否就不考試了呢?當然不行!期間,我們的學校大多不考試,結果中學畢業生連簡單的一元一次方程都不會,這樣社會如何發展?考試還是衡量學生學習掌握程度的標尺,當然考試形式可以的筆試,也可以是操作過程,更可以寫論述文章、論文之類形式;考試時間可以是期中、期末考試,可以是融入平時的多次抽查中,也可以羅列各類課程統考時間安排表,學生學習到一定程度,可以報名參加考試,來檢驗自己知識的掌握程度,形式可以通過實踐不斷總結,不斷改進。總之,有助于學生更有效掌握知識、能打開學生智門的方法就是好方法。

學生通過考試,當然需要有一系列學分累積機制,最好將理論課程和實踐課程按不同學分比例分別統計,保證不同學科對理論和實際操作的要求不同。

這樣的機制,對教師的要求不是低了,而是更高。要求教師積極思考,尋找能與學生更好溝通,激活學生心智的鑰匙,這是沒有一個統一模式可循的,教師也必須不斷摸索、創新。

有了這種師生一對一、一對多、多對多的關系機制,學生與教師之間的距離不是遠了,而是更近了,社會也會更和諧。因為從教師的角度來說,必須了解學生,走近學生,才能找出適合他們學習自嘶方法,才能激活他們的學習興趣;從學生的角度來說,有問題、有心結就可以及時與他們所喜歡的教師溝通、請教,盡快排除障礙,琢磨出適合自己學習的好方法。要使學生學習效果好,教師與學生是一個整體,只有雙方的努力、協調,才能找到最佳的教學方法。

如果學生太多,老師顧及不了怎么辦?老師可以到學校與學生面對面的談話,也可以出現在各種活動場合,如:各類研討會老師可以當組織者,讓學生大家來準備內容、暢通各自的觀點,但教師更多的時間可以利用現有的網絡環境、3G環境,老師可以規定時間在網上,利用視頻、語音交流與學生好似面對面的交談,也可以利用手機、短信等的形式及時進行一些師生對話。不遠的將來電腦、手機、電視三網合一,利用任何IT工具都可以及時溝通,現代科學技術的發展已經具備了技術上的條件,問題是我們需要尋找到一系列行之有效的方法來強化師生間的溝通。

放在云架構內的這些教學資源,隨著不斷的更新、增加,必將成為一筆極大的資源財富,不僅可以供在校學生學 習使用,也可以提供給全社會需要再學習、需要更新知識的人士使用,為全社會形成一種不斷學習的氛圍,提供一個強大的資源保障。

一旦形成全社會不斷學習的風氣,社會就會和諧,文明程度的程度就會不斷提高,人們的創新意識和能力就有了源動力,人們就會從更多的追求物質財富逐步進入追求精神財富,那么社會的發展也就更穩健。

隨著社會的進步,我們應該摸索和尋找一種更理性和有利于學生身心健康的教學體制,讓學習者獲得獲取知識的樂趣,讓教師真正成為學生的良師益友。

第3篇：項目需求分析范文

【關鍵詞】項目管理；中小型企業人才需求；畢業生就業；國家政策

2012年，我國普通高校畢業生規模已達680萬人。由于當前我國經濟發展面臨的國內外環境仍然十分復雜，不穩定、不確定因素還很多；高校畢業生就業總量壓力和結構性矛盾依然突出，就業形勢不容樂觀。

雖然大學生求職與企業人才招聘不止進行一次，但是對于企業對畢業生的選擇和大學生畢業后第一次擇業的一系列工作活動來說，卻是符合項目的特征，即一次性，漸進性，多目標性，生命周期性。為系統地、全面地看清畢業生就業情況萎縮與社會人才需求增大的矛盾，運用項目管理過程思想將這一矛盾階段化、細節化，分析各方內在特征及相互之間的聯系與區別，結合相關應用理論、經驗知識和真實數據資料探索解決方法就顯得很有必要。

1.基于項目管理的國內中小型企業人才需求分析

統計數字顯示，當前我國中小型和微型企業已經占全國企業總數99%，創造的最終產品和服務價值相當于國內生產總值的60%左右，提供了全國80%的城鎮就業崗位，上繳的稅收約為國家稅收總額的50%。此外，目前，中國65%的發明專利、75%以上的企業技術創新、80%以上的新產品開發，都是由中小企業完成的。這充分表明，沒有量大面廣的中小企業的平穩較快發展，就沒有整個國民經濟的平穩較快發展[1]。而中小企業的生存發展歸根結底離不開人才的作用，找對人才、留住人才、發展人才，加強企業競爭力，延長企業生命力恰恰成為制約企業如何發展以及如何更好更快發展的重要因素。

1.1 中小型企業人才需求的特點

1.1.1 人才需求量大，需求層次廣

中小型企業的創立和發展期，用人比較靈活，隨著機構、規模不斷擴大，對人才的需求量急劇增加，除了基礎部門的行政運營人員，還有營銷管理人員、財務管理人員這類高級知識性人才，同時也大量缺乏專業技術人員。對人才存在如此大的缺口需求導致了大學畢業生成為中小企業的主要選拔對象，畢業生在中小企業的發展空間也很大。

1.1.2 認同企業文化，忠于為企業服務

中小型企業想要獲得長期的、穩定的發展壯大就必須建立完整的企業價值文化，只有當企業員工對企業價值高度認同，才能保證在企業發展過程中由于資金、技術、資源等有限的不良因素影響下，企業員工堅持個人價值與企業理念相契合，努力幫助企業渡過難關，個人潛力也得到最大發揮。

1.1.3 具備一定能力，有較強可塑性

近年來，企業在招聘員工方面相對于“學歷”更看重“學力”。當然，員工自身的基本能力培養也是必不可少的，這主要包括：問題分析能力、溝通能力、團隊合作能力、抗壓能力等。然而，不是每一個應聘人員都具備較強的能力，一旦加入就能為企業創造價值，所以企業現在選拔人才注重的是一種學習的能力，一種經“雕琢”后能變成“璞玉”的能力，一種能隨著環境變化自己不斷改進的能力。

1.1.4 有良好的信用背景，誠實信用

如今，誠實信用不僅是個人自身信用狀況的表現，也是社會各方對員工的考察點。特別是涉及到企業資金項目的財會人員、銷售人員、出納人員之前的信用情況，有無挪用、侵占企業資產、收取不當回扣等不良記錄。應聘人員學歷、資格證書有無假冒等，有時如果企業不慎重審查會給企業造成致命性的打擊。

1.1.5 擁有創新思維，具備創造能力

面對人民幣升值、原材料價格與用工成本不斷攀升、出口不景氣以及嚴峻的資金短缺等形勢，原來主要依靠低勞動力成本和廉價原材料的發展模式已經不再可行，科技創新和品牌越來越受到業界的重視。所以，中小企業應以“創新”為主導，有意識地選拔培養一批擁有創新思維，具備一定創造能力的新員工，這勢必為企業發展添磚加瓦。

1.2 中小型企業在招聘工作中存在的問題

在我國，中小企業平均壽命僅為三四年，中小企業招聘現存的主要問題有：企業缺乏人力資源管理；未進行成本估計；崗位需求分析不具體；招聘基礎工作薄弱；招聘崗位詮釋不全；員工錄用機制不規范；員工缺乏專業培訓；績效考核制度不健全；激勵措施不給力等。

這一系列問題之所以較為突出且沒有根本性改變，是由于中小企業是由單一個人或少數人提供資金組成，因此在經營上多半是業主直接管理而較少受外界干涉。企業受規模、資金、工作環境等的制約，家族管理模式下的任人唯親現象也就相當普遍，同時，缺乏良好的就業平臺、公平競爭的機會、人才培養的引導、地方政府的支持，使中小企業在人才引進和保留方面舉步維艱。

1.3 中小型企業人才招聘體系分析

將企業員工招聘進行項目化管理可以更系統、清晰地分析出每個階段的工作要求，使招聘工作更加規范化、合理化。結合相關現代人力資源管理理論，人才招聘項目化分解體系圖如下（見圖1）：

圖1 人才招聘項目化分解體系圖

1.3.1 啟動階段

啟動階段要求招聘的總體規劃必須符合企業文化，招聘成果有利于企業針對性、有計劃地引進人才，是關系到招聘工作實際性操作的基礎。

1.3.1.1 相關信息分析

信息分析可分為內部信息分析和外部信息分析。內部信息分析主要是與企業相關方面的評定與估計，如公司的地理位置、辦公條件、工資水平、盈利水平、負債情況、發展前景等。外部信息分析則是對公司控制之外的國家政策、人才市場環境、競爭對手情況加以考慮。

第4篇：項目需求分析范文

關鍵詞：軟件項目，軟件開發，需求管理，需求變更

 

在信息化建設高速發展的今天，建立與之相適應的信息化系統已成為政府機關，企事業單位的重要課題之一。然而，在軟件項目的開發過程中，項目變更頻繁、進度超期，成本增加等現象數不勝數，這些問題的出現，使很多項目無法達到預定的目標，最終不得不以失敗而告終。究其原因，主要有需求開發的原因、項目控制的原因、與客戶溝通的原因、技術方面的原因等等，但對項目影響最大的則大多與開發需求有關。

（一）軟件項目需求開發與管理存在問題分析

1、需求獲取過程中，需求的不確定性

（1）項目開發團隊缺乏項目的業務背景和行業經驗，沒有能完全了解客戶的需求，需求分析不到位。項目開發團隊的組成，是根據項目的規模、項目技術人員具備的專業技術水平來決定的。需求規格說明書是項目組成員通過前期的調研、向客戶詳細咨詢等方式獲得，是項目需求階段的重要文檔。需求分析人員在需求獲取過程中，由于不了解客戶的業務流程及行業狀況，不好把握客戶的需求，無法將需求表述為準確的技術用語，對項目需求分析產生一定的影響。

（2）客戶不能全面、準確的闡述項目需求。由于客戶對計算機系統的能力和限制缺乏了解，他們認為所提出的需求是否準確、全面，計算機最終能否達到他們的需求，只能取決于需求分析人員對客戶對需求的描述和理解。

（3）對需求理解的分歧。客戶和需求分析員之間由于工作背景不同以及理解的偏差，雙方很難在溝通過程中對某一問題進行有效的溝通。當需求分析人員就系統需求與客戶進行溝通時，需求分析人員通常使用的是專業的計算機術語，而客戶使用的是通俗的行業語言描述。對同樣的一句話，不同行業背景，不同層次的人員所理解的含義也盡不一樣，這些情況都會在認識上產生一定的分歧。

2、需求分析不完整

在需求分析階段，客戶提出的需求僅是一個模糊的概念，需求分析員雖然已按客戶的描述進行需求分析，但這只是從開發者的角度考慮，并沒有能完全站在客戶角度去搜集和整理需求，所形成的軟件需求說明文檔無法得到客戶的認可。

3、需求變更頻繁

需求在項目開發生命周期的任何階段，都有可能被改變、刪除或增加，需求的變更，對項目后期的相關活動產生很大的影響。這時，項目組成員不得不重新執行需求分析、設計、測試等工作。免費論文，需求變更。在需求評審、確認階段，不同層面的客戶所關注的問題也不盡一樣，由此將會提出其它新的想法及要求；另外，客戶的業務變化，也是客戶提出需求變更的原因之一，這些需求變更的提出，對項目的進度、成本、資源配置等造成一定程度的影響。

4、缺乏有效的溝通制度和機制

由于項目組對客戶的組織結構、人員關系、工作職責等沒有足夠了解，使得用戶需求的傳遞延遲、丟失或者傳達的意見被曲解的現象。另外，在需求開發階段，由于出現多個用戶代表各說其詞，沒有形成統一的需求，以致于項目組無法得到最終用戶代表確認的需求。

（二）軟件項目需求開發和管理對策

針對上述軟件項目需求開發和管理存在問題，提出以下應對措施：

1、全面、準確的理解客戶需求

（1）需求獲取是項目需求分析人員與客戶之間有效的溝通與交流，收集客戶需求，與客戶達成需求共識的活動。這項工作在很大程度上依賴于需求獲取者的專門知識，這種專門知識可以建立在對各種行業的了解上，也建立在對項目開發技術的全面了解上，因此項目需求獲取階段必須由具備專業技術知識的項目經理或技術人員擔當。針對項目開發方缺乏項目相關行業經驗的情況，可以聘請行業專家、顧問等專業人員，通過業務培訓、專業指導的方式進行，以提高項目團隊尤其是項目需求分析人員對客戶需求的把握能力。

（2）選擇熟悉業務流程、能夠確定需求的管理者、客戶代表，讓他們參與需求討論。對于客戶無法詳細描術清楚的需求，由需求分析人員對他們進行引導，必要時，有針對性的對他們進行軟件項目的相關知識培訓，讓客戶能夠更好的了解軟件項目開發知識，提高他們對開發高質量系統需求重要性的認識，從而能清楚表達自己的需求。

（3）為了能夠準確把握客戶的需求，只有語言、文字上的交流溝通還不夠，還需要通過成熟的項目進行演示，或搭建直觀易懂的項目需求模型，由有實際開發經驗的項目經理作為需求分析人員向客戶演示并詳細解說，減少客戶與分析人員對系統開發需求的理解偏差。若客戶在聽取需求分析人員的解說后，仍對項目需求仍存在理解上的分歧，需求分析人員可與客戶再進行深入交流和需求探討。

2、對客戶需求進行深入分析，達成共識

需求分析是項目管理的核心內容之一，準確、完整的需求分析是軟件項目成功的基礎。為了能夠得到客戶對需求的認可，要求項目需求分析人員能夠準確領會客戶的意圖，對客戶需求進行深入分析，完整的編寫需求分析文檔。通過召開會議的方式，組織雙方相關人員進行項目需求評審，向客戶詳細介紹系統功能的描述，讓客戶能充分理解說明書的內容，以形成全面、準確的需求說明文檔。

3、加強需求變更管理

對項目而言，出現需求變更是不可避免的，變更可能是由客戶、項目團隊或項目特殊原因引起的。項目變更控制和跟蹤，是項目開發的一項重要摘要的變更說明書，其內容包括：變更時間、變更內容、變更申請人、變更采取的措施等，并對變更內容及時進行跟蹤、確認。只有對需求變更進行有效的控制和跟蹤管理，才能有效保障項目的成功開發。

4、制定有效的溝通制度和機制，采取多種溝通方式

在項目需求開發階段，項目分析人員與客戶的有效溝通，是建立在彼此對需求達成一致的基礎之上的雙向互動過程。如果沒有一個良好的溝通渠道，項目將無法繼續開展。因此，項目經理有必要盡早建立一個完善的溝通網絡，制定有效的溝通制度，加強項目經理與成員、項目經理與客戶之間的雙向有效溝通。通過制度規定，對于特別重要的內容要采用多種方式進行有效溝通、確定，提高溝通意識及溝通的有效性，以確保信息能及時傳達到位。例如，除發送郵件外，還應電話提醒、傳真回執確認，對于特別重要的內容，要以召開會議的方式進行傳達。

（三）結束語

項目需求開發和管理是軟件項目開發中非常重要的工作內容，它貫穿于開發活動全過程。免費論文，需求變更。免費論文，需求變更。軟件項目的失敗大多數不是技術上、管理技能方面的原因，而是軟件需求開發與管理所致。免費論文，需求變更。免費論文，需求變更。可見，需求開發和管理在項目開發中起著及其關鍵的作用。免費論文，需求變更。因此，在項目需求階段，我們應系統的了解和掌握需求開發與管理的相關知識，結合項目實際情況并加以應用，做好需求的開發和管理工作，確保項目的順利完成。

[1]張文清.軟件開發過程項目管理的研究[D].北京:首者經濟貿易大學,2005

[2]屠梅曾、劉欣、胡昊編著.項目管理[M].上海:格致出版社:上海人民出版社，2008,192-193.

第5篇：項目需求分析范文

關鍵詞：軟件；需求；分析；開發；系統

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）22-5270-03

隨著計算機、信息等技術的發展，計算機被廣泛應用在各個行業中。各行業的管理與生產趨于信息化、數字化。使得與之相應的各種軟件更多更復雜，客戶對軟件的要求更加高。軟件產品是否能順利交付給客戶，是否能得到客戶認可，客戶是否能真正運用，是否能達到客戶的期望，這些與軟件需求分析有密切的聯系。為了提高軟件質量，就應該對軟件需求分析加以重視。

1 軟件需求分析任務

1.1 何謂軟件需求分析

先舉個例子來說明，對于裝修房子這個問題相信大多數人都能理解，客戶裝修房子要與裝修公司簽合同。在簽合同之前，裝修設計者一定會與客戶詳細討論各種細節。如整個裝飾格調？各個房間的功能？房間家具圖紙樣式等等，每個環節都有約定說明及裝修合同，雙方都明白假如完工后修改帶來的不便以及變更細節的危害性。同樣在軟件開發中也有這樣的過程即軟件需求分析。

軟件開發者要從客戶的工作業務中提取出軟件系統能夠幫助客戶利用計算機解決或更好解決的工作中各種問題。通過對客戶工作問題的分析，規劃出開發者所要開發的軟件。這些的活動階段即構成軟件開發生命周期的需求分析階段。

1.2 軟件需求分析的任務

軟件需求是指客戶對目標軟件系統在功能、行為、性能、設計約束等方面的期望。通過對應問題及其環境的理解與分析，為問題涉及信息、功能及系統行為建立模型，將客戶需求精確化、完全化。

軟件需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的“做什么”的問題。軟件需求分析的任務不是確定系統怎樣完成的工作，而是確定系統必須完成那些工作，也就是對目標系統提出完整、準確、清晰、具體的要求。

1.3 軟件需求分析的重要性

一方面：軟件需求分析對軟件具決定性。軟件開發出滿足客戶要求的軟件產品，就必須知道客戶的需求。需求分析就是分析軟件客戶的需要是什么，決定要什么。不能真正滿足客戶需要的軟件不是合格的軟件。

另一方面：軟件需求分析對軟件后期開發具方向性。需求分析可以讓軟件項目人員明確方向，讓項目成員知道下面步驟如何實施。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規格說明，為后續軟件開發工作指明方向，保證軟件開發在正常的軌道進行。

1.4 軟件需求分析的過程具體可分四個步驟

1）對問題進行識別；2）問題的分析與方案的綜合；3）編制軟件需求分析的相關文檔；4） 需求分析評審，對系統給予評價。

2 軟件需求分析過程中常見的問題及采取措施

軟件的需求與傳統生產企業產品需求相比較，具有模糊性、多變性和主觀性等特點，它不像生產汽車、電腦等硬件的需求，是有形的、客觀的、可描述的、可檢測的。軟件需求分析是軟件項目開發中難把握的問題。下面對軟件需求分析過程中常見問題進行分析后，給出相應措施來保證需求分析的質量：

2.1開發人員和客戶間交流與理解的問題

2.1.1 問題原因主要體現

1）軟件開發人員不可能是全才。對客戶應用領域的問題不是專家，對客戶的業務活動流程及業務環境不熟悉，認識不夠清楚、準確。

2）而客戶不熟悉計算機應用。有的客戶不太懂軟件，他們可能覺得軟件是萬能的，會提出一些根本無法實現的、不切實際的需求；有的客戶也可能覺得軟件不能解決工作中的問題，無法提出正確的需求。

3）軟件開發人員與客戶雙方所占位置不同。不了解對方的工作，對相同需求的認識有差異，交流時存在著理解上的不同。

2.1.2可采取的措施

1）對開發人員進行專業培訓。開發人員對所開發系統的領域不一定了解，為了使開發人員能更好理解用戶的需求，在做需求分析的初始階段對開發人員進行該領域相關知識的培訓。對開發人員盡快完整地熟悉相關業務，從而能夠站在客戶的立場看待軟件需求。

2）熟悉現有的處理系統的各個方面。熟悉客戶各崗位人員、工作環境、工作流程；確定各部分的需求調查對象；建立調研對象通訊錄以保證調研及分析期間的溝通。使需求調研分析更好更全面地進行。

3）所有客戶方進行溝通。需求分析不僅僅是軟件工程項目方的事，軟件客戶也起到了至關重要的作用。應當從項目的啟動開始，需求分析員及其項目成員就要分清項目客戶方包含哪些人和部門，通過溝通協調對他們施加影響，爭取所有客戶對軟件項目的支持和配合。

2.2需求不完整及完備程度的問題

2.2.1可能的原因

1）需求獲取時參與的客戶太少。需求調查時的對象數量不夠，獲取的客戶需求有限自然使得需求不夠完整。

2）客戶提出的需求是有限的。有的客戶因對計算機新技術、信息新技術了解不多，無法提隱含的或潛在的需求；有的客戶也不太明白自己的真正需求；有的客戶對問題的陳述往往是不完整。這些都使得獲取的需求不夠完整。

3）開發人員主觀性。開發人員主觀性為對客戶開發項目的需求明白，實際只是開發人員的主觀判斷。使得獲取的需求是片面的，不完整的。

2.2.2可采取的措施

1）讓更多的客戶參與軟件開發項目。得到客戶對項目的支持，調查并明確他們的需求和愿望。讓具有代表性的用戶在項目早期直接參與到開發隊伍中，并一同經歷整個開發過程。

2）收集整理資料，對各項業務全面分析。收集各項業務中的資料如：行業標準、工作手冊、作業流程、辦事指南、各種表格、技術資料等等。通過這些資料掌握對了解系統有幫助。對系統中的每項業務及流程要進行全面了解，幫助全面理解客戶需求。

3）深入挖掘潛在的需求，反復進行完善需求。主要對業務流程、組織架構、軟硬件環境和現有系統等相關內容進行溝通，挖掘系統中最終客戶的真正需要各需求，把握需求的方向。還要啟發客戶探討隱含的或潛在的需求，這樣可發激發他們提供更為完整全面的需求。

2.3軟件需求不一致性問題

2.3.1常見的原因

1）現實使用的系統的信息的不一致。正在使用的處理系統所反映的信息本身就不一致，自然使得獲取的需求不一致。

2）不同的客戶的需求不一致。不同的客戶站在不同的角度，對現實使用的系統認識理解不一致，對新系統具有不同的要求和期愿，故所得的需求不一致。如客戶中使用目標系統者關心系統是否簡單易用，而對客戶中的管理客者則關心系統是否高效。

3）相同的客戶的需求不致。相同的客戶對系統使用頻繁程度的差異、受教育程度和經驗水平也不盡相同，故所產生的需求不一致。

2.3.2可采取的措施

1）對各種不同客戶需要進行分類。項目早期就針對所有這些主要用戶進行分類，每一個客戶類將有自己的一系列功能和非功能要求。這樣就能從每一個重要的客戶類代表中獲取不同的需求。

2）對需求進行優先級排序。不一致的需求，那么必須決策出滿足哪一類客戶方的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與軟件項目目標的關系如何，將有助于決定哪一個客戶類所占份額更大來確定是關鍵與非關鍵客戶需求。這樣就對客戶需求進行優先級的排序。

3）軟件項目需求進行定位。軟件需求沒有簡單的對與錯，只能軟件需求需要從不同的地方、不同的角度去定位；去考慮；去分析。“ 需求分析”不能是“客戶要求什么就是什么”；也不是“我們能做什么就做什么”。用戶需求必須和業務需求一致，功能需求必須和用戶需求一致。嚴格的遵守不同層次間的一致性關系，才可以保證最后開發出來的目標軟件不會偏離最初的實現目標。

4）平衡需要對其分層次。需求人員，在進行需求分析的時候，首先應該明白客戶的需求，然后再加上自己的分析處理過程，將需求劃分成不同的層次如：哪些現在能做、現在哪些不能、哪些以后可以做，應當考慮全面并進行平衡和取舍。

2.4需求不明確、模糊的問題

2.4.1可能原因

1）客戶的認識的模糊。對于軟件系統，客戶很難精確地提出它的功能和性能要求。開始只能提出一個大概、模糊的要求，只有經過長時間的反復認識才逐步明確。

2）需求描述導致的需求模糊。需求描述的不清楚，或需求描述的方式方法可能使得不同的人對需求說明產生了不同的理解。

3）需求分解和細化程度不明確。軟件需求分析對問題按自頂向下、逐層分解的方式進行分解和細化。在分解和細化中，對橫向分解的寬度不明確；對對縱向分解的深度不明確。

2.4.2可采用措施

1）準確表達用戶需求，描述各項業務要詳細。對數據的具體業務來如查、增、刪、改、傳等若干步驟，都有其業務名稱，同一步驟可能對多個數據集進行不同操作需描述正確及詳細。準確地表達所接受的用戶要求，只有通過確切描述的軟件需求才能成為軟件設計的基礎。

2）編寫軟件需求文檔。盡可能全面詳細描述原有系統和客戶希望將來系統具有的各項業務流程，確定系統必須具有的功能和性能，定義了系統中的數據，簡略描述處理數據的主要算法，就要把分析的結果用軟件需求文檔記錄下來。軟件需求文檔是需求的載體，借助它與客戶進行討論，對描述不明確的模糊的需求進行修改，最終讓客戶確認。

3）組織從不同角度審查需求的隊伍對需求審查。按照技術標準，對需求分析階段工作進行審查。不同的評審者從不同的角度對需求說明給予解釋，讓每個評審人員都真正了解需求文檔，對需求文檔進行評審，以便發現問題，排除故障，及時改正錯誤。

4）與開發團隊中的其他小組成員協助明確需求。軟件開發中上一階段的工作成果往往要通過多次的溝通才能更為清晰地被下一階段成員接受，需求分析也是如此。需求文檔完成之后，借助這些對需求“固化”的文檔資料與其他項目組成員進行交流溝通，共同明確軟件項目需求。

5）需求分解和細化程度劃定。進行需求分析的時候，在理解客戶的需求上，對軟件與需求的寬度和深度有硬性的劃定。使軟件做到什么程度要劃定從而減少因分解和細化需求帶來的不明確和模糊。

2.5需求具有不穩定性，是動態變化的問題

2.5.1引起需求變更原因

1）客戶對軟件項目認識導致新要求，要求需求變化。開始沒有對問題識別全面，隨著客戶對這個軟件項目越來越深刻理解，就可能對軟件的系統的界面、功能、性能等提出新要求，導致需求變更。

2）客戶工作環境發生變化，要求需求變化。在軟件開發過程中，客戶業務流程簡化或流程增加，使得需求要發生改變；客戶工作中新設備、新技術出現，使需求變更。

3）客戶與軟件開發者溝通不夠，導致需求錯誤，需求必須改變。客戶與軟件開發者雙方對軟件項目的認識、理解有不同，加上雙方溝通不夠，使得對需求分析不正確，發生需求錯誤，使需求變更。

2.5.2可采用措施

1）對需求進行固態、動態的分類。我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產生變動的需求，考慮到它的可變性，這樣設計功能和數據庫的時候不致因為后面的變動而影響整個工程。

2）需求評審過程考進反復。評審是對軟件目標系統功能的正確性、完整性和清晰性，以及其他需求給予評價。需求評審過程進行反復，可以有效減少需求變更的發生。評審通過就可進入下一階段的工作。

3）評審中設立需求的基準線。需求評審中，與客戶方，軟件開發其他工作人員應該確定需求基準線。對軟件目標系統中必須的需求，可有可無的需求，完全沒有必要的需求進行劃分。這樣可以減少需求變更，也可以將變更引起的麻煩減至最小。

3 結束語

本文通過對軟件需求分析為主題，對軟件需求的任務、過程及重要性進行剖析，針對軟件需求分析過程中出現的常見問題進行一些探討，采取了一些可行的技術措施和管理措施來避免可能導致需求分析失敗的情況，提高軟件需求分析的質量，能圓滿地完成軟件需求分析任務，順利的進行軟件發開工作。

參考文獻：

[1] 張海藩.軟件工程[M].北京：人民郵電出版社，2007.

[2] 鄭人杰，殷人昆，陶永雷.實用軟件工程[M].北京：清華大學出版社，2003.

第6篇：項目需求分析范文

關鍵詞：軟件；開發；需求；分析

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2008)32-1125-04

The Study on Requirement Analysis in Software's Development

WU Zheng

(Anhui Family Planning School, Chizhou 247000, China)

Abstract: software requirement analysis is a decisive step of planning stage in software engineering, it changes unclear software concept into specific explainations in this step, thus,it establishes foundation of software development.This paper intoduces the requirement definition,types of the requirement, the mission of the requirement analysis, the method of the requirement analysis,the change of the requirement,and applied example etc. These intoductions will be helpful in requirement analysis of software’s development.

Key words: software; development; requirement; analysis

1 引言

軟件項目的開發主要分為五個階段：需求分析階段、設計階段、編碼階段、測試階段和維護階段，需求調研和分析是軟件開發的第一個階段。完善的軟件需求說明是軟件開發項目得以成功的基礎。不管設計如何精心或者編碼如何巧妙，如果對軟件需求不加以明確規定，將使用戶感到失望，并給軟件開發者帶來嚴重后果。據權威部門統計，目前軟件的成功率約為25%，75%的軟件是失敗的。在這75%的失敗中，約有50%以上的軟件是由于需求的原因造成的。另有資料表明，軟件開發項目中返工開銷幾乎占開發總費用的一半，而導致返工的主要原因是需求分析錯誤或不明確，從而引發項目開發中的一系列更改。成功的軟件需求分析不僅能提高軟件的成功率，而且能節省大量的資源，因此需求分析是軟件開發的關鍵階段。[1]

2 需求的定義和類型

2.1 需求的定義

軟件產業存在的一個普遍問題就是缺乏統一定義的名詞術語來描述我們的工作。客戶所定義的“需求”對開發者似乎是一個較高層次的產品概念，而開發人員所說的“需求”對用戶來說又像是詳細設計了。實際上，軟件需求包含著多個層次，不同層次的需求從不同角度與不同程度反映著細節問題。

IEEE軟件工程標準詞匯表（1997年）將需求定義為：

1) 用戶解決問題或達到目標所需的條件或能力。

2) 系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或能力。

3) 一種反映上面1)或2)所描述的條件或能力的文檔說明。

IEEE的定義包括從用戶角度（系統的外部行為），以及從開發者角度（一些內部特性）來闡述需求，其關鍵的問題是一定要編寫需求文檔。

另外，還有其他幾種關于“需求”的定義：

需求是用戶所需要的并能觸發一個程序或系統開發工作的說明；

需求是從系統外部能發現系統所具有的滿足于用戶的特點、功能及屬性等；

需求是指明必須實現什么的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。

從以上的定義中，我們依然無法得到有關“需求”的清晰概念，真正的“需求”實際上存在人們的腦海中，任何文檔形式的需求（例如：需求規格說明）僅是一個模型或一種敘述，但是編寫出高質量的需求規格說明書在需求分析階段還是關鍵。

需求分析奠定了軟件工程和項目管理的基礎。我們在建造軟件系統這座大廈的時候，如果需求分析的基礎不夠堅實和牢固，那么往往會導致軟件系統問題百出，甚至被馬上丟棄。在建造軟件系統的過程中，如果我們經常習慣地沿用一些不規范的方法，其后果便是產生一條鴻溝──開發者開發的與用戶所想得到的軟件存在著巨大的“期望差異”。 因此“需求”這個名詞的定義不僅僅是從用戶角度對系統外部行為的描述，以及從開發人員角度對系統內部特性的描述，其關鍵的一點是“需求”必須文檔化。

2.2 需求的類型

軟件需求包括三個不同的層次──業務需求、用戶需求和功能需求。

除此之外，每個系統還有各種非功能需求。

業務需求（BusinessRequirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。

用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。

功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知用戶已接受其預定”。功能需求描述是開發人員需要實現什么。

非功能需求（Non-functional Requirement） 定義了軟件產品為滿足用戶業務需求而必須具有的除功能需求以外的特性。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟件管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等。

3 需求分析的任務

3.1 解決的問題

1) 齊全、準確地找出目標系統全部的功能、性能、限制；

2) 找出全部的輸入流、輸出流；

3) 找出所有的加工；

4) 產生完整的分層的DFD、數據字典、加工的描述；

5) 補充的意見。

3.2 綜合要求

確定對系統的綜合要求，系統功能要求，系統性能要求，運行要求，將來可能提出的要求。

3.3 任務

圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經開發方和用戶認可或達成共識的軟件需求分析文檔（需求規格說明書、修改后的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書）。這個文檔能清晰準確地說明系統將要開發什么，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟件系統的接口。可以說需求文檔在開發過程中一直起指導作用。

為了更好地完成軟件開發第一階段的需求分析任務，提高質量，需求管理是必不可少的。

需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，并控制需求的變更，主要體現在跟蹤和控制需求變更管理。需求管理是開發工作有效進行的保證，是一種很高層次的系統行為，涉及整個開發過程和產品本身。

4 需求分析的方法

需求分析方法由對軟件問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的。信息域具有三種屬性： 信息流、信息內容和信息結構。

常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等。選擇那種方法要根據哪些資源在什么時間對開發人員有效，不能盲目套用。這里著重闡述面向數據流的結構化分析方法（SA）。[2]

4.1 面向數據流的結構化分析方法

面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動，該方法使用簡單易讀符號，根據軟件內部數據傳遞、變換的關系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用于數據處理類型軟件的需求分析，這一方法除了簡單，容易掌握之外，還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果。

4.2 自頂向下逐層分解的分析策略

SA方法的基本手段：“分解”和“抽象”。這是系統開發技術中控制復雜性的兩種手段。它先將系統“抽象”成一個模型，此模型是有輸入和輸出并有系統名稱的盒子，然后打開這個盒子，對它進行逐層分解，直到能被理解，可以實現為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。

4.3 結構化分析方法使用工具

SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分。描述工具是：

1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什么聯系等等。

2) 數據字典：定義了數據流圖中每一個圖形元素。

3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每一個加工。

由于分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析一般采用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書，該文檔包括一套數據流圖，對數據流圖中的成分進行定義的一本數據字典及對加工邏輯的描述。

4.4 結構化分析步驟

用結構化分析方法進行系統需求分析的具體步驟是：

1) 了解當前系統的工作流程，獲得當前系統的物理模型。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當前系統的理解，如畫系統流程圖。

2) 抽象出當前系統的邏輯模型。物理模型反映了系統“怎么做”的具體實現，去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統“做什么”的功能。

3) 建立目標系統的邏輯模型。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什么”，從而從當前系統的邏輯模型導出目標系統的邏輯模型。

4) 作進一步補充和優化。為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。

說明目標系統的人機界面。

說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等）。

其他（系統特有的其他必須滿足的性能和限制，也需要用適當的形式做出書面記錄。

分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的一些錯誤并及時糾正，直至用戶確認這個模型表達了他們的要求后，系統文件（軟件需求規格說明書等）才作為用戶和軟件開發人員之間的“合同”而最后得到確定。

4.5 結構化分析方法的優缺點

1) 優點： 結構化分析方法是軟件需求分析中公認的、有成效的、技術成熟的、使用廣泛的一種方法，它較適合于開發數據處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易于使用，為后一階段的設計、測試、評價提供了有利條件。

2) 缺點：① 傳統的SA方法主要用于數據處理方面的問題，主要工具DFD體現了系統“做什么”的功能，但它僅是一個靜態模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統。② 上世紀60年代末出現的數據庫技術，使許多大型數據處理系統中的數據都組織成數據庫的形式，SA方法使用DFD在分析與描述“數據要求”方面是有局限的，DFD應與數據庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合一樣)。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求。③ 對于一些頻繁的人機交互的軟件系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟件需求的精確性有待提高。

5 需求的變更

在開發項目過程中，用戶隨時會提出一些新的需求，要求開發方解決，這些需求的提出，有時在開發階段中有時在開發階段后。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結果與前一次不一致，我們把這種不一致稱為需求變更。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠。在需求分析階段，開發方與用戶沒有很好的交流，開發方就根據用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術更新過快。由于技術的快速更新， 企業可能引進一些新的設備， 而這些設備可能就會與我們的目標系統有直接的關系， 由于這一變化可能發生在解決用戶原先問題之前或者之中，那么開發方不得不加入這一新的需求。[3]

第7篇：項目需求分析范文

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

中圖分類號：TP311 文獻標識碼：A 文章編號：1674-7712 （2012） 18-0039-01

“軟件工程”這個名詞是1968年美國和西歐的一些科學家在NATO（北大西洋公約組織）會議上第一次提出的，是利用工程學的方法開發和維護計算機軟件的一門學科。本篇論文粗淺分析的是軟件工程中的需求分析。

軟件開發由需求分析、概要設計、詳細設計、編碼、軟件測試、項目維護和軟件集成幾部分內容組成。英文中有個全稱為CapabilityMaturityModelforSoftware，縮寫為SW-CMM，簡稱為CMM，用漢語表達出的意思就是——“能力成熟度模型”，也就是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。軟件開發被CMM的核心視為一個過程，并根據這一核心原則對其進行過程監控與研究，目的是更加科學化、標準化，在監督過程中發現影響項目的關鍵問題并予以解決，使企業能夠更好地實現商業目標。軟件開發人員開發和維護軟件及相關產品的一套行為、方法、實踐及變換過程被定義為軟件過程，它包括軟件開發過程和軟件管理過程。CMM把軟件開發機構按照不同開發水平劃分為5個級別，每個等級被分解為幾個KPA（關鍵過程域），KPA是指在某個成熟度等級應重點關注的區域，也是達到此成熟度等級必須解決的關鍵點。在CMM中成熟度第二等級有6個關鍵過程域，主要涉及建立軟件項目管理控制方面的內容。即：需求管理（RM）、軟件項目計劃（SPP）、軟件項目跟蹤與監控（SPTO）、軟件子合同管理（SSM）、軟件質量保證（SQA）、軟件配置管理（SCM）。

軟件項目管理中還有一個非常關鍵的步驟——需求管理。對于計算機系統的認識，很多用戶有很多盲區，對于系統的具體需求往往也比較模糊，經常出現疏漏或者是錯誤的問題，隨著項目的進展，凸現的會愈發明顯。對于開發人員來說，軟件產品的部分內容必須重新開發，這就意味著需求的變更。而對于整個軟件項目管理而言，勢必要重新分配資源、調整計劃、估算成本等等。需求分析的完整與否可以控制軟件質量、決定項目周期、增減項目成本。故而：需求管理工程越來越成為熱點。

需求獲取的正確性和有效性要求很高：角色的專業化、業務創新的復雜、交付速度等等。有時缺少特定需求的某些信息。在解決這個不確定性之前，可能必須與客戶商議，檢查與另一個系統的接口或者定義另一個需求。使用“待確定”符號作為標準指示器來強調軟件需求規格說明中的這些需求的缺陷。

設計一個軟件應用系統的起點與基本依據是需求分析。對用戶來講最重要的是有效性，高效性，靈活性，完整性，互操作性，可靠性，健壯性，可用性。對開發者來說最重要的是可維護性，可移植性，可重用性，可測試性。在屬性取舍方面，用戶和開發者必須確定屬性優先級，做決策時始終遵照優先級，為了達到產品特性的最佳平衡，必須在需求獲取階段識別，確定相關的質量屬性并為之確定優先級。當為項目定義重要屬性時利用屬性間正負關系圖可防止發生與目標沖突的行為。通常一個軟件項目合同的簽訂，體現的可能是整個系統的目標需求，面向用戶的需求往往被忽略，對于這種情況一定要注意需求更改的可控性。任何一個需求分析因客觀原因可能存在著需求更改的現象，要使受需求變化影響的產品與需求變更一致，就要建立需求的基準版本和更改版本，真正了解用戶想要解決的實際問題，即使需求的變更比較頻繁，也要注重需求的穩定性。直接影響到軟件過程的改進因素離不開需求分析的完整性和變更可控性，它不僅可以決定軟件的質量、開發成本的高低、甚至是導致項目成敗的關鍵。

需求管理員是軟件工程組（SEG）中要明確定義的一個角色。具體操作步驟有幾點：

第一：多角度全方位的對項目進行分析并且對項目的可行性進行論證；

第二：對客戶進行需求調研，整理客戶需求，負責編寫用戶需求說明書；

第三：負責將完成的項目模塊給客戶做演示，并收集完成模塊的意見；

第四：協助系統架構師、系統分析師對需求進行理解。

有了上述鋪墊，毋庸置疑的一個角色也要出場了，那就是——需求工程師。再好的軟件如果沒有做好需求分析也將失去市場意義，失去生存活力。需求工程師是溝通用戶與開發人員的橋梁，做好需求分析是一個產品是否能夠適應用戶要求的關鍵所在。需求工程師們在了解用戶又了解技術的基礎上掌控項目發展的風向標。

計算機軟件工程中的需求分析要解決的任務是"做什么"的問題，全面地理解用戶和開發人員的各項要求，準確表達所接受的需求。之所以重要，是因為它具有決策性、方向性、策略性的作用，從某種程度上說，它的作用可能并不小于程序設計，而且是提高軟件質量的基礎，也是決定一個軟件項目成敗的關鍵。

參考文獻：

第8篇：項目需求分析范文

關鍵詞：信息資源 ；查詢；數據流圖

一、 信息資源規劃

    信息資源規劃是指對企業生產經營所需要的信息，從采集、處理、傳輸到使用的全面規劃。在企業的生產經營活動中，信息的產生、流動和使用是非常頻繁的。

對于信息資源規劃的理解應該從五個方面出發：（1）一整套方法論；（2）標準和規范；（3）軟件支持工具系統；（4）整體解決方案；（5）一批成功案例。

    著名的信息資源規劃教授高復先用“信息孤島”來形容企業在實施信息化的過程中，使用不同的系統、不同的應用、不同的技術平臺進行不同的功能操作，從而使得各種資源難以流動、無法交流的現象出現。“因此，要想解決信息孤島的問題，就必須進行信息資源規劃，信息資源規劃的產生是大勢之趨，也是必然之舉。”高教授強調。

1、幫助理清并規范表達用戶需求，落實""應用主導""。

2、整合信息資源，消除""信息孤島""，實現應用系統集成。""

3、指導SCM、ERP、CRM等應用軟件的選型并保證成功實施。

在整個過程中，用戶是處在主導地位，需求分析工程師和開發人員負責整理用戶需求，為之后的軟件設計打下基礎。 從廣義上講：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理等一系列工程。 狹義上講：需求分析指需求的分析、定義過程。 需求分析就是分析軟件用戶的需求是什么。

需求分析的任務就是解決“做什么”，就是要全面地理解用戶的各項要求，并準確地表達所接受的用戶需求。需求分析階段的工作，可以分為四個方面:問題識別，分析與綜合，制訂規格說明，評審。

需求分析的方法有很多。這里只強調原型化方法， 原型化方法十分重要。原型就是軟件的一個早期可運行的版本，它實現了目標系統的某些或全部功能。該方法盡可能快地建造一個粗糙的系統，系統實現了目標系統的某些或全部功能，但是這個系統可能在可靠性，界面的友好性或其它方面上存在缺陷。

需求分析之所以重要，就因為它具有決策性、方向性、策略性的作用，它在軟件開發的過程中占有很重要的地位。在一個大型軟件系統的開發中，它的作用要遠遠大于程序設計。

    使用原型化方法有兩種不同的策略:廢棄策略，追加策略。廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改，形成比較好的思想，據此設計出較完整，準確，一致，可靠的最終系統。系統構造完成后，原來的模型系統就被廢棄不用。

客戶與開發人員交流需要好的方法。在需求分析的階段，同樣需要用到信息資源規劃的理論，例如：客戶的時間表不合理我們常常聽到客戶這樣說：“這是一個非常緊迫的任務，我們需要項目在X周內完成。”常見的錯誤是，沒有進行詳細分析，并了解項目的范圍以及完成項目所必需的資源，就同意客戶的要求。未經討論就同意不合理的時間表，這實際上是給客戶造成傷害：項目很有可能被延期（因為不可能按時完成），或存在質量問題（因為趕工，沒有進行適當的檢驗）。這時我們就要用信息資源規劃理論，把項目需求規范轉化成一個項目計劃、詳細的任務和各階段所需的資源，并為最佳情況、一般情況和最差情況建立模型。保證項目計劃考慮到有效資源的限制，并為檢測和質量檢驗保留足夠的時間。與客戶討論最終期限問題，用計劃草案中的數據為陳述提供證據。若計劃是合理的，則很有可能隨后的談判會極為成效，并對雙方有利。

二、 數據流圖

數據流圖（Data Flow Diagram），就是采用圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用于表示軟件模型的一種圖示方法。

三、小結

由此，在軟件開發的整個過程中，信息資源規劃起著相當重要的作用，資源規劃的好壞將直接影響項目的質量以及后期的維護工作，我們不可忽視。

參考文獻：

[1]高復先，信息資源規劃-信息化建設基礎工程，清華大學出版社，2008年

第9篇：項目需求分析范文

關鍵詞：工作過程；項目導向；情境教學

1.教學內容的組織

本課程基于四個學習情境開展教學，理論與實踐一體化，把所要掌握的理論知識貫穿于每個學習情境中，整個課程教學均在網絡實訓基地完成，每個學習情境圍繞一個教學項目，每個教學項目進行分解，開發和設計出若干個實訓項目，以學生為主體，在邊做邊教，邊做邊學，做到教、學、做一體。

序號學習情境學習單元教學內容學時分配1SOHO網絡構建SOHO網絡需求分析，規劃與設計建網方案如何根據實際項目進行需求分析，網絡拓撲結構設計、SOHO網絡設備選型、分類IP地址規劃，設計網絡建設方案36SOHO網絡布線實施、網絡連接與配置、網絡測試與驗收雙絞線制作、SOHO網絡設備連接、ADSL接入配置、網絡配置、網絡測試與故障排查、驗收文檔編寫32企業辦公網絡構建企業辦公網絡需求分析，規劃與設計建網方案如何根據實際項目進行需求分析，網絡拓撲結構設計、交換機設備選型、無類IP地址規劃、服務規劃224設計網絡建設方案2企業辦公網絡子網規劃、交換機安裝與配置子網規劃、VLAN的劃分2二層交換機的安裝與配置4三層交換機的安裝與配置6常用網絡服務的規劃、安裝與配置文件服務器的安裝與配置2DHCP服務器的安裝與配置2網絡測試與驗收全網連通性測試，故障排查，驗收文檔編寫43園區網絡的構建園區網絡構建需求分析，規劃與設計建網方案如何根據實際項目進行需求分析，網絡拓撲結構設計、交換機、路由器設備選型、無類IP地址規劃，設計網絡建設方案214園區路由器安裝與配置路由器的安裝與配置（包括靜態路由、RIP、OSPF、ACL配置）10園區網絡測試與驗收全網連通性測試，故障排查，驗收文檔編寫24校園網的構建案例實訓校園網的需求分析、校園網組網方案規劃與設計根據我院龍腰校區的實際情況和網絡需求進行分析、交換機與路由器設備的選型、規劃與設計組網方案2

12校園網組網實施交換機安裝與配置4路由器安裝與配置4校園網測試與驗收全網連通性測試，故障排查，驗收文檔編寫2

2、教學項目舉例

項目名稱：構建SOHO網絡                                所屬學習情境：SOHO網絡構建

實施場所：校內網絡技術實訓基地      課時：6課時        環境準備人員：實訓教師

指導教師：專任教師為主，兼任教師為輔                    評估小組成員：專兼教師、各小組組長

教學目標：

通過項目教學使學生了解SOHO網絡構建的工作流程，掌握SOHO網構建技能，能按項目需求構建小型網絡。具備SOHO網絡的規劃、設計與實施的能力及SOHO網絡的運維管理能力

學習任務：

根據SOHO網絡的構建項目要求，能對SOHO網絡的硬件需求，軟件需求分析，并根據軟硬件的選擇原則，能根據用戶需求做出合理的資金預算；能根據SOHO網絡布線標準，熟練制作雙絞線；能熟練完成SOHO網絡的連接，網絡配置，網絡測試及故障的排查方法；能按項目需求很好地完成構建SOHO網絡建設方案并實施項目

實施環境要求：

每組學生3-4人，每組實踐平臺要求：3-4臺計算機，[一臺modem、一臺ADSLmodem]。材料準備：雙絞線、水晶頭、RJ45壓線鉗、交換機/集線器（每組一臺）、網卡（每機一張）

項目說明：

項目場景介紹

現有一個辦公室，共有四臺電腦，要求連接成網絡，相互之間能相互通信及文件和打印共享，同時有一臺電腦能支持遠程桌面功能。（如果環境允許的話，可設計完成與Internet網絡的連接）

需求分析

（1）連接四臺計算機

分析：采取什么拓撲結構，需要什么網絡設備，如何聯接

（2）能相互通信

分析：如何安裝網絡軟件，如何設置網絡屬性，如何測試能否相互通信

（3）能共享文件與打印資源

分析：如何設置文件與打印資源，如何訪問網絡資源？

*（4）訪問Internet網絡

分析：有幾種連接方法？采用哪種連接方法訪問Internet性價比最高？為什么？

項目教學過程：

將學生進行分組實施項目，每組指定一個小組長，每組4—6人，一個實驗平臺，按照項目的 “資訊、計劃、決策、實施、檢查、評估” 六個工作過程環節來開展教學，實現邊做邊學，從做中學。

（1）資訊

教師給出項目，分析項目建設需求，讓學生明確這個教學項目要完成的任務。

（2）計劃

要求小組長組織小組成員對項目說明進行討論、分析，制定建網初步方案。

（3）決策

確定網絡構建方案，畫出網絡拓撲圖，并由小組長安排小組成員工作任務，明確項目實施的步驟及完成的時間。

（4）實施

小組成員按方案和工作任務安排進行項目實施。

（5）檢查

項目實施完成后，小組成員進行訪問測試，看能否達到項目預期目標，如果未達到要求，則組織小組成員進行故障分析和排除，并記錄排障日志。

（6）評估

項目經過自己檢查，提交給評價小組進行驗收，評價小組將對項目的各項功能進行測試，評分，并要求小組提交所有的項目過程材料（包括方案和排障日志）

整個教學過程，以學生為主體，教師從中指導，實現與學生的互動，回答和解釋學生提出的疑問，從而讓學生學習到該教學項目所應該掌握的部分知識內容。

教學項目驗收標準：

（1）組網方案合理、描述條理清晰、內容完整、方案設計性價比高（30%）

（2）網線制作規范和連接規范（10%）

（3）各主機是否配置正確，IP地址規劃合理，能實現四臺主機相互通信，并能相互共享網絡資源（40%）

（4）過程表現情況及團隊合作情況（20%）

（5）是否選擇最優連網方式，連接設置正確，能成功連接Interne

3、結論

本課程依據網絡技術專業高職生的培養目標、企業職業崗位的任職要求，針對網絡構建崗位的主要工作任務的工作過程所應具備的基本工作能力，進行教學內容的選取，整個課程的教學內容強調實踐教學，重于強化專業技能的培養，同時網絡組建必須要求掌握的知識與技術貫穿于教學項目中，通過實踐教學加深對理論知識的理解，通過綜合項目的工作過程教學培養學生的崗位技能、團結協作能力及解決實際問題的能力，大大縮短校企之間的距離，使學生能根據企業的場景，企業用戶的需求，完成企業網絡的規劃、設計和實施的能力。具有一定的針對性和適用性，為學生上崗和持續發展奠定良好的基礎。

參考文獻：