項(xiàng)目需求確認(rèn)方法(需求分析方法)

1.需求分析有哪些方法

三種需求分析的方法：結(jié)構(gòu)化分析方法、面向?qū)ο蟮姆治龇椒ā⒚嫦騿栴}域的分析方法。

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

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

2.需求確認(rèn)的方法

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

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

3.簡述采購需求數(shù)量確定的方法

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

2.商品采購市場預(yù)測的目的

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

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

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

3.預(yù)測在采購中的作用P95（看）

4.獨(dú)立需求物料的采購需求確定

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

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

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

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

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

6.物料需求計(jì)劃（MPR）

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

7.分銷需求計(jì)劃（DRP）

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

1）分析采購項(xiàng)目供應(yīng)資料

2）計(jì)算總體定單容量

3）計(jì)算承接定單容量

4）確定剩余定單容量

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

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

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

11.采購預(yù)算的主要作用

1）保障企業(yè)戰(zhàn)略計(jì)劃和作業(yè)計(jì)劃的執(zhí)行，確保企業(yè)組織目標(biāo)一致

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、系統(tǒng)功能分析。

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

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

這種方法適合于設(shè)計(jì)方和建設(shè)方、使用方都清楚項(xiàng)目需求的情況。因?yàn)榻ㄔO(shè)方和使用方都清楚項(xiàng)目的需求，需要雙方進(jìn)一步溝通的需求或問題就比較少，通過采用這種簡單的問卷調(diào)查方法就能使問題得到較好的解決。

顯然對于樂百氏集團(tuán)這樣規(guī)模龐大的公司，簡單的問卷調(diào)查是不能夠滿足準(zhǔn)確獲得需求的需要的。會議討論法，是指設(shè)計(jì)方和用戶相關(guān)人員召開若干次需求討論會議，達(dá)到徹底弄清項(xiàng)目需求的一種需求獲取方法。

這種方法適合于設(shè)計(jì)方不清楚用戶的詳細(xì)業(yè)務(wù)需求，但使用方清楚項(xiàng)目需求的情況。因?yàn)槭褂梅角宄?xiàng)目的需求，他們能準(zhǔn)確地表達(dá)出他們的需求，而設(shè)計(jì)方有專業(yè)的需求，而我們有專業(yè)的軟件開發(fā)經(jīng)驗(yàn)，經(jīng)過回憶討論交流之后，能夠?qū)τ脩舻男枨筮M(jìn)行準(zhǔn)確描述和把握。

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

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

因?yàn)樵O(shè)計(jì)方和用戶方都不能非常準(zhǔn)確的描述出客戶的需求，因此此時(shí)就更需要借助于一定的“載體”來加快對需求的挖掘和雙方對需求理解。

6.我們應(yīng)當(dāng)怎樣做需求確認(rèn)：快速原型法

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

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

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

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

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

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

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

7.我們應(yīng)當(dāng)怎樣做需求確認(rèn)：評審與簽字確認(rèn)會

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

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

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

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

3. 增加其它功能。軟件是對現(xiàn)實(shí)的模擬，而現(xiàn)實(shí)也是復(fù)雜多變的。我們與用戶在進(jìn)行業(yè)務(wù)流程分析時(shí)，也許一些流程沒有考慮到，或者還有特殊情況需要處理。這些是客戶要求增加功能的主要?jiǎng)右颉?/p>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

擴(kuò)展資料：

信息需求的內(nèi)容構(gòu)成

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

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

參考資料來源：

百度百科-信息需求