項目需求分析_需求分析應該由誰來做？ _生活經驗

項目需求分析文檔都包括哪些內容？需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個復雜過程在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之后的軟件設計打下基礎。需求分析階段包括：

項目需求說明書,怎么寫一：引言
1、編寫目的：說明編寫這份項目需求說明書的目的，指出預期的讀者。
2、背景說明：待開發的軟件系統的名稱。本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡。該軟件系統同其他系統或其他機構的基本的相互來往關系。
3、定義
列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。
4、參考資料
列出用得著的參考資料，項目相關的計劃書，或者合同，批文之類的。
二：任務概述
1、目標
敘述該項目開發的意圖、應用目標、作用范圍以及其它應向讀者說明的有關該軟件開發的背景材料。解釋被開發軟件與其它有關軟件之間的關系。如果本軟件產品是一項獨立的軟件，而且全部內容自含，則說明這一點。
2、用戶的特點
列出本項目的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟件的預期使用頻度。這些是軟件設計工作的重要約束。
3、假定和約束
列出進行本軟件開發工作的假定和約束，例如經費限制、開發期限等。
三：需求規定
1、對功能的規定
用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經怎樣的處理、得到什么輸出，說明軟件應支持的終端數和應支持的并行操作的用戶數。
2、對性能的規定：精度說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。時間特性要求：說明對于該軟件的時間特性要求。
四：運行環境規定
1、設備
列出運行該軟件所需要的硬件設備。說明其中的新型設備及其專門功能。
2、支持軟件
列出支持軟件,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟件等。
3、接口
說明該軟件同其他軟件之間的接口、數據通信協議等。
4、控制
說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源。
五數據要求
數據的邏輯描述：
對數據進行邏輯描述時可把數據分為動態數據和靜態數據。所謂靜態數據，指在運行過程中主要作為參考的數據，它們在很長的一段時間內不會變化，一般不隨運行而改變。所謂動態數據．包括所有在運行中要發生變化的數據以及在運行中要輸入、輸出的數據。進行描述時應把各數據元素邏輯地分成若干組，列如函數、源數據或對于其應用更為恰當的邏輯分組。給出每一數據元的名稱（包括縮寫和代碼）、定義（或物理意義）度量單位、值域、格式和類型等有關信息。

文章插圖
擴展資料需求分析也稱為軟件需求分析、系統需求分析或需求分析工程等，是開發人員經過深入細致的調研和分析，準確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什么的過程。
參考資料百度百科-需求分析
怎么做項目需求分析報告做項目真辛苦阿！這樣的感嘆整天都掛在口上。客戶需求變動確實是一個軟件開發永遠不變的話題。為什么小的軟件企業面對經常變動的需求是如此的狼狽？到底要怎么做才能滿足客戶的需求？聽棠的“客戶需求何時休”深刻的披露了這個問題存在的根源。需求分析，不僅僅是拿到客戶的需求，更重要的是還需進行分析，了解細節，并就細節跟客戶咨詢，獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題并不在他們考慮的范圍之內，如果作為項目承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。聽棠所說到的幾點，感受特別深： “其實問題出在開頭，客戶需求只是軟件需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析” “客戶本身是不怎么懂技術的，客戶只知道自己的業務需求，而在軟件設計時，是在把業務需求抽象到系統中實現的，把業務轉變為邏輯時，一切都應該符合邏輯的，但客戶的業務思想有時候在軟件系統實現時會有問題的，這就需要分析時分析出來的。少了分析，問題也會在后面的開發中暴露出來，到時可就更麻煩了。” 還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這里的矛盾，而這些問題，如果在期初時，軟件負責人不分析，而是純粹的“聽從”客戶要求去做，當暴露這些問題時，你怪客戶也沒用啊。項目需求分析報告，在了解客戶需求時，不要不動腦子，不要一味的點頭說“I C”，其實在表面的業務里面可能包含著N多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓項目越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣了解客戶需求未免太麻煩了。至于一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，后面的變動也將在邏輯上變動，相信代價已經不會那么大了。這其實也體現了系統的擴展性。需求分析，是一個項目提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的制造者，在系統制造過程中，只有雙方相互配合，共同對系統進行設計才能最后達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的了解，但是，對于軟件需求方面的描述是不了解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常復雜的。我們拿到客戶需求后，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，并減少后期的修改。
java項目需求分析怎么寫需求文檔一般分兩類：需求調研報告、需求分析報告
調研報告：是記錄的用戶的原始需求，基本上可以算做是和用戶溝通的原始記錄。
分析報告：是對調研報告進行歸類分析的結果。一個比較全面的文檔了，在這個文檔里面一般包含以下內容：項目的背景、項目的目標、項目的范圍、用戶特點、相關技術、規范標準等。相關約束、用戶的組織結構、角色等用戶需要的功能點，這些功能的優先級，業務流程、功能特點，有沒有特殊需求等等
總而言之，需求分析報告的下一站是給設計人員的，設計人員看到需求分析報告就知道系統應該包含哪些功能點、權限設計、流程設計等，這些內容都可以直接從需要分析報告里面得出
項目需求該怎么寫如果是一個軟件系統的項目，站在項目角度需求管理包括項目需求、用戶需求、業務需求、功能需求、非功能需求等內容。而項目管理文檔中主要是項目需求，在項目實施文檔中主要是用戶需求分析報告、軟件（或系統）需求規格說明書等。項目需求主要包括：（不同的項目還會有適當增減，由于不清楚你的項目具體情況，所以把總體上項目需求包括的內容都羅列一下）

項目目標與任務需求分析應該怎么寫？項目目標與任務需求分析=項目的目標和任務。
目標是具體可量化的,由目的而生,計劃是達成目的的籌劃,而任務就是計劃中的每個完成點一般先有目的,再有計劃,后有目標,用任務完成目標
項目目標（Project Objectives）：簡單地說就是實施項目所要達到的期望結果，即項目所能交付的成果或服務。項目的實施過程實際就是一種追求預定目標的過程，因此，從一定意義上講，項目目標應該是被清楚定義，并且可以是最終實現的。項目目標包括：可測量的項目成功標準。項目可能有各種各樣的經營，費用，進度，技術和質量目標。項目目標可能還包括費用，進度和質量指標。每一個項目目標都有屬性，例如費用目標就有美元單位或人民幣單位。
【項目需求分析_需求分析應該由誰來做？】需求分析：開發人員準確地理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的需求規格說明的過程。
基本任務: ⑴問題識別：雙方確定對問題的綜合需求，這些需求包括功能需求，性能需求，環境需求，用戶界面需求。
⑵分析與綜合，導出軟件的邏輯模型
⑶編寫文檔：包括編寫"需求規格說明書","初步用戶使用手冊","確認測試計劃","修改完善軟件開發計劃"需求分析應該由誰來做？一般情況下來說，需求分析是由產品經理或者項目經理提出來的。而不是通過研發人員或者是測試人員來做。
產品經理一般是被劃分在產品部或者是市場部門，這兩個職能部門一般情況下更為了解客戶需求以及市場行情。而項目經理呢，會有著相對豐富的資源，可以從別的部門找來相應資源來進行整合，故此如是。
另，很多工業公司或者是IT公司，走的都是這個架構。樓主可以有時間研究一下IT公司的架構，如SAP, Oracle, Peoplesoft, Cisco 和騰訊， Ali 的架構。
希望能有所幫助
擴展
謝謝你的回答，我想問的是需求分析的這個階段，也就是你指的產品部或市場部整理的需求到研發轉成概要設計之間的這個階段，這個階段是應該產品部或市場部直接交由研發進行分析，還是應該在測試先進行一輪需求分析，然后交由研發進行概要設計。
PS：這方面的流程和負責人有么有專業的理論支持，例如CMMI流程等

補充
應該是由研發進行需求分析在進行概要設計。CMMI流程應該是套用在整個項目開始的階段一直貫穿到項目結束。理論支持，是看貴公司產品的業務大?。?如果項目比較龐大，是需要相關人士進行流程支持。