項目的需求分析怎麼寫?
項目需求分析怎麼寫
項目需求分析的概念 需求分析是指理解用戶需求，就軟件功能與客戶達成一致，估計軟件風險和評估項目代價，最終形成開發計劃的一個複雜過程。（這個和我在微軟體驗到的又不太一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中，用戶的確是處在主導地位，需求分析工程師和項目經理要負責整理用戶需求，為之後的軟件設計打下基礎。需求分析階段結束後，要求得到：1.SRS文檔(System Requirement Specificatio鄲); 2.DRM 文檔；3.Acceptance Plan. 從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解：需求分析指需求的分析、定義過程。 一、為什麼要需求分析 需求分析就是分析軟件用戶的需求是什麼.如果投入大量的人力，物力,財力,時間,開發出的軟件卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發一個軟件,最後卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾首的.(相信大家都有體會)比如,用戶需要一個for linux的軟件,而你在軟件開發前期忽略了軟件的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發for windows的軟件,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候你是欲哭無淚了,痕不得找塊豆腐一頭撞死.
需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用,他在軟件開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的重視.在一個大型軟件系統的開發中,他的作用要遠遠大於程序設計. 二、需求分析的任務 簡言之,需求分析的任務就是解決"做什麼"的問題,就是要全面地理解用戶的各項要求,並準確地表達所接受的用戶需求.三、需求分析的過程 需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂規格說明,評審.
問題識別
就是從系統角度來理解軟件,確定對所開發系統的綜合要求,並提出這些需求的實現條件,以及需求應該達到的標準.這些需求包括：功能需求(做什麼),性能需求(要達到什麼指標),環境需求(如機型,操作系統等),可靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求(軟件運行是所需的內存,CPU等),軟件成本消耗與開發進度需求,預先估計以後系統可能達到的目標.
分析與綜合
逐步細化所有的軟件功能,找出系統各元素間的聯繫,接口特性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分.最後,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什麼的模型).
制訂規格說明書
即編制文檔,描述需求的文檔稱為軟件需求規格說明書.請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問題),向下一階段提交.
評審
對功能的正確性,完整性和清晰性,以及其它需求給予評價.評審通過才可進行下一階段的工作,否則重新進行需求分析。 四、需求分析的方法 需求分析的方法有很多.這裡只強調原型化方法,其它的方法如:結構化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從來沒用過這些方法)在此不討論.
原型化方法是十分重要的(是軟考等常考的知識點).原型就是軟件的一個早期可運行的版本,它實現了目標系統的某些或全部功能.
原型化方法就是儘可能快地建造一個粗糙的系統,這系統實現了目標系統的某些或全部功能,但是這個......
軟件的需求分析怎麼寫啊？
1. 引言
1.1 編寫目的:編寫此文檔的目的是進一步定製軟件開發的細節問題,便於用戶與開發商協調工作.本文檔面向的讀者主要是項目委託單位的管理人員.希望能使本軟件開發工作更具體.
1.2 項目背景
1.2.1項目委託單位:****公司
1.2.2開發單位:***公司
1.3 定義
1.4 參考資料
2. 任務概述
2.1 目標:
<1> 決策支持:根據公司的要求及時提供所需報表及文件,並在適當時候對各部門領導給予銷售及進貨等方面的提示
<2>提高效率:利用軟件進行管理,避免人工管理的失誤以及 延遲性,從而實現高效率的管理.
2.2 運行環境:
<1> 硬件方面:Pentium級處理芯片
1兆顯存的兼容顯卡
256色,800*600的兼容顯示器
標準兼容打印機
<2>軟件方面: WIN95操作系統
2.3 條件與限制:
編程用計算機一臺
完成期限2000/7/1
無資金供給
3. 數據概述
數據流程圖如下:
3.1 靜態數據:包括系統登錄密碼,各數據庫所在位置,系統分析原始數據
3.2 動態數據:包括各數據庫內各項顯示數據,用戶登錄信息,系統時間
3.3 數據庫描述:
人事管理數據庫:公司內人員的個人詳細信息,包括檔案信息
銷售管理數據庫:當日銷售記錄及以前的銷售統計,用於銷售分析
財務管理數據庫:公司內部賬目及收支情況詳表
技術管理數據庫:公司所需各技術檔案的詳細記錄(包括文檔)
3.4 數據字典:
<1>數據流詞條描述:
1.數據流名:登錄信息
來源:用戶的輸入
去向:系統內部檢驗部分
組成:用戶名,密碼
流通量:每次登錄輸入一次
2.數據流名:登錄結果
來源:系統
去向:用戶
組成:返回信息
流通量:每次登錄返回一次
3.數據流名:輸入修改信息
來源:用戶
去向:系統判斷部分
組成:根據各數據庫內容而不同
流通量:依用戶輸入而定
4.數據流名:反饋信息
來源:系統判斷部分
去向:用戶
組成:系統經判斷後發回的字符數據
流通量: 依系統當前信息而定
5.數據流名:識別信息
來源:系統內部檢驗部分
去向:系統判斷部分
組成:系統各數據庫的標識信息
流通量:用戶每次輸入流通一次
6.數據流名:處理信息
來源:系統判斷部分
去向:各數據庫處理部分
組成:讀取/修改標識,讀取/修改的變量名稱
流通量:用戶每次輸入流通一次
7.數據流名:讀取修改
來源:系統判斷部分
去向:系統各數據庫
組成:讀取/修改標識,讀取/修改內容
流通量: 用戶每次輸入流通一次
<2>數據文件詞條描述:
1.數據文件名:人事數據
簡述:存儲人員信息
數據文件組成:人員的各項信息(以CString類型為主)
2.數據文件名:銷售數據
簡述:存儲當日及從前的銷售記錄
數據文件組成:銷售的各項信息
3.數據文件名:財務數據
簡述:存儲財務管理信息
數據文件組成:財務管理的各項記錄
4.數據文件名:技術數據
簡述:存儲公司內部使用的技術檔案信息
數據文件組成:技術檔案名稱,內容
<3>加工邏輯詞條描述:
1.加工名:檢驗
......
項目目標與任務需求分析應該怎麼寫？
項目目標與任務需求分析=項目的目標和任務，目標和任務是什麼就寫什麼了
項目需求報告要怎麼寫？
聽棠的“客戶需求何時休”深刻的披露了這個問題存在的根源。需求分析，不僅僅是拿到客戶的需求，更重要的是還需進行分析，瞭解細節，並就細節跟客戶諮詢，獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題並不在他們考慮的範圍之內，如果作為項目承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。聽棠所說到的幾點，感受特別深：“其實問題出在開頭，客戶需求只是軟件需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析”還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這裡的矛盾，而這些問題，如果在期初時，軟件負責人不分析，而是純粹的“聽從”客戶要求去做，當暴露這些問題時，你怪客戶也沒用啊。項目需求分析報告，在瞭解客戶需求時，不要不動腦子，不要一味的點頭說“I C”，其實在表面的業務裡面可能包含著N多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓項目越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣瞭解客戶需求未免太麻煩了。至於一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，後面的變動也將在邏輯上變動，相信代價已經不會那麼大了。這其實也體現了系統的擴展性。需求分析，是一個項目提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的製造者，在系統製造過程中，只有雙方相互配合，共同對系統進行設計才能最後達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的瞭解，但是，對於軟件需求方面的描述是不瞭解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常複雜的。我們拿到客戶需求後，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，並減少後期的修改。
如何做需求分析
隨著技術的不斷髮展和用戶對網站功能性的需求不斷提高，如今網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創作相比，網站項目的設計和開發越來越像一個軟件工程，也越來越複雜，網站項目的設計和開發進入了需要強調流程和分工的時代，建立規範的、有效的、健壯的開發機制，才能適應用戶不斷變化的需要，達到預期的計劃目標。
網站項目管理（WPM）的含義為Web-based Project Management，即以Web 應用程序為主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網絡和Web
服務器等關鍵主體，主要體現在網站設計、以瀏覽器為客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關係管理。）等項目管理中。
按照筆者的經驗，網站項目管理可以分為以下l六個階段進行控制：
1. 需求分析及變更管理
2. 項目模型及業務流程分析
3. 系統分析及軟件建模
4. 界面設計、交互設計及程序開發
5. 系統測試和文檔編寫
6. 客戶培訓、技術支持和售後服務
需要說明的是，這些階段雖然具有一定的延續性，但是並非完全隔斷的，例如需求變更管理和測試工作、文檔編寫都是貫穿整個項目過程的，許多工作時交叉進行或同時進行的。
（一）如何做好需求分析及變更管理？
業務員與客戶進行的溝通，撰寫需求分析報告是項目展開的基礎。項目是以客戶的需求為中心，而不是為技術而遷就需求。
一：讓客戶暢所欲言，羅列出所有的需求
讓用戶將所有的想法儘可能的闡述清楚，並把所有的要求羅列出來，不要遺漏。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發的工作量，從而被今後客戶無止境的變更拖入泥潭，直接明白地跟客戶把問題和要求一條條地列出來，把條理、歸納、分析先都扔到一邊去，將用戶最原始、最完整的要求準確地記錄下來就完成了第一步的工作。
很明顯，假如客戶的需求做的都不完整，隨時可能會產生意想之外的變更，甚至這個變更會破壞已經做的模型及結構，那麼這個項目從開始就註定了會失敗；比如站點所有的功能都實現了，本地測試起來也沒有什麼問題了，但是你卻不知道客戶的系統是要承受每天100萬獨立IP的訪問，而你原來想當然的以為了不起就是1萬獨立IP訪問的訪問流量，稍微有經驗的開發人員都會明白這樣的設計是個災難，無論是應用服務器、數據庫還是程序全部要重新開發！
二：透過現象分析潛在的需求
很多情況下客戶並非專業人士，在他們滔滔不絕的描述中不能指望他們幫助我們整理出重點和技術難關，這需要我們去為客戶進行分析、歸納和整理，尤其是客戶談的不多卻又是技術上實現難度和強度很高的地方特別值得注意。
客戶往往對需求的概念是非常模糊的，大多時候給出的需求都是籠統而且尺度難以控制的，這就要求業務人員在傾聽了客戶的詳細說明以後，幫助客戶進行整理和分析，同時預測客戶在開發過程中變更及今後應用中可能進行修改升級的潛在需求。
比如在為客戶設計辦公自動化系統的時候，也許就要為客戶預留將來與他們的業務單位進行交互的通道；在設計郵件系統的時候要考慮可能會需要廣告管理服務器；設計網絡電子商店時今後增加庫存產品進銷存統計分析等等；限於時間財力的考慮，客戶通常能夠接受分階段實施的開發過程，在需求分析時，提早為客戶設想到今後的需求變更除了使項目開發更加順利以外，也為今後業務的進一步深入打下......
做程序，項目需求分析，一般做多久。
國內很多老一輩的根本不注重這一點。但國外的，很小的開始實戰寫需求了。因為他們一直認為需求是相當重要。每次都做項目前都是，亂七八操的需求分析，像個草搞。偶爾做一下，改一下。改一下需求，那麼，原來的框架，編碼都要改。而我同學他們的雖然做需求做了一個月多，但卻是按需求很順利的一氣搞定。我問的是：無論是多大，還是多小的項目，都要把需求寫清楚再做。
java 項目需求文檔要怎麼寫？
需求文檔一般分兩類
需求調研報告
需求分析報告
調研報告：是記錄的用戶的原始需求，基本上可以算做是和用戶溝通的原始記錄。
分析報告：是對調研報告進行歸類分析的結果。一個比較全面的文檔了，在這個文檔裡面一般包含以下內容：
項目的背景
項目的目標
項目的範圍
用戶特點
相關技術、規範標準等
相關約束
用戶的組織結構、角色等
用戶需要的功能點，這些功能的優先級，業務流程、功能特點，有沒有特殊需求等等
總而言之，需求分析報告的下一站是給設計人員的，設計人員看到需求分析報告就知道系統應該包含哪些功能點、權限設計、流程設計等，這些內容都可以直接從需要分析報告裡面得出