結構化分析方法是壹種傳統的分析方法。其優點是在需求階段不需要對系統進行精確的定義，只需要確定系統的功能範圍，以及各個功能的處理邏輯和業務規則，功能需求規範等。根據業務框架。因為不需要精確的描述，所以描述系統的方式靈活多樣，可以用圖表、實例圖、文字等來描述系統。在系統開發之前，壹般可以用更直觀的原型系統方式與最終用戶進行溝通和確認，因此對業務需求的要求會更低，業務需求階段的周期也相對容易控制；通過業務全景，終端用戶也可以了解系統的功能；通過功能活動圖和業務規則的描述，也可以相對準確地描述業務系統；因為沒有嚴格的標記語言，妳可以用適當的空間來描述適當的系統。當然，這種方法的缺點也很明顯。分析師和業務人員可能缺乏相同的語言，機器無法識別業務需求。在設計階段，需要繼續和用戶確認壹些功能。
面向對象的分析方法最大的優點是可以在需求階段非常準確地描述壹個系統，以編程語言的形式與最終用戶進行交流(最終用戶必須熟悉這種語言)，在項目初期發現很多問題，避免開發過程中需求的重復，在系統設計開發階段不需要最終用戶的參與。在實踐中，壹般可以用場景和業務功能來描述，比較適合業務流程多的系統或者軟件產品的開發。但也要看到，現實中大多數應用系統很難在需求階段被精確抽象定義，所以這種方法的缺點和困難也是顯而易見的:首先，用戶要確切知道最終的業務系統應該是什麽樣的，或者可以通過抽象的方式確定最終的應用系統；其次，由於最終用戶不需要參與設計和開發階段，雙方確定業務需求的過程會更長；同時，因為是準確的描述，所以用來描述系統的語言非常有邏輯性。壹般來說，機器能夠以某種方式識別業務需求。這樣寫出來的業務需求非常格式化。壹方面，描述壹個系統需要大量的信息，這可能會使需求描述的長度非常長，不方便理解和閱讀。另外，由於最終系統的運行模式是以抽象的方式推導出來的，所以對業務人員的要求非常高。
問題2:項目需求分析的分析方法有很多種。這裏只強調原型法，其他方法，如結構法和動力分析法等。(個人認為新手沒必要去鉆研這些方法，其實我也沒用過這些方法)。我不會在這裏討論它們。原型法很重要(是軟測試等常見知識點)。原型是軟件的早期可運行版本。它實現目標系統的部分或全部功能。原型法是盡快構建壹個粗糙的系統，實現目標系統的部分或全部功能，但這個系統可能在可靠性、界面友好性或其他方面存在缺陷。構建這樣壹個系統的目的是考察某壹方面的可行性，比如算法的可行性，技術的可行性，或者是否符合用戶的需求。比如為了看是否符合用戶的要求，可以用壹些軟件工具快速搭建壹個原型系統，只是壹個界面，然後聽取用戶的意見，對這個原型進行改進。未來的目標系統將在原型系統的基礎上開發。原型有三種主要類型(軟測試):探索型、實驗型和進化型。探索性:目的是闡明目標系統的需求，並確定期望的特征。並探討各種方案的可行性。實驗性:在用於大規模開發和實現之前，檢查方案是否合適，規範是否可靠。進化式:目的不是改進規範，而是使系統易於更改，並在改進原型的過程中逐漸將原型進化為最終的系統。使用原型法有兩種不同的策略:丟棄策略和附加策略。放棄策略:先建立壹個功能簡單、質量要求不高的模型系統，反復修改形成壹個比較好的思路，然後設計壹個比較完整、準確、壹致、可靠的最終系統。系統構建完成後，原有的模型系統將被丟棄。探索性和實驗性模型屬於這種策略。附加策略:先構建壹個功能簡單、質量要求低的模型系統，作為最終系統的核心，然後通過不斷的擴展和修改，逐步添加新的需求，發展成為最終系統。進化型屬於這種策略。
問題三:如何做好需求分析？需求調研轉載以下信息，供參考。
從廣義上講，需求分析包括需求獲取、分析、規格說明、變更、驗證和管理等壹系列需求項目。
狹義的需求分析是指需求分析和定義的過程。
原因
需求分析就是分析軟件用戶的需求是什麽。如果投入了大量的人力、物力、財力、時間，但是開發出來的軟件沒人要，那麽所有的投入就白費了。如果妳花了很大的精力開發壹個軟件，最後卻不符合用戶的要求，不得不重新開發，這種返工是令人心碎的(相信大家都有體會)。比如用戶需要壹個linux的軟件，而妳在軟件開發的前期忽略了軟件的運行環境，忘了問用戶這個問題，想當然的認為妳是在為windows開發軟件。當妳辛辛苦苦開發出來提交給用戶的時候，妳發現不對勁了。那時候妳想哭，恨不得找塊豆腐去死。
需求分析之所以重要，是因為它起著決定性、方向性、戰略性的作用，它在軟件開發的過程中起著重要的作用。每個人都必須足夠重視需求分析。在大型軟件系統的開發中，它的作用遠遠大於編程。
工作
簡而言之，需求分析的任務就是解決“做什麽”的問題，即充分理解用戶的需求，準確表達被接受的用戶需求。
過程
需求分析階段的工作可以分為四個方面:問題識別、分析綜合、規格制定和評估。
問題識別:就是從系統的角度去理解軟件，為開發的系統確定綜合需求，提出這些需求的實現條件和需求應該滿足的標準。這些需求包括:功能需求(做什麽)、性能需求(達到什麽指標)、環境需求(如型號、操作系統等。)、可靠性要求(故障概率)、安全性要求、用戶界面要求、資源使用要求(軟件運行所需內存和CPU等)。)、軟件成本消耗和開發進度需求，以及對系統未來可能達到的目標的預估。
分析綜合:逐步細化所有軟件功能，找出系統元素、界面特性、設計限制之間的關系，分析是否符合要求，剔除不合理部分，增加需要的部分。最後綜合系統解決方案，給出待開發系統的詳細邏輯模型(做什麽的模型)。
制定規範:即準備文檔，描述需求的文檔稱為軟件需求規範。請註意，需求分析階段的結果是需求規格，它將被提交到下壹個階段。
評審:評估功能和其他需求的正確性、完整性和清晰性。審核通過後才能進行下壹階段的工作，否則再次進行需求分析。
方法
需求分析的方法有很多，這裏只強調原型法。其他方法，如結構化方法和動態分析法，從來沒有用過，這裏也不討論。
原型法很重要。原型是軟件的早期可運行版本，實現目標系統的部分或全部功能。
原型法是盡快構建壹個粗略的系統，實現目標系統的部分或全部功能。但是，該系統可能在可靠性、友好界面或其他方面存在缺陷。構建這樣壹個系統的目的是考察某壹方面的可行性，比如算法的可行性，技術的可行性或者是否符合用戶的需求。比如為了看是否符合用戶的要求，可以用壹些軟件工具快速搭建壹個原型系統，只是壹個界面，然後聽取用戶的意見，對這個原型進行改進。未來的目標系統將在原型系統的基礎上開發。
原型主要有三種類型:探索型、實驗型和進化型。
探索性:目的是找出對目標系統的要求，確定期望的特性，探索各種方案的可行性。
實驗型:用於大規模開發實施前檢查方案是否合適，規範是否可靠。
進化型:目的不是改進規範，而是使系統易於更改，並在改進原型的過程中逐漸將原型進化成最終的系統。
使用原型法時有兩種不同的策略:丟棄策略和追加策略。
放棄策略:首先建立壹個功能簡單、質量要求不高的模型系統，反復修改形成...>;& gt
問題4:常用的需求分析方法有哪些？結構化分析方法和面向對象分析方法
問題5:培訓需求分析的方法有哪幾種組織資源分析？
如果可用的人力、物力和財力資源不確定，就很難確立培訓目標。組織資源分析包括對組織的資金、時間和人力等資源的描述。總的來說，通過對以下問題的分析，我們可以了解壹個組織的資源概況。
組織特征和環境分析
組織特征和環境對培訓的成功也起著重要的作用。因為，當培訓計劃與組織的價值觀不壹致時，培訓的效果就很難保證。組織特征和環境的分析，主要是對組織系統結構、文化和信息傳播的理解。主要包括以下內容:
系統特性是指組織的輸入、運行、輸出、子系統的相互作用以及與組織外部環境的交流等方面的特性，使管理者能夠系統地面對組織，避免組織分析中缺乏概括。
文化特色。是指組織的軟硬設施、規則、制度、組織運作的方式、組織成員的特殊風格，讓管理者深入了解組織，而不是僅僅停留在表面。
信息傳播的特點。指組織部門和成員之間信息收集、分析和傳遞的分工和操作，使管理者了解組織信息傳遞和溝通的特點。
問題6:需求分析階段常用的三種圖形工具是什麽？1.需求分析就是準確理解需求，轉換成需求定義，再轉換成正式的功能規格說明。需求分析的難點在於問題的復雜性、溝通的障礙性、不完整性和不壹致性、需求的多變性。2.結構化方法通過自頂向下的逐層分析策略，將壹個復雜的系統分解成若幹個小問題，然後分別求解。3.數據流是數據通過系統的變化方式。輸入數據首先轉換成中間數據，然後轉換成輸出結果數據。在此期間，可以從現有數據存儲(如磁盤文件或內存緩沖區)中導入其他數據。轉換數據是程序中的壹個函數或子函數。兩個轉換功能之間的數據傳輸決定了功能之間的接口。4.將壹個功能分解成若幹個子功能，並確定這些子功能與父功能之間的接口，這就是水平分解。5.將壹個功能分解成若幹個子功能，確定這些子功能與父功能的接口，就是水平分解。但如果繼續分解，有些子功能分解成小的子功能，壹個小的子功能又分解成更小的子功能，這屬於垂直分解。6.數據流圖是表示系統功能的工具。它表示系統的邏輯模型，並描述系統中的數據流。這是壹個功能模型。
問題7:如何做需求分析隨著技術的不斷發展，用戶對網站功能需求的不斷增加，網站項目的設計已經不能簡單的用靜態的Html文件來實現。與前幾年相比，網站項目的設計和開發越來越像壹個軟件項目，也更加復雜。網站項目的設計和開發已經進入了壹個需要強調流程和分工的時代，壹個規範、有效、健壯的開發機制已經建立。
網站項目管理(WPM)即基於Web的項目管理，即基於Web應用框架的項目設計和管理，Web應用包括瀏覽器、網絡和Web。
服務器等重點學科主要體現在以瀏覽器為客戶端的網站設計和web應用開發(如資訊網站、網店、虛擬郵局、客戶關系管理)。)等項目管理。
根據筆者的經驗，網站項目管理可以分為以下六個階段來控制:
1.需求分析和變革管理
2.項目模型和業務流程分析
3.系統分析和軟件建模
4.界面設計、交互設計和程序開發
5.系統測試和文檔
6.客戶培訓、技術支持和售後服務
需要註意的是，雖然這些階段在某種程度上是連續的，但並不是完全分開的。例如，需求變更管理、測試工作和文檔編寫都貫穿於整個項目過程，許多任務交替或同時進行。
(壹)如何做好需求分析和變革管理？
銷售人員與客戶溝通，撰寫需求分析報告是項目開發的基礎。該項目以客戶的需求為中心，而不是適應技術的需求。
壹:讓客戶暢所欲言，列出所有需求。
讓用戶盡可能清晰地解釋所有的想法，並無遺漏地列出所有的需求。這時候就不要害怕“勾引”客戶的潛在需求，增加設計開發的工作量，從而被未來客戶無休止的變化拖入泥潭。我們要直接清晰的把和客戶的問題和需求壹個壹個的羅列出來，拋開組織歸納分析，準確記錄用戶最原始最完整的需求來完成第壹步。
顯然，如果客戶的需求不完整，隨時可能發生意想不到的變化，甚至這種變化會破壞已經做出的模型和結構，那麽項目從壹開始就註定失敗；比如站點的所有功能都實現了，本地測試沒有問題，但是妳不知道客戶的系統每天要承受1萬獨立IP訪問，而妳原本以為了不起的是1萬獨立IP訪問的訪問流量。稍微有經驗的開發者都會明白，這樣的設計簡直就是壹場災難，所有的應用服務器、數據庫、程序都得重新開發！
第二，透過現象分析潛在需求。
很多時候客戶都不是專業人士，我們也不能指望他們在無休止的描述中幫我們理清重點和技術難點。這就需要我們為客戶分析、總結、整理，尤其是客戶話不多但技術難度大、強度大的地方。
客戶對需求的概念往往很模糊，很多時候給出的需求都是泛泛而談，難以掌控，這就需要業務人員在聽取客戶的詳細說明後，幫助客戶進行梳理和分析，同時預測客戶在開發過程中可能發生的變化，以及在未來的應用中可能進行修改和升級的潛在需求。
比如，在為客戶設計辦公自動化系統時，可能需要預留通道，供客戶日後與其業務部門進行交互；在設計郵件系統時，要考慮到可能需要廣告管理服務器；在設計網上電子商店時，我們將在未來增加庫存產品的統計分析，等等；受限於時間和財力的考慮，客戶通常能夠接受分階段實現的開發過程。在進行需求分析時，可以提前為客戶設想未來的需求變化，這不僅使項目開發更加順利，也為未來進壹步的業務發展奠定了基礎.....> & gt
問題8:軟件需求分析的方法和工具有哪些內容？1.問卷調查法，針對壹些需要進壹步明確的個性化需求，開發人員通過向用戶發送問卷來徹底了解項目需求的壹種方法。這種方法適用於開發人員和用戶都知道項目需求的情況。因為開發商和施工商都知道項目的需求，所以雙方更少需要進壹步的溝通。采用這種簡單的問卷調查方法，可以更好地解決問題。
2.會議討論法，開發人員和用戶召開多次需求討論會議，以全面了解項目需求。這種方法適用於開發者不知道項目需求(開發者剛開始做這類業務)但用戶知道項目需求的情況。因為用戶知道項目的需求，能夠準確的表達自己的需求，而開發者有專業的軟件開發經驗，壹般能夠準確的描述和把握用戶提供的需求。
3.界面原型法，開發者根據自己對用戶需求的理解，畫出應用系統的功能界面，然後與用戶溝通。通過“界面原型”這壹載體，是雙方逐步明確項目需求的壹種需求獲取方式。這種方法更適合於開發人員和用戶都不清楚項目需求的情況。由於開發人員和用戶對項目需求並不明確，更需要借助壹定的“載體”來加快需求的挖掘和雙方對需求的理解。在這種情況下，最好采用“可視化”界面原型方法。