什么是需求分析(什么是方案需求分析)，36創業加盟網給大家帶來詳細的介紹，讓更多的人可以參考:什么是需求分析(什么是方案需求分析)。
什么是項目需求分析？需求分析是指理解用戶需求，就功能與客戶達成一致，估計和評估項目 代價，最終形成開發計劃的一個復雜過程。（這個和我在微軟體驗到的又不太 一樣，微軟的需求分析大多是市場人員和用戶協助小組的人去評估用戶的接 受程度，這一點也可以理解，因為公司的性質有根本差別）在這個過程中， 用戶的確是處在主導地位，需求分析工程師和要負責整理用戶需求，為之后 的設計打下基礎。需求分析階段結束后，要求得到： 1.SRS 文檔(System Requirement Specification); 2.DRM 文檔；3.Acceptance Plan. 從廣義上 理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一 系列需求工程。狹義上理解：需求分析指需求的分析、定義過程。 一、為什么要需求分析需求分析就是分析用戶的需求是什么.如果投入大量的人力，物力,財力, 時間,開發出的卻沒人要,那所有的投入都是徒勞.如果費了很大的精力,開發 一個,最后卻不滿足用戶的要求,從而要重新開發過,這種返工是讓人痛心疾 首的.(相信大家都有體會)比如,用戶需要一個 for linux 的,而你在開發前期1忽略了的運行環境,忘了向用戶詢問這個問題,而想當然的認為是開發 for windows 的,當你千辛萬苦地開發完成向用戶提交時才發現出了問題,那時候 你是欲哭無淚了,痕不得找塊豆腐一頭撞死.需求分析之所以重要,就因為他具有決策性,方向性,策略性的作用, 他在開發的過程中具有舉足輕重的地位.大家一定要對需求分析具有足夠的 重視.在一個大型系統的開發中,他的作用要遠遠大于程序設計. 二、需求分析的任務簡言之,需求分析的任務就是解決"做什么"的問題,就是要全面地理 解用戶的各項要求,并準確地表達所接受的用戶需求. 三、需求分析的過程需求分析階段的工作,可以分為四個方面:問題識別,分析與綜合,制訂 規格說明,評審.問題識別：就是從系統角度來理解,確定對所開發系統的綜合要求,并 提出這些需求的實現條件,以及需求應該達到的標準.這些需求包括：功能需 求(做什么),性能需求(要達到什么指標),環境需求(如機型,操作系統等),可 靠性需求(不發生故障的概率）,安全保密需求,用戶界面需求,資源使用需求 (運行是所需的內存,CPU 等),消耗與開發進度需求,預先估計以后系統可能達 到的目標.分析與綜合：逐步細化所有的功能,找出系統各元素間的聯系,接口特 性和設計上的限制,分析他們是否滿足需求,剔除不合理部分,增加需要部分. 最后,綜合成系統的解決方案,給出要開發的系統的詳細邏輯模型(做什么的 模型).2制訂規格說明書：即編制文檔,描述需求的文檔稱為需求規格說明書. 請注意,需求分析階段的成果是需求規格說明書(好象軟考曾經考過這個問 題),向下一階段提交.評審：對功能的正確性,完整性和清晰性,以及其它需求給予評價.評 審通過才可進行下一階段的工作,否則重新進行需求分析。
四、需求分析的方法需求分析的方法有很多.這里只強調原型化方法,其它的方法如:結構 化方法,動態分析法等(個人認為,對初學者不必深究這些方法,實際上我也從 來沒用過這些方法)在此不討論.原型化方法是十分重要的(是軟考等常考的知識點).原型就是的一個 早期可運行的版本,它實現了目標系統的某些或全部功能.原型化方法就是盡可能快地建造一個粗糙的系統,這系統實現了目標 系統的某些或全部功能,但是這個系統可能在可靠性,界面的友好性或其他方 面上存在缺陷.建造這樣一個系統的目的是為了考察某一方面的可行性,如算 法的可行性,技術的可行性,或考察是否滿足用戶的需求等.如,為了考察是否 滿足用戶的要求,可以用某些工具快速的建造一個原型系統,這個系統只是一 個界面,然后聽取用戶的意見,改進這個原型.以后的目標系統就在原型系統 的基礎上開發.原型主要有三種類型(軟考考過):探索型,實驗型,進化型.探索型:目 的是要弄清楚對目標系統的要求,確定所希望的特性,并探討多種方案的可行 性.實驗型:用于大規模開發和實現前,考核方案是否合適,規格說明是否可靠. 進化型:目的不在于改進規格說明,而是將系統建造得易于變化,在改進原型3的過程中,逐步將原型進化成最終系統。
在使用原型化方法是有兩種不同的策略:廢棄策略,追加策略.廢棄策略:先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行 修改,形成比較好的思想,據此設計出較完整,準確,一致,可靠的最終系統.系 統構造完成后,原來的模型系統就被廢棄不用.探索型和實驗型屬于這種策 略。追加策略:先構造一個功能簡單而且質量要求不高的模型系統，作為 最終系統的核心,然后通過不斷地擴充修改,逐步追加新要求，發展成為最終 系統。進化型屬于這種策略. 五、需求分析的 20 條法則（本節摘自工程專家網）客戶與開發人員交流需要好的方法。下面建議 20 條法則，客戶和開發 人員可以通過評審以下內容并達成共識。如果遇到分歧，將通過協商達成對 各自義務的相互理解，以便減少以后的磨擦（如一方要求而另一方不愿意或 不能夠滿足要求）。 1、 分析人員要使用符合客戶語言習慣的表達需求討論集中于業務需求和任務，因此要使用術語。客戶應將有 關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定 要懂得計算機行業的術語。 2、分析人員要了解客戶的業務及目標只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。
這將有助于開發人員設計出真正滿足客戶需要并達到期望的優秀。為幫助開 發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新4系統，那么開發和分析人員應使用一下目前的舊系統，有利于他們明白目前 系統是怎樣工作的，其流程情況以及可供改進之處。 3、 分析人員必須編寫需求報告分析人員應將從客戶那里獲得的所有信息進行整理，以區分業務需 求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客 戶就能得到一份“需求分析報告”，此份報告使開發人員和客戶之間針對要 開發的產品內容達成協議。報告應以一種客戶認為易于翻閱和理解的方式組 織編寫。客戶要評審此報告，以確保報告內容準確完整地表達其需求。一份 高質量的“需求分析報告”有助于開發人員開發出真正需要的產品。 4、 要求得到需求工作結果的解釋說明分析人員可能采用了多種圖表作為文字性“需求分析報告”的補 充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中 各種圖表有著極高的價值；雖然它們不太難于理解，但是客戶可能對此并不 熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和 需求開發工作的結果什么是需求分析，以及怎樣檢查圖表有無錯誤及不一致等。
5、 開發人員要尊重客戶的意見如果用戶與開發人員之間不能相互理解，那關于需求的討論將會有 障礙。共同合作能使大家“兼聽則明”。參與需求開發過程的客戶有權要求 開發人員尊重他們并珍惜他們為項目成功所付出的時間，同樣，客戶也應對 開發人員為項目成功這一共同目標所做出的努力表示尊重。 6、 開發人員要對需求及產品實施提出建議和解決方案通常客戶所說的“需求”已經是一種實際可行的實施方案，分析人5員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與 當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的 事情后，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人 員還能提出增加一些用戶沒有發現的很有價值的系統特性。 7、 描述產品使用特性客戶可以要求分析人員在實現功能需求的同時還注意的易用性，因 為這些易用特性或質量屬性能使客戶更準確、高效地完成任務。例如：客戶 有時要求產品要“界面友好”或“健壯”或“高效率”，但對于開發人員來 講，太主觀了并無實用價值。正確的做法是，分析人員通過詢問和調查了解 客戶所要的“友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪 些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡， 以確保做出合理的取舍。
8、 允許重用已有的組件需求通常有一定靈活性，分析人員可能發現已有的某個組件與客戶 描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以 便開發人員能夠降低新系統的開發和節省時間，而不必嚴格按原有的需求說 明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們并 不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。 9、 要求對變更的代價提供真實可靠的評估有時，人們面臨更好、也更昂貴的方案時，會做出不同的選擇。而 這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。 所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影6響、和得失等。開發人員不能由于不想實施變更而隨意夸大評估。 10、 獲得滿足客戶功能和質量要求的系統每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員 關于系統“做什么”所需的所有信息，而且還要求開發人員能通過交流了解 清楚取舍與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員 開發出的產品很可能無法讓您滿意。 11、 給分析人員講解您的業務分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人 員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析 人員能把握客戶業務的細微潛在之處，他們可能不知道那些對于客戶來說理 所當然的“常識”。
總結：以上內容就是什么是需求分析(什么是方案需求分析)詳細介紹，如果您對創業項目感興趣，可以咨詢客服或者文章下面留言，我們會第一時間給您項目的反饋信息。
