項目需求確認方法(需求分析方法)

1.需求分析有哪些方法

三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問(wèn)題域的分析方法。

結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業(yè)務(wù)框架確定系統的功能范圍，以及每個(gè)功能的處理邏輯和業(yè)務(wù)規則，功能需求規格書(shū)等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來(lái)描述系統。在系統開(kāi)發(fā)以前，一般還可以采用更為直觀(guān)的原型系統方式和最終用戶(hù)進(jìn)行交流和確認，因此對業(yè)務(wù)需求的要求會(huì )低一些，業(yè)務(wù)需求階段的周期相對容易控制；通過(guò)業(yè)務(wù)全景圖，最終用戶(hù)也能了解系統的功能；通過(guò)功能活動(dòng)圖和業(yè)務(wù)規則的描述，也可以相對精確地描述業(yè)務(wù)系統；因為沒(méi)有嚴格的標記語(yǔ)言，可以采用適當的篇幅描述適當的系統。當然，這種方法的缺點(diǎn)也是明顯的，分析人員和業(yè)務(wù)人員之間可能缺乏共同語(yǔ)言，機器不能識別業(yè)務(wù)需求書(shū)，在設計階段還需要繼續和用戶(hù)確認一部分功能。

面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個(gè)系統，采用程序語(yǔ)言的方式和最終用戶(hù)交流（最終用戶(hù)必須要熟悉這種語(yǔ)言），能夠在項目一開(kāi)始就發(fā)現很多問(wèn)題，避免在開(kāi)發(fā)的過(guò)程中出現需求的反復，而且在系統設計和開(kāi)發(fā)階段不需要最終用戶(hù)參與。在實(shí)施上，一般可以采用場(chǎng)景、業(yè)務(wù)功能等方式來(lái)描述，比較適合于業(yè)務(wù)流程環(huán)節多的系統，或者軟件產(chǎn)品的開(kāi)發(fā)。但是，我們也要看到，在現實(shí)中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點(diǎn)和困難也是顯而易見(jiàn)的：首先，用戶(hù)要非常清楚地知道最終的業(yè)務(wù)系統應該是什么樣，或者采用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶(hù)不需要參與設計和開(kāi)發(fā)階段的工作，所以雙方確定業(yè)務(wù)需求的過(guò)程也會(huì )比較長(cháng)；同時(shí)，因為是精確描述，因此描述系統的語(yǔ)言是非常邏輯化的，一般通過(guò)某種方式可以使機器識別業(yè)務(wù)需求，采用這種方式寫(xiě)的業(yè)務(wù)需求是非常格式化的，一方面描述一個(gè)系統需要的信息非常多，可能使需求說(shuō)明的篇幅非常長(cháng)，不便于理解和閱讀；另外由于通過(guò)抽象的方式來(lái)推演最終系統的運行方式，對業(yè)務(wù)人員的要求非常高。

2.需求確認的方法

有效提問(wèn) 為什么我們要提問(wèn)？ 收集信息和發(fā)現需求時(shí) 開(kāi)始和結束談話(huà) 控制談話(huà)方向時(shí) 制止別人滔滔不絕的談話(huà)時(shí) 征求別人意見(jiàn) 不明白或不相信需要確認時(shí) 提出建議時(shí) 處理異議時(shí) 有效應用兩種提問(wèn)方式： 通 常， 我 們 會(huì ) 用 開(kāi) 放 式 問(wèn) 題 開(kāi) 頭， 一 旦 談 話(huà) 偏 離 你 的 主 題， 用 封 閉 性 問(wèn) 題進(jìn) 行 限 制， 如 果 發(fā) 現 對 方 有 些 緊 張， 再 改 用 開(kāi) 放 式 問(wèn) 題。

請注意：避免用“為什么”開(kāi)始溝通！ 避免無(wú)用的問(wèn)題： 引導性問(wèn)題 多重問(wèn)題 ? 積極聆聽(tīng)的作用： 為了獲得更多信息 幫助把談話(huà)繼續下去 處理不同的意見(jiàn) 有效發(fā)表自己的意見(jiàn) 保持溝通氣氛的友好 ? 反省自己是否做過(guò)： 當別人講話(huà)時(shí)，你在想自己的事 聽(tīng)別人講話(huà)時(shí)，不斷比較與自己想法的不同點(diǎn) 打斷別人的講話(huà) 為講演者結束他的講演 當別人講話(huà)時(shí)談?wù)撈渌氖虑?忽略過(guò)程而只要結論 僅僅聽(tīng)那些自己想聽(tīng)的或希望聽(tīng)的事和內容 是否人的外觀(guān)或他們的說(shuō)話(huà)方式給你客觀(guān)的聽(tīng)造成困難 是否很容易被其他的背景或聲音分散注意力 。

3.簡(jiǎn)述采購需求數量確定的方法

1.采購預測——商品采購市場(chǎng)的預測，是在商品采購市場(chǎng)調查取得的資料的基礎上，經(jīng)過(guò)分析研究，并運用科學(xué)的方法來(lái)預算未來(lái)一定時(shí)期內商品市場(chǎng)供求及其變化趨勢，從而為商品采購決策和制定商品采購計劃提供科學(xué)的依據

2.商品采購市場(chǎng)預測的目的

1）為參與產(chǎn)品設計而進(jìn)行采購市場(chǎng)預測

2）為參與市場(chǎng)競爭而進(jìn)行采購市場(chǎng)預測

3）為商品采購決策和制定商品采購計劃而進(jìn)行采購市場(chǎng)預測

3.預測在采購中的作用P95（看）

4.獨立需求物料的采購需求確定

1）獨立需求物料與相關(guān)需求物料

相關(guān)需求是指某種物料的需求量與其他物料有直接的匹配關(guān)系，當其他某種物料的需求量確定以后，就可以通過(guò)這種相關(guān)關(guān)系把該種物料的需求量推算出來(lái)

獨立需求是指某種物料的需求量是由外部市場(chǎng)決定的，與其他物料不存在直接的對應關(guān)系，表現出對這種庫存需求的獨立性

5.定量訂貨模型和定期訂貨模型

在定期訂貨系統中，每次訂貨數量都不盡相同，定購量的大小主要取決于各個(gè)時(shí)期的使用率，它一般比定量訂貨系統要求更多的安全庫存

6.物料需求計劃（MPR）

MPR既是一種管理理念，生產(chǎn)方式，也是一種方法技術(shù)，一個(gè)信息系統，即是一種庫存控制方法，也是一種時(shí)間進(jìn)度安排方法

7.分銷(xiāo)需求計劃（DRP）

8.物料采購訂單容量的確定

1）分析采購項目供應資料

2）計算總體定單容量

3）計算承接定單容量

4）確定剩余定單容量

9.下單數量=生產(chǎn)需求量-計劃入庫量-現有庫存量+安全庫存量

下單時(shí)間=要求到貨時(shí)間-認證周期-定單周期-緩沖時(shí)間

10.采購預算——就是一種用數量來(lái)表示的計劃，是將企業(yè)未來(lái)一定時(shí)期內經(jīng)營(yíng)決策的目標通過(guò)有關(guān)數據系統的反映出來(lái)，使經(jīng)營(yíng)決策具體化，數量化的表現。

11.采購預算的主要作用

1）保障企業(yè)戰略計劃和作業(yè)計劃的執行，確保企業(yè)組織目標一致

2）協(xié)調企業(yè)各部門(mén)之間的合作經(jīng)營(yíng)

3）在企業(yè)各部門(mén)之間合理安排有限的資源

4）對企業(yè)物流成本進(jìn)行控制，監督

4.需求分析的步驟有哪些

一、需求識別 需求人員在此步驟應該分析需求類(lèi)別、需求復雜度和需求價(jià)值用來(lái)確定需求實(shí)施的優(yōu)先級。

1.需求類(lèi)別確認：需求類(lèi)別包含流程類(lèi)需求、統計分析類(lèi)需求、接口類(lèi)需求，一個(gè)需求可能為某一類(lèi)型需求，也可能包含多類(lèi)需求。確認需求類(lèi)別后應對每類(lèi)需求的數量進(jìn)行初步分析（比如流程類(lèi)需求包含幾個(gè)流程、統計分析類(lèi)需求包含幾個(gè)報表、接口類(lèi)需求包含幾個(gè)接口）。

2.需求復雜度分析：一般需求受理工作量在1-5人天的需求復雜度低，工作量在5-15人天的需求復雜度中，工作量在15人天以上需求復雜度高。（工作量表示需求受理全過(guò)程需求人員需要付出的工作量）。

3.價(jià)值分析：需求人員收到需求后應根據收集需求內容初步分析需求痛點(diǎn)/目標、需求復雜度、業(yè)務(wù)重要程度確定需求價(jià)值，需求價(jià)值分析 二、業(yè)務(wù)流程/統計查詢(xún)/接口分析 針對流程類(lèi)需求必須進(jìn)行業(yè)務(wù)流程分析，統計查詢(xún)和接口類(lèi)需求可不進(jìn)行詳細的流程分析。1.業(yè)務(wù)流程分為部門(mén)級、組織級和崗位級 部門(mén)級流程關(guān)注脈絡(luò )需要分析涉及哪些具體崗位、執行活動(dòng)、每個(gè)活動(dòng)之間的關(guān)聯(lián)關(guān)系，它是需求分析的主線(xiàn)條，也是流程分析的主要產(chǎn)物。

組織級流程關(guān)注宏觀(guān)一般不會(huì )直接繪制，是對部門(mén)級流程的概括和抽象。崗位級流程關(guān)注每個(gè)業(yè)務(wù)活動(dòng)的執行步驟屬需求細節范疇，在流程分析階段不要過(guò)度進(jìn)入細節。

2.需求識別階段確認的流程均為部門(mén)級流程 需求人員在進(jìn)行流程分析應遵循如下方法：（1）業(yè)務(wù)流程確認：一個(gè)流程為一個(gè)業(yè)務(wù)事件，一般是外部角色發(fā)起或系統內部主動(dòng)發(fā)起（比如時(shí)間事件或狀態(tài)事件），發(fā)起后會(huì )觸發(fā)一系列業(yè)務(wù)活動(dòng)。（2）角色及業(yè)務(wù)活動(dòng)確認：流程圖中的每個(gè)泳道都必須對應到角色，每個(gè)角色對應多個(gè)業(yè)務(wù)活動(dòng)。

需求人員在確認業(yè)務(wù)活動(dòng)時(shí)一定要保證活動(dòng)的粒度，一個(gè)業(yè)務(wù)活動(dòng)一定是由一個(gè)角色完成且每個(gè)業(yè)務(wù)活動(dòng)都是有價(jià)值的活動(dòng)。比如項目輸入項目名稱(chēng)是一個(gè)執行步驟，這個(gè)動(dòng)作沒(méi)有價(jià)值，項目經(jīng)理查詢(xún)項目信息就是一個(gè)業(yè)務(wù)活動(dòng)。

在需求描述時(shí)針對線(xiàn)下活動(dòng)或新增活動(dòng)應該應標識區分。（3）業(yè)務(wù)活動(dòng)間關(guān)系及數據確認：確定所有業(yè)務(wù)活動(dòng)的前后置關(guān)系，并明確流程間的傳遞的數據實(shí)體。

（4）流程整體瓶頸分析：一般若某個(gè)角色業(yè)務(wù)活動(dòng)工作量較大，或流程涉及高級領(lǐng)導，一般都會(huì )造成瓶頸，這種情況需求人員應想辦法分散工作量提出流程優(yōu)化建議。3.針對統計查詢(xún)類(lèi)需求及接口類(lèi)需求，按照上述業(yè)務(wù)活動(dòng)確定原則分析、確定角色，并明確每個(gè)角色所執行的業(yè)務(wù)活動(dòng)即可。

三、數據實(shí)體分析 針對流程類(lèi)需求需要分析各業(yè)務(wù)活動(dòng)傳遞的數據實(shí)體，統計分析類(lèi)需求需要分析統計查詢(xún)條件和查詢(xún)展現兩類(lèi)數據實(shí)體、接口類(lèi)需求需要分析接口傳遞數據實(shí)體，具體分析包含如下內容：1.明確數據實(shí)體：確認需要分析的所有數據實(shí)體，明確哪些為系統原有實(shí)體、哪些為新增實(shí)體、哪些為改造實(shí)體。2.明確所有數據實(shí)體間關(guān)系：實(shí)體間關(guān)系包含（1對1、1對多、多對多），另外需要分析數據實(shí)體變更是否需要保留版本，實(shí)體刪除（邏輯刪除、物理刪除）是否影響其它數據實(shí)體。

3.明確數據實(shí)體字段：針對新增數據或改造數據實(shí)體需要明確新增字段的名稱(chēng)、字段類(lèi)型、是否必填、字段取值方式（人工輸入、系統自動(dòng)繼承自其它數據實(shí)體、系統自動(dòng)計算需要明確計算公式）。4.數據權限分析：需要分析不同角色在數據權限方面的差異，若涉及縱向多級用戶(hù)，要說(shuō)明對于集團/省/地市用戶(hù)的數據隔離。

四、角色及使用場(chǎng)景分析 一般來(lái)說(shuō)每個(gè)業(yè)務(wù)活動(dòng)是對用戶(hù)使用場(chǎng)景的抽象，每個(gè)業(yè)務(wù)活動(dòng)可能包含多個(gè)場(chǎng)景，分析使用場(chǎng)景時(shí)應按照業(yè)務(wù)活動(dòng)為主線(xiàn)逐個(gè)進(jìn)行分析，每個(gè)業(yè)務(wù)活動(dòng)分析時(shí)應包含如下內容：1.明確活動(dòng)執行角色。2.明確活動(dòng)執行的前置條件和后置條件。

3.明確不同場(chǎng)景：一個(gè)業(yè)務(wù)活動(dòng)可能包含正常的使用場(chǎng)景、備選使用場(chǎng)景和異常使用場(chǎng)景；4.明確每個(gè)場(chǎng)景的執行步驟：描述執行步驟時(shí)應使用簡(jiǎn)單的語(yǔ)法，主語(yǔ)明確語(yǔ)義易于理解，每個(gè)步驟不應該在任何一方（執行角色、系統）停留兩部以上，重點(diǎn)描述如何交互。5.業(yè)務(wù)規則和約束：明確在每個(gè)業(yè)務(wù)活動(dòng)下應遵循的業(yè)務(wù)規則和約束，這里一般是與業(yè)務(wù)流程相關(guān)的行為規則（比如項目周期時(shí)長(cháng)超過(guò)90天必須提交二級領(lǐng)導審批），或與數據實(shí)體相關(guān)的數據規則（需求交接單拒收時(shí)候必須填寫(xiě)拒收原因，且拒收原因不能超過(guò)500字）。

五、系統功能分析。

5.需求分析常用方法都有哪些,請舉例說(shuō)明

問(wèn)卷調查法，是指設計方就用戶(hù)需求中的一些個(gè)性化的、需要進(jìn)一步明確的需求或問(wèn)題，通過(guò)采用向用戶(hù)問(wèn)卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。

這種方法適合于設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進(jìn)一步溝通的需求或問(wèn)題就比較少，通過(guò)采用這種簡(jiǎn)單的問(wèn)卷調查方法就能使問(wèn)題得到較好的解決。

顯然對于樂(lè )百氏集團這樣規模龐大的公司，簡(jiǎn)單的問(wèn)卷調查是不能夠滿(mǎn)足準確獲得需求的需要的。會(huì )議討論法，是指設計方和用戶(hù)相關(guān)人員召開(kāi)若干次需求討論會(huì )議，達到徹底弄清項目需求的一種需求獲取方法。

這種方法適合于設計方不清楚用戶(hù)的詳細業(yè)務(wù)需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能準確地表達出他們的需求，而設計方有專(zhuān)業(yè)的需求，而我們有專(zhuān)業(yè)的軟件開(kāi)發(fā)經(jīng)驗，經(jīng)過(guò)回憶討論交流之后，能夠對用戶(hù)的需求進(jìn)行準確描述和把握。

這個(gè)方法對于準確的獲得樂(lè )百氏公司的需求是一種不錯的選擇。在本案例中系統的設計人員也是這么做的，他們通過(guò)和樂(lè )百氏項目組經(jīng)理的討論，很快了解了樂(lè )百氏的運作過(guò)程的數據。

界面原型法，是指設計方根據自己所了解的用戶(hù)需求，描畫(huà)出應用系統的功能界面后與用戶(hù)進(jìn)行交流和溝通，通過(guò)“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合于設計方和用戶(hù)都不是非常清楚項目需求、只是大概了解用戶(hù)需求的情況。

因為設計方和用戶(hù)方都不能非常準確的描述出客戶(hù)的需求，因此此時(shí)就更需要借助于一定的“載體”來(lái)加快對需求的挖掘和雙方對需求理解。

6.我們應當怎樣做需求確認：快速原型法

常常聽(tīng)到許多朋友跟我埋怨，需求分析之難，就在于用戶(hù)自身就常常弄不清楚自己的需求。起初在需求確認的時(shí)候說(shuō)得好好的，一到軟件上線(xiàn)的時(shí)候就不是那么回事了，這可沒(méi)法整。但我們只要坐下來(lái)仔細分析就會(huì )發(fā)現，在需求分析的時(shí)候我們跟用戶(hù)是在空對空地討論問(wèn)題。用戶(hù)不是專(zhuān)業(yè)人士，他也搞不清楚軟件到底會(huì )做成啥樣，所以你跟他確認的時(shí)候他就點(diǎn)頭了。但是，用戶(hù)不是傻子，當你軟件上線(xiàn)時(shí)，他拿到了實(shí)物了，知道軟件做成啥樣了，一旦不滿(mǎn)意他就開(kāi)始提變更了。所以，需求分析的癥結就在與這個(gè)實(shí)物。

既然癥結在此，毫無(wú)疑問(wèn)，我們就應當在需求分析階段拿出實(shí)物，用實(shí)物與用戶(hù)確認需求，這就是快速原型法的基本思想。快速原型法，簡(jiǎn)稱(chēng)原型法（Prototyping），是20世紀80年代提出的一種從設計思想、工具、手段都全新的系統開(kāi)發(fā)方法。它摒棄了那種一步步周密細致地調查分析，然后逐步整理出文字檔案，設計開(kāi)發(fā)，最后才能讓用戶(hù)看到軟件結果的繁瑣作法。當我們捕獲了一批業(yè)務(wù)需求以后，就立即使用快速可視化工具開(kāi)發(fā)出一個(gè)原型，交給用戶(hù)去試用、補充和修改。再提出一些新的需求以后，再開(kāi)發(fā)一版新的原型。原型法的關(guān)鍵就是這個(gè)快速開(kāi)發(fā)。不用考慮性能、美觀(guān)、可靠，原型的目的就是模擬客戶(hù)的需求，與客戶(hù)進(jìn)行確認的。整個(gè)需求分析的過(guò)程就是“捕獲需求->原型開(kāi)發(fā)->確認需求->再捕獲需求”的過(guò)程。

原型開(kāi)發(fā)的快速與模擬到什么程度，是一對矛盾，我們要去把握。要快速開(kāi)發(fā)，必然不可能和最終交付的軟件系統一模一樣，許多復雜問(wèn)題被簡(jiǎn)化，非關(guān)鍵性流程被忽略，這就是所謂的模擬。因此，模擬到什么程度是關(guān)鍵，既能說(shuō)明問(wèn)題，又不耽誤時(shí)間。根據我的經(jīng)驗，一般能拿出界面，并可以走通關(guān)鍵性流程就可以了。一些快速開(kāi)發(fā)平臺為快速原型法提供了可能。

當用戶(hù)拿到原型可以自己操作時(shí)，需求研討的氣氛立即變得不太一樣了。當用戶(hù)享受原型給他們帶來(lái)體驗的快感時(shí)，需求被源源不斷地被提出來(lái)。這時(shí)候的需求，就不再是枯燥無(wú)味的文字游戲，而是生動(dòng)形象的圖形界面。日后，如果項目采用迭代開(kāi)發(fā)，讓用戶(hù)看著(zhù)軟件一點(diǎn)兒一點(diǎn)兒地成長(cháng)，這又是多么美妙的體驗啊。與此同時(shí)，你與用戶(hù)的信任也在一步一步建立起來(lái)，軟件風(fēng)險在降低，項目將朝著(zhù)正確方向前進(jìn)。

快速原型法是美妙的，它給你與用戶(hù)帶來(lái)了從未有過(guò)的體驗。但美妙的同時(shí)，也會(huì )帶來(lái)一些的尷尬，不必要的誤會(huì )，我們一定要注意。最常見(jiàn)的誤會(huì )就是讓用戶(hù)將原型誤以為最終交付的系統。開(kāi)發(fā)一個(gè)系統需要持續數月，但你倒好，幾天就搞定了，為什么還要在這個(gè)系統上投入大量資金呢？如果對方領(lǐng)導開(kāi)始有這樣的想法時(shí)，雙方就開(kāi)發(fā)費用進(jìn)行的談判就有一些不妙了。所以在給用戶(hù)看到原型前，一定要跟用戶(hù)解釋清楚。

既然是原型，必要的校驗、非正常操作的處理通通都被忽略。因此，當演示原型出錯時(shí)，用戶(hù)你可千萬(wàn)不要較真喲！這丑話(huà)可得說(shuō)在前頭，否則用戶(hù)跟你較起真來(lái)，你在用戶(hù)心目中的形象可就要大打折扣了。

我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪(fǎng)我們應當怎樣做需求調研：研討會(huì )我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業(yè)務(wù)流程分析（上）我們應當怎樣做需求分析：業(yè)務(wù)流程分析（下）我們應當怎樣做需求分析：用例說(shuō)明我們應當怎樣做需求分析：查詢(xún)報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動(dòng)圖和狀態(tài)圖我們應當怎樣做需求分析：業(yè)務(wù)領(lǐng)域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領(lǐng)域驅動(dòng)設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個(gè)需求列表的實(shí)例我們應當怎樣做需求確認：需求規格說(shuō)明書(shū)我們應當怎樣做需求確認：評審與簽字確認會(huì )（續）

7.我們應當怎樣做需求確認：評審與簽字確認會(huì )

時(shí)間過(guò)得真快，經(jīng)過(guò)一系列需求研討、需求分析和整理確認，我們整理出了需求列表，編寫(xiě)出了需求規格說(shuō)明書(shū)，一切似乎該到結束需求分析階段的時(shí)候了。但是，敏捷大師的一句話(huà)讓我們徹底心涼到了骨頭里。敏捷大師說(shuō)了，我們不可能在需求分析階段完成所有的需求分析工作，它將延續到設計、開(kāi)發(fā)，甚至測試階段。

一直以來(lái)，我對這句話(huà)非常困惑。既然需求分析階段不能完成所有的需求分析工作，那么完成多少才算結束呢？80%?60%？或者更少？大師沒(méi)有給出一個(gè)標準。大師就是大師，生活在太空里的，我們慢慢理解吧。經(jīng)過(guò)多年的實(shí)踐，我慢慢理解了。我們說(shuō)這種需求分析工作不可能完全完成，或者說(shuō)日后用戶(hù)的需求會(huì )變，其實(shí)并不是毫無(wú)規律可循的。通常，用戶(hù)對需求的變更只發(fā)生在某些固定的范圍內，弄清楚了這些范圍，我們的問(wèn)題就迎刃而解了。

1. 整體需求不變，具體細節變化。我們說(shuō)需求是分層次的，整體框架、功能模塊、每個(gè)操作的細節。如果用戶(hù)變更到了將整個(gè)框架都推翻了，這個(gè)項目就別做了。所以整體框架是必須在需求分析階段完成的，是日后不可能改變的。功能模塊可能要變，但通常是某個(gè)部分在變，而更多的是那些具體操作的細節在變。

2. 界面風(fēng)格與操作易用性是最容易發(fā)生變更的。我們說(shuō)用戶(hù)看到軟件以后不滿(mǎn)意，其實(shí)主要是對界面風(fēng)格與操作性不滿(mǎn)意，而不是軟件功能。界面不夠美觀(guān)，操作不方便，不符合用戶(hù)的操作習慣，都是造成用戶(hù)不滿(mǎn)意的地方。

3. 增加其它功能。軟件是對現實(shí)的模擬，而現實(shí)也是復雜多變的。我們與用戶(hù)在進(jìn)行業(yè)務(wù)流程分析時(shí)，也許一些流程沒(méi)有考慮到，或者還有特殊情況需要處理。這些是客戶(hù)要求增加功能的主要動(dòng)因。

OK，萬(wàn)事俱備只欠東風(fēng)，當所有工作都完備以后，我們的需求分析工作開(kāi)始進(jìn)入最后收尾的階段。我們說(shuō)，需求分析階段的產(chǎn)出物是需求列表與需求規格說(shuō)明書(shū)，而最終結束的里程碑無(wú)疑就是需求評審會(huì )了，或者說(shuō)與用戶(hù)的簽字確認會(huì )。

需求評審會(huì )的主要目的就是確認需求，以便以此開(kāi)始我們的設計開(kāi)發(fā)工作。從理論上說(shuō)，需求評審會(huì )應當由用戶(hù)代表，與項目經(jīng)理、需求分析員、系統架構師、設計人員、測試人員、QA經(jīng)理，還有公司相關(guān)領(lǐng)導參加。但實(shí)際上，讓如此多不同角色的人聚集在一起開(kāi)會(huì )是不現實(shí)的。因此，我們可以將需求評審會(huì )分為內部評審會(huì )與外部評審會(huì )兩部分來(lái)開(kāi)比較現實(shí)。

處理外部問(wèn)題，必先要從內部統一思想。先召開(kāi)一個(gè)內部評審會(huì )，聽(tīng)聽(tīng)系統架構師、設計人員、測試人員、QA經(jīng)理對需求分析工作的意見(jiàn)，然后由領(lǐng)導講講話(huà)，布置一下后面的工作，是十分有必要的。按照我的經(jīng)驗，系統架構師這時(shí)的作用相當重要，他應當仔細閱讀需求，仔細思考技術(shù)是否可行，以及預測該系統是否能夠達到用戶(hù)方領(lǐng)導對該項目制訂的目標。如果答案是否定，立即進(jìn)行調整。

最后就是與用戶(hù)的外部需求評審會(huì )了。外部需求評審會(huì )，也可稱(chēng)為簽字確認會(huì )議，就是與用戶(hù)就需求規格說(shuō)明書(shū)進(jìn)行評審，最后簽字確認。用戶(hù)簽過(guò)字的東西，不可能完全抑制住用戶(hù)的變更，但至少從很大程度上抑制住了用戶(hù)的大改。然而，在召開(kāi)外部需求評審會(huì )之前，我們建議大家就需求規格說(shuō)明書(shū)，先與各個(gè)單位或部門(mén)的用戶(hù)代表討論并確定下來(lái)，避免在最終的簽字確認會(huì )上出現分歧，影響工作進(jìn)度。畢竟大家都不容易，工作一大堆，聚在一起不容易。

經(jīng)過(guò)數月的分析討論，最終在一片和諧的氣氛中，雙方領(lǐng)導在需求規格說(shuō)明書(shū)上簽字，項目開(kāi)始進(jìn)入一個(gè)新的輪回。在這個(gè)輪回中，是焦頭爛額、不勝其苦，還是如履薄冰、最終順利交付，是與許多因素有關(guān)的。但我想說(shuō)，一份高質(zhì)量的需求分析必定起到?jīng)Q定性的作用，必定為日后的軟件開(kāi)發(fā)掃清了許多許多的地雷。

我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪(fǎng)我們應當怎樣做需求調研：研討會(huì )我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業(yè)務(wù)流程分析（上）我們應當怎樣做需求分析：業(yè)務(wù)流程分析（下）我們應當怎樣做需求分析：用例說(shuō)明我們應當怎樣做需求分析：查詢(xún)報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動(dòng)圖和狀態(tài)圖我們應當怎樣做需求分析：業(yè)務(wù)領(lǐng)域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領(lǐng)域驅動(dòng)設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個(gè)需求列表的實(shí)例我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規格說(shuō)明書(shū)（全文終）

8.確定信息需求的三個(gè)步驟

收集需求，分析需求的重要性，確定需求。

1、需求優(yōu)先級的定義應根據當時(shí)的環(huán)境和實(shí)際情況，是否有足夠的理論支持和數據支持，滿(mǎn)足需求后的分析結果是否清晰等。當定義一個(gè)需求是否被確定為一個(gè)明確的需求時(shí)，這些都被考慮在內。

2、有四個(gè)要求優(yōu)先：重要和緊急；重要和不緊急；緊急和不重要；不緊急和不重要。這四種情況也是我們處理需求優(yōu)先的原則，即重要性+緊迫性。

3、還應考慮需求的風(fēng)險與價(jià)值之間的關(guān)系。高價(jià)值-高風(fēng)險的功能需求應優(yōu)先考慮，即優(yōu)先考慮獲得高價(jià)值回報，而早期處理可以有效地消除重大風(fēng)險。

4、對于高值低風(fēng)險的功能需求，所提供的價(jià)值是等價(jià)的，但由于風(fēng)險較低，可以以后進(jìn)行。

5、對于低價(jià)值低風(fēng)險的功能需求，應該排在第三位，放棄它們對產(chǎn)品總價(jià)值的影響很小，而且風(fēng)險也很低。

6、對于低值高風(fēng)險的功能需求，顯然最好盡量避免開(kāi)發(fā)或推遲工作。

擴展資料：

信息需求的內容構成

1、信息要求，包括信息內容和形式的要求。信息的內容反映了信息所屬的學(xué)科，如“生物信息”、“經(jīng)濟信息”、“環(huán)境保護信息”；信息的形式多種多樣，如“知識信息”或“信息信息”、政策信息、市場(chǎng)信息或“產(chǎn)品信息”。

2、對信息源的要求，包括信息源的范圍和載體形式。用戶(hù)對這些方面有不同的要求。

參考資料來(lái)源：

百度百科-信息需求