項目需求確認方法(需求分析方法)
1.需求分析有哪些方法
三種需求分析的方法：結(jié)構(gòu)化分析方法、面向?qū)ο蟮姆治龇椒?、面向問題域的分析方法。
結(jié)構(gòu)化的分析方法是傳統(tǒng)的分析法，它的好處是在需求階段可以不需要精確地定義系統(tǒng)，只需要根據(jù)業(yè)務框架確定系統(tǒng)的功能范圍，以及每個功能的處理邏輯和業(yè)務規(guī)則，功能需求規(guī)格書等。因為不需要精確描述，因此描述系統(tǒng)的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統(tǒng)。在系統(tǒng)開發(fā)以前，一般還可以采用更為直觀的原型系統(tǒng)方式和最終用戶進行交流和確認，因此對業(yè)務需求的要求會低一些，業(yè)務需求階段的周期相對容易控制；通過業(yè)務全景圖，最終用戶也能了解系統(tǒng)的功能；通過功能活動圖和業(yè)務規(guī)則的描述，也可以相對精確地描述業(yè)務系統(tǒng)；因為沒有嚴格的標記語言，可以采用適當?shù)钠枋鲞m當?shù)南到y(tǒng)。當然，這種方法的缺點也是明顯的，分析人員和業(yè)務人員之間可能缺乏共同語言，機器不能識別業(yè)務需求書，在設計階段還需要繼續(xù)和用戶確認一部分功能。
面向?qū)ο蟮姆治龇椒ǖ淖畲蠛锰幨窃谛枨箅A段，就能夠非常精確地描述一個系統(tǒng)，采用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項目一開始就發(fā)現(xiàn)很多問題，避免在開發(fā)的過程中出現(xiàn)需求的反復，而且在系統(tǒng)設計和開發(fā)階段不需要最終用戶參與。在實施上，一般可以采用場景、業(yè)務功能等方式來描述，比較適合于業(yè)務流程環(huán)節(jié)多的系統(tǒng)，或者軟件產(chǎn)品的開發(fā)。但是，我們也要看到，在現(xiàn)實中，絕大多數(shù)的應用系統(tǒng)都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業(yè)務系統(tǒng)應該是什么樣，或者采用一種抽象的方式能夠確定最終的應用系統(tǒng)；其次，因為最終用戶不需要參與設計和開發(fā)階段的工作，所以雙方確定業(yè)務需求的過程也會比較長；同時，因為是精確描述，因此描述系統(tǒng)的語言是非常邏輯化的，一般通過某種方式可以使機器識別業(yè)務需求，采用這種方式寫的業(yè)務需求是非常格式化的，一方面描述一個系統(tǒng)需要的信息非常多，可能使需求說明的篇幅非常長，不便于理解和閱讀；另外由于通過抽象的方式來推演最終系統(tǒng)的運行方式，對業(yè)務人員的要求非常高。
2.需求確認的方法
有效提問 為什么我們要提問？ 收集信息和發(fā)現(xiàn)需求時 開始和結(jié)束談話 控制談話方向時 制止別人滔滔不絕的談話時 征求別人意見 不明白或不相信需要確認時 提出建議時 處理異議時 有效應用兩種提問方式： 通 常， 我 們 會 用 開 放 式 問 題 開 頭， 一 旦 談 話 偏 離 你 的 主 題， 用 封 閉 性 問 題進 行 限 制， 如 果 發(fā) 現(xiàn) 對 方 有 些 緊 張， 再 改 用 開 放 式 問 題。
請注意：避免用“為什么”開始溝通！ 避免無用的問題： 引導性問題 多重問題 ? 積極聆聽的作用： 為了獲得更多信息 幫助把談話繼續(xù)下去 處理不同的意見 有效發(fā)表自己的意見 保持溝通氣氛的友好 ? 反省自己是否做過： 當別人講話時，你在想自己的事 聽別人講話時，不斷比較與自己想法的不同點 打斷別人的講話 為講演者結(jié)束他的講演 當別人講話時談論其他的事情 忽略過程而只要結(jié)論 僅僅聽那些自己想聽的或希望聽的事和內(nèi)容 是否人的外觀或他們的說話方式給你客觀的聽造成困難 是否很容易被其他的背景或聲音分散注意力 。
3.簡述采購需求數(shù)量確定的方法
1.采購預測——商品采購市場的預測，是在商品采購市場調(diào)查取得的資料的基礎上，經(jīng)過分析研究，并運用科學的方法來預算未來一定時期內(nèi)商品市場供求及其變化趨勢，從而為商品采購決策和制定商品采購計劃提供科學的依據(jù)
2.商品采購市場預測的目的
1）為參與產(chǎn)品設計而進行采購市場預測
2）為參與市場競爭而進行采購市場預測
3）為商品采購決策和制定商品采購計劃而進行采購市場預測
3.預測在采購中的作用P95（看）
4.獨立需求物料的采購需求確定
1）獨立需求物料與相關需求物料
相關需求是指某種物料的需求量與其他物料有直接的匹配關系，當其他某種物料的需求量確定以后，就可以通過這種相關關系把該種物料的需求量推算出來
獨立需求是指某種物料的需求量是由外部市場決定的，與其他物料不存在直接的對應關系，表現(xiàn)出對這種庫存需求的獨立性
5.定量訂貨模型和定期訂貨模型
在定期訂貨系統(tǒng)中，每次訂貨數(shù)量都不盡相同，定購量的大小主要取決于各個時期的使用率，它一般比定量訂貨系統(tǒng)要求更多的安全庫存
6.物料需求計劃（MPR）
MPR既是一種管理理念，生產(chǎn)方式，也是一種方法技術(shù)，一個信息系統(tǒng)，即是一種庫存控制方法，也是一種時間進度安排方法
7.分銷需求計劃（DRP）
8.物料采購訂單容量的確定
1）分析采購項目供應資料
2）計算總體定單容量
3）計算承接定單容量
4）確定剩余定單容量
9.下單數(shù)量=生產(chǎn)需求量-計劃入庫量-現(xiàn)有庫存量+安全庫存量
下單時間=要求到貨時間-認證周期-定單周期-緩沖時間
10.采購預算——就是一種用數(shù)量來表示的計劃，是將企業(yè)未來一定時期內(nèi)經(jīng)營決策的目標通過有關數(shù)據(jù)系統(tǒng)的反映出來，使經(jīng)營決策具體化，數(shù)量化的表現(xiàn)。
11.采購預算的主要作用
1）保障企業(yè)戰(zhàn)略計劃和作業(yè)計劃的執(zhí)行，確保企業(yè)組織目標一致
2）協(xié)調(diào)企業(yè)各部門之間的合作經(jīng)營
3）在企業(yè)各部門之間合理安排有限的資源
4）對企業(yè)物流成本進行控制，監(jiān)督
4.需求分析的步驟有哪些
一、需求識別 需求人員在此步驟應該分析需求類別、需求復雜度和需求價值用來確定需求實施的優(yōu)先級。
1.需求類別確認：需求類別包含流程類需求、統(tǒng)計分析類需求、接口類需求，一個需求可能為某一類型需求，也可能包含多類需求。確認需求類別后應對每類需求的數(shù)量進行初步分析（比如流程類需求包含幾個流程、統(tǒng)計分析類需求包含幾個報表、接口類需求包含幾個接口）。
2.需求復雜度分析：一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過程需求人員需要付出的工作量）。
3.價值分析：需求人員收到需求后應根據(jù)收集需求內(nèi)容初步分析需求痛點/目標、需求復雜度、業(yè)務重要程度確定需求價值，需求價值分析 二、業(yè)務流程/統(tǒng)計查詢/接口分析 針對流程類需求必須進行業(yè)務流程分析，統(tǒng)計查詢和接口類需求可不進行詳細的流程分析。1.業(yè)務流程分為部門級、組織級和崗位級 部門級流程關注脈絡需要分析涉及哪些具體崗位、執(zhí)行活動、每個活動之間的關聯(lián)關系，它是需求分析的主線條，也是流程分析的主要產(chǎn)物。
組織級流程關注宏觀一般不會直接繪制，是對部門級流程的概括和抽象。崗位級流程關注每個業(yè)務活動的執(zhí)行步驟屬需求細節(jié)范疇，在流程分析階段不要過度進入細節(jié)。
2.需求識別階段確認的流程均為部門級流程 需求人員在進行流程分析應遵循如下方法：（1）業(yè)務流程確認：一個流程為一個業(yè)務事件，一般是外部角色發(fā)起或系統(tǒng)內(nèi)部主動發(fā)起（比如時間事件或狀態(tài)事件），發(fā)起后會觸發(fā)一系列業(yè)務活動。（2）角色及業(yè)務活動確認：流程圖中的每個泳道都必須對應到角色，每個角色對應多個業(yè)務活動。
需求人員在確認業(yè)務活動時一定要保證活動的粒度，一個業(yè)務活動一定是由一個角色完成且每個業(yè)務活動都是有價值的活動。比如項目輸入項目名稱是一個執(zhí)行步驟，這個動作沒有價值，項目經(jīng)理查詢項目信息就是一個業(yè)務活動。
在需求描述時針對線下活動或新增活動應該應標識區(qū)分。（3）業(yè)務活動間關系及數(shù)據(jù)確認：確定所有業(yè)務活動的前后置關系，并明確流程間的傳遞的數(shù)據(jù)實體。
（4）流程整體瓶頸分析：一般若某個角色業(yè)務活動工作量較大，或流程涉及高級領導，一般都會造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優(yōu)化建議。3.針對統(tǒng)計查詢類需求及接口類需求，按照上述業(yè)務活動確定原則分析、確定角色，并明確每個角色所執(zhí)行的業(yè)務活動即可。
三、數(shù)據(jù)實體分析 針對流程類需求需要分析各業(yè)務活動傳遞的數(shù)據(jù)實體，統(tǒng)計分析類需求需要分析統(tǒng)計查詢條件和查詢展現(xiàn)兩類數(shù)據(jù)實體、接口類需求需要分析接口傳遞數(shù)據(jù)實體，具體分析包含如下內(nèi)容：1.明確數(shù)據(jù)實體：確認需要分析的所有數(shù)據(jù)實體，明確哪些為系統(tǒng)原有實體、哪些為新增實體、哪些為改造實體。2.明確所有數(shù)據(jù)實體間關系：實體間關系包含（1對1、1對多、多對多），另外需要分析數(shù)據(jù)實體變更是否需要保留版本，實體刪除（邏輯刪除、物理刪除）是否影響其它數(shù)據(jù)實體。
3.明確數(shù)據(jù)實體字段：針對新增數(shù)據(jù)或改造數(shù)據(jù)實體需要明確新增字段的名稱、字段類型、是否必填、字段取值方式（人工輸入、系統(tǒng)自動繼承自其它數(shù)據(jù)實體、系統(tǒng)自動計算需要明確計算公式）。4.數(shù)據(jù)權(quán)限分析：需要分析不同角色在數(shù)據(jù)權(quán)限方面的差異，若涉及縱向多級用戶，要說明對于集團/省/地市用戶的數(shù)據(jù)隔離。
四、角色及使用場景分析 一般來說每個業(yè)務活動是對用戶使用場景的抽象，每個業(yè)務活動可能包含多個場景，分析使用場景時應按照業(yè)務活動為主線逐個進行分析，每個業(yè)務活動分析時應包含如下內(nèi)容：1.明確活動執(zhí)行角色。2.明確活動執(zhí)行的前置條件和后置條件。
3.明確不同場景：一個業(yè)務活動可能包含正常的使用場景、備選使用場景和異常使用場景；4.明確每個場景的執(zhí)行步驟：描述執(zhí)行步驟時應使用簡單的語法，主語明確語義易于理解，每個步驟不應該在任何一方（執(zhí)行角色、系統(tǒng)）停留兩部以上，重點描述如何交互。5.業(yè)務規(guī)則和約束：明確在每個業(yè)務活動下應遵循的業(yè)務規(guī)則和約束，這里一般是與業(yè)務流程相關的行為規(guī)則（比如項目周期時長超過90天必須提交二級領導審批），或與數(shù)據(jù)實體相關的數(shù)據(jù)規(guī)則（需求交接單拒收時候必須填寫拒收原因，且拒收原因不能超過500字）。
五、系統(tǒng)功能分析。
5.需求分析常用方法都有哪些,請舉例說明
問卷調(diào)查法，是指設計方就用戶需求中的一些個性化的、需要進一步明確的需求或問題，通過采用向用戶問卷調(diào)查表的方式，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進一步溝通的需求或問題就比較少，通過采用這種簡單的問卷調(diào)查方法就能使問題得到較好的解決。
顯然對于樂百氏集團這樣規(guī)模龐大的公司，簡單的問卷調(diào)查是不能夠滿足準確獲得需求的需要的。會議討論法，是指設計方和用戶相關人員召開若干次需求討論會議，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于設計方不清楚用戶的詳細業(yè)務需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能準確地表達出他們的需求，而設計方有專業(yè)的需求，而我們有專業(yè)的軟件開發(fā)經(jīng)驗，經(jīng)過回憶討論交流之后，能夠?qū)τ脩舻男枨筮M行準確描述和把握。
這個方法對于準確的獲得樂百氏公司的需求是一種不錯的選擇。在本案例中系統(tǒng)的設計人員也是這么做的，他們通過和樂百氏項目組經(jīng)理的討論，很快了解了樂百氏的運作過程的數(shù)據(jù)。
界面原型法，是指設計方根據(jù)自己所了解的用戶需求，描畫出應用系統(tǒng)的功能界面后與用戶進行交流和溝通，通過“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合于設計方和用戶都不是非常清楚項目需求、只是大概了解用戶需求的情況。
因為設計方和用戶方都不能非常準確的描述出客戶的需求，因此此時就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求理解。
6.我們應當怎樣做需求確認：快速原型法
常常聽到許多朋友跟我埋怨，需求分析之難，就在于用戶自身就常常弄不清楚自己的需求。起初在需求確認的時候說得好好的，一到軟件上線的時候就不是那么回事了，這可沒法整。但我們只要坐下來仔細分析就會發(fā)現(xiàn)，在需求分析的時候我們跟用戶是在空對空地討論問題。用戶不是專業(yè)人士，他也搞不清楚軟件到底會做成啥樣，所以你跟他確認的時候他就點頭了。但是，用戶不是傻子，當你軟件上線時，他拿到了實物了，知道軟件做成啥樣了，一旦不滿意他就開始提變更了。所以，需求分析的癥結(jié)就在與這個實物。
既然癥結(jié)在此，毫無疑問，我們就應當在需求分析階段拿出實物，用實物與用戶確認需求，這就是快速原型法的基本思想?？焖僭头?，簡稱原型法（Prototyping），是20世紀80年代提出的一種從設計思想、工具、手段都全新的系統(tǒng)開發(fā)方法。它摒棄了那種一步步周密細致地調(diào)查分析，然后逐步整理出文字檔案，設計開發(fā)，最后才能讓用戶看到軟件結(jié)果的繁瑣作法。當我們捕獲了一批業(yè)務需求以后，就立即使用快速可視化工具開發(fā)出一個原型，交給用戶去試用、補充和修改。再提出一些新的需求以后，再開發(fā)一版新的原型。原型法的關鍵就是這個快速開發(fā)。不用考慮性能、美觀、可靠，原型的目的就是模擬客戶的需求，與客戶進行確認的。整個需求分析的過程就是“捕獲需求->原型開發(fā)->確認需求->再捕獲需求”的過程。
原型開發(fā)的快速與模擬到什么程度，是一對矛盾，我們要去把握。要快速開發(fā)，必然不可能和最終交付的軟件系統(tǒng)一模一樣，許多復雜問題被簡化，非關鍵性流程被忽略，這就是所謂的模擬。因此，模擬到什么程度是關鍵，既能說明問題，又不耽誤時間。根據(jù)我的經(jīng)驗，一般能拿出界面，并可以走通關鍵性流程就可以了。一些快速開發(fā)平臺為快速原型法提供了可能。
當用戶拿到原型可以自己操作時，需求研討的氣氛立即變得不太一樣了。當用戶享受原型給他們帶來體驗的快感時，需求被源源不斷地被提出來。這時候的需求，就不再是枯燥無味的文字游戲，而是生動形象的圖形界面。日后，如果項目采用迭代開發(fā)，讓用戶看著軟件一點兒一點兒地成長，這又是多么美妙的體驗啊。與此同時，你與用戶的信任也在一步一步建立起來，軟件風險在降低，項目將朝著正確方向前進。
快速原型法是美妙的，它給你與用戶帶來了從未有過的體驗。但美妙的同時，也會帶來一些的尷尬，不必要的誤會，我們一定要注意。最常見的誤會就是讓用戶將原型誤以為最終交付的系統(tǒng)。開發(fā)一個系統(tǒng)需要持續(xù)數(shù)月，但你倒好，幾天就搞定了，為什么還要在這個系統(tǒng)上投入大量資金呢？如果對方領導開始有這樣的想法時，雙方就開發(fā)費用進行的談判就有一些不妙了。所以在給用戶看到原型前，一定要跟用戶解釋清楚。
既然是原型，必要的校驗、非正常操作的處理通通都被忽略。因此，當演示原型出錯時，用戶你可千萬不要較真喲！這丑話可得說在前頭，否則用戶跟你較起真來，你在用戶心目中的形象可就要大打折扣了。
我們應當怎樣做需求分析我們應當怎樣做需求調(diào)研：初識我們應當怎樣做需求調(diào)研：拜訪我們應當怎樣做需求調(diào)研：研討會我們應當怎樣做需求調(diào)研：需求研討我們應當怎樣做需求調(diào)研：迭代我們應當怎樣做需求調(diào)研：需求捕獲（上）我們應當怎樣做需求調(diào)研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業(yè)務流程分析（上）我們應當怎樣做需求分析：業(yè)務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態(tài)圖我們應當怎樣做需求分析：業(yè)務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅(qū)動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：需求規(guī)格說明書我們應當怎樣做需求確認：評審與簽字確認會（續(xù)）
7.我們應當怎樣做需求確認：評審與簽字確認會
時間過得真快，經(jīng)過一系列需求研討、需求分析和整理確認，我們整理出了需求列表，編寫出了需求規(guī)格說明書，一切似乎該到結(jié)束需求分析階段的時候了。但是，敏捷大師的一句話讓我們徹底心涼到了骨頭里。敏捷大師說了，我們不可能在需求分析階段完成所有的需求分析工作，它將延續(xù)到設計、開發(fā)，甚至測試階段。
一直以來，我對這句話非常困惑。既然需求分析階段不能完成所有的需求分析工作，那么完成多少才算結(jié)束呢？80%?60%？或者更少？大師沒有給出一個標準。大師就是大師，生活在太空里的，我們慢慢理解吧。經(jīng)過多年的實踐，我慢慢理解了。我們說這種需求分析工作不可能完全完成，或者說日后用戶的需求會變，其實并不是毫無規(guī)律可循的。通常，用戶對需求的變更只發(fā)生在某些固定的范圍內(nèi)，弄清楚了這些范圍，我們的問題就迎刃而解了。
1. 整體需求不變，具體細節(jié)變化。我們說需求是分層次的，整體框架、功能模塊、每個操作的細節(jié)。如果用戶變更到了將整個框架都推翻了，這個項目就別做了。所以整體框架是必須在需求分析階段完成的，是日后不可能改變的。功能模塊可能要變，但通常是某個部分在變，而更多的是那些具體操作的細節(jié)在變。
2. 界面風格與操作易用性是最容易發(fā)生變更的。我們說用戶看到軟件以后不滿意，其實主要是對界面風格與操作性不滿意，而不是軟件功能。界面不夠美觀，操作不方便，不符合用戶的操作習慣，都是造成用戶不滿意的地方。
3. 增加其它功能。軟件是對現(xiàn)實的模擬，而現(xiàn)實也是復雜多變的。我們與用戶在進行業(yè)務流程分析時，也許一些流程沒有考慮到，或者還有特殊情況需要處理。這些是客戶要求增加功能的主要動因。
OK，萬事俱備只欠東風，當所有工作都完備以后，我們的需求分析工作開始進入最后收尾的階段。我們說，需求分析階段的產(chǎn)出物是需求列表與需求規(guī)格說明書，而最終結(jié)束的里程碑無疑就是需求評審會了，或者說與用戶的簽字確認會。
需求評審會的主要目的就是確認需求，以便以此開始我們的設計開發(fā)工作。從理論上說，需求評審會應當由用戶代表，與項目經(jīng)理、需求分析員、系統(tǒng)架構(gòu)師、設計人員、測試人員、QA經(jīng)理，還有公司相關領導參加。但實際上，讓如此多不同角色的人聚集在一起開會是不現(xiàn)實的。因此，我們可以將需求評審會分為內(nèi)部評審會與外部評審會兩部分來開比較現(xiàn)實。
處理外部問題，必先要從內(nèi)部統(tǒng)一思想。先召開一個內(nèi)部評審會，聽聽系統(tǒng)架構(gòu)師、設計人員、測試人員、QA經(jīng)理對需求分析工作的意見，然后由領導講講話，布置一下后面的工作，是十分有必要的。按照我的經(jīng)驗，系統(tǒng)架構(gòu)師這時的作用相當重要，他應當仔細閱讀需求，仔細思考技術(shù)是否可行，以及預測該系統(tǒng)是否能夠達到用戶方領導對該項目制訂的目標。如果答案是否定，立即進行調(diào)整。
最后就是與用戶的外部需求評審會了。外部需求評審會，也可稱為簽字確認會議，就是與用戶就需求規(guī)格說明書進行評審，最后簽字確認。用戶簽過字的東西，不可能完全抑制住用戶的變更，但至少從很大程度上抑制住了用戶的大改。然而，在召開外部需求評審會之前，我們建議大家就需求規(guī)格說明書，先與各個單位或部門的用戶代表討論并確定下來，避免在最終的簽字確認會上出現(xiàn)分歧，影響工作進度。畢竟大家都不容易，工作一大堆，聚在一起不容易。
經(jīng)過數(shù)月的分析討論，最終在一片和諧的氣氛中，雙方領導在需求規(guī)格說明書上簽字，項目開始進入一個新的輪回。在這個輪回中，是焦頭爛額、不勝其苦，還是如履薄冰、最終順利交付，是與許多因素有關的。但我想說，一份高質(zhì)量的需求分析必定起到?jīng)Q定性的作用，必定為日后的軟件開發(fā)掃清了許多許多的地雷。
我們應當怎樣做需求分析我們應當怎樣做需求調(diào)研：初識我們應當怎樣做需求調(diào)研：拜訪我們應當怎樣做需求調(diào)研：研討會我們應當怎樣做需求調(diào)研：需求研討我們應當怎樣做需求調(diào)研：迭代我們應當怎樣做需求調(diào)研：需求捕獲（上）我們應當怎樣做需求調(diào)研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業(yè)務流程分析（上）我們應當怎樣做需求分析：業(yè)務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態(tài)圖我們應當怎樣做需求分析：業(yè)務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅(qū)動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規(guī)格說明書（全文終）
8.確定信息需求的三個步驟
收集需求，分析需求的重要性，確定需求。
1、需求優(yōu)先級的定義應根據(jù)當時的環(huán)境和實際情況，是否有足夠的理論支持和數(shù)據(jù)支持，滿足需求后的分析結(jié)果是否清晰等。當定義一個需求是否被確定為一個明確的需求時，這些都被考慮在內(nèi)。
2、有四個要求優(yōu)先：重要和緊急；重要和不緊急；緊急和不重要；不緊急和不重要。這四種情況也是我們處理需求優(yōu)先的原則，即重要性+緊迫性。
3、還應考慮需求的風險與價值之間的關系。高價值-高風險的功能需求應優(yōu)先考慮，即優(yōu)先考慮獲得高價值回報，而早期處理可以有效地消除重大風險。
4、對于高值低風險的功能需求，所提供的價值是等價的，但由于風險較低，可以以后進行。
5、對于低價值低風險的功能需求，應該排在第三位，放棄它們對產(chǎn)品總價值的影響很小，而且風險也很低。
6、對于低值高風險的功能需求，顯然最好盡量避免開發(fā)或推遲工作。
擴展資料：
信息需求的內(nèi)容構(gòu)成
1、信息要求，包括信息內(nèi)容和形式的要求。信息的內(nèi)容反映了信息所屬的學科，如“生物信息”、“經(jīng)濟信息”、“環(huán)境保護信息”；信息的形式多種多樣，如“知識信息”或“信息信息”、政策信息、市場信息或“產(chǎn)品信息”。
2、對信息源的要求，包括信息源的范圍和載體形式。用戶對這些方面有不同的要求。
參考資料來源：
百度百科-信息需求
