需求確認方法有哪些

① 如何確定課程的培訓需求

制定培訓需求調查計劃
培訓需求調查計劃是保證培訓需求調查順利開展的前提，制定一個完整的培訓需求調查計劃，主要有以下幾個步驟：
1.確定培訓需求調查目標
調查工作應達到一個什麼樣的目標，一般而言，是完全確立某種培訓的需要。但由於在培訓需求調查中會有各種客觀或主觀的原因，培訓需求調查的結果並不是完全可信的。因此，要盡可能排除其他因素的影響，提高培訓需求調查結果的可信度。
2.選擇培訓需求調查方法
培訓需求調查方法包括面談法、重點團隊分析法、工作任務分析法、觀察法、問卷調查法等等。
根據企業的實際情況以及培訓中可利用的資源選擇一種合適的培訓方法。一般來說，工作任務安排非常緊湊的企業員工不宜對其採用面談法；而專業技術性較強的員工一般不用觀察法。
3.明確培訓需求調查內容
分析培訓調查應得到什麼資料，除去手中已有的資料，就是調查內容。調查內容不宜太廣泛，對一項內容應進行多角度調查。一般來說，培訓需求調查的內容包括企業全體員工基本情況分析，員工知識、技能和態度分析；培訓環境因素的分析等等。
制定一份合理的培訓需求調查計劃有利於培訓需求調查工作的開展。而制定一份調查計劃就必須確定目標、選擇方法和明確內容。
實施培訓需求調查工作
有效地實施培訓需求調查工作是獲取培訓需求信息的關鍵。在開展培訓需求調查時，應明確以下問題：
1.了解受訓員工現狀
(1)了解員工在組織中的位置。不同職位的員工有不同的培訓需求。
(2)以前是否受過培訓，要盡可能避免內容相同的培訓。
(3)員工有過什麼樣的培訓。
(4)培訓的形式有哪些。培訓形式上的選擇應該盡可能地豐富，這樣才能提高培訓效果。

② 溝通如何確認對方的需求

收集信息和發現需求時 開始和結束談話 控制談話方向時 制止別人滔滔不絕的談話時 徵求別人意見 不明白或不相信需要確認時提出建議時處理異議時有效應用兩種提問方式: 通 常, 我 們 會 用 開 放 式 問 題 開 頭, 一 旦 談 話 偏 離 你 的 主 題, 用 封 閉 性 問 題進 行 限 制, 如 果 發 現 對 方 有 些 緊 張, 再 改 用 開 放 式 問 題。 避免無用的問題：引導性問題多重問題 積極聆聽的作用： 為了獲得更多信息 幫助把談話繼續下去 處理不同的意見 有效發表自己的意見 保持溝通氣氛的友好  反省自己是否做過: 當別人講話時,你在想自己的事 聽別人講話時,不斷比較與自己想法的不同點 打斷別人的講話 為講演者結束他的講演 當別人講話時談論其他的事情 忽略過程而只要結論 僅僅聽那些自己想聽的或希望聽的事和內容 是否人的外觀或他們的說話方式給你客觀的聽造成困難是否很容易被其他的背景或聲音分散注意力

③ 我們應當怎樣做需求確認：評審與簽字確認會

時間過得真快，經過一系列需求研討、需求分析和整理確認，我們整理出了需求列表，編寫出了需求規格說明書，一切似乎該到結束需求分析階段的時候了。但是，敏捷大師的一句話讓我們徹底心涼到了骨頭里。敏捷大師說了，我們不可能在需求分析階段完成所有的需求分析工作，它將延續到設計、開發，甚至測試階段。 一直以來，我對這句話非常困惑。既然需求分析階段不能完成所有的需求分析工作，那麼完成多少才算結束呢？80%？60%？或者更少？大師沒有給出一個標准。大師就是大師，生活在太空里的，我們慢慢理解吧。經過多年的實踐，我慢慢理解了。我們說這種需求分析工作不可能完全完成，或者說日後用戶的需求會變，其實並不是毫無規律可循的。通常，用戶對需求的變更只發生在某些固定的范圍內，弄清楚了這些范圍，我們的問題就迎刃而解了。 1. 整體需求不變，具體細節變化。我們說需求是分層次的，整體框架、功能模塊、每個操作的細節。如果用戶變更到了將整個框架都推翻了，這個項目就別做了。所以整體框架是必須在需求分析階段完成的，是日後不可能改變的。功能模塊可能要變，但通常是某個部分在變，而更多的是那些具體操作的細節在變。 2. 界面風格與操作易用性是最容易發生變更的。我們說用戶看到軟體以後不滿意，其實主要是對界面風格與操作性不滿意，而不是軟體功能。界面不夠美觀，操作不方便，不符合用戶的操作習慣，都是造成用戶不滿意的地方。 3. 增加其它功能。軟體是對現實的模擬，而現實也是復雜多變的。我們與用戶在進行業務流程分析時，也許一些流程沒有考慮到，或者還有特殊情況需要處理。這些是客戶要求增加功能的主要動因。 OK，萬事俱備只欠東風，當所有工作都完備以後，我們的需求分析工作開始進入最後收尾的階段。我們說，需求分析階段的產出物是需求列表與需求規格說明書，而最終結束的里程碑無疑就是需求評審會了，或者說與用戶的簽字確認會。 需求評審會的主要目的就是確認需求，以便以此開始我們的設計開發工作。從理論上說，需求評審會應當由用戶代表，與項目經理、需求分析員、系統架構師、設計人員、測試人員、QA經理，還有公司相關領導參加。但實際上，讓如此多不同角色的人聚集在一起開會是不現實的。因此，我們可以將需求評審會分為內部評審會與外部評審會兩部分來開比較現實。 處理外部問題，必先要從內部統一思想。先召開一個內部評審會，聽聽系統架構師、設計人員、測試人員、QA經理對需求分析工作的意見，然後由領導講講話，布置一下後面的工作，是十分有必要的。按照我的經驗，系統架構師這時的作用相當重要，他應當仔細閱讀需求，仔細思考技術是否可行，以及預測該系統是否能夠達到用戶方領導對該項目制訂的目標。如果答案是否定，立即進行調整。 最後就是與用戶的外部需求評審會了。外部需求評審會，也可稱為簽字確認會議，就是與用戶就需求規格說明書進行評審，最後簽字確認。用戶簽過字的東西，不可能完全抑制住用戶的變更，但至少從很大程度上抑制住了用戶的大改。然而，在召開外部需求評審會之前，我們建議大家就需求規格說明書，先與各個單位或部門的用戶代表討論並確定下來，避免在最終的簽字確認會上出現分歧，影響工作進度。畢竟大家都不容易，工作一大堆，聚在一起不容易。 經過數月的分析討論，最終在一片和諧的氣氛中，雙方領導在需求規格說明書上簽字，項目開始進入一個新的輪回。在這個輪回中，是焦頭爛額、不勝其苦，還是如履薄冰、最終順利交付，是與許多因素有關的。但我想說，一份高質量的需求分析必定起到決定性的作用，必定為日後的軟體開發掃清了許多許多的地雷。 我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規格說明書（全文終）

④ 如何精準確定用戶的需求

實事求是的說，發現用戶真正的需求比較難。人的心理都不一樣，你這樣想，人家不一定這樣想。
比如說，我們每天都在用的微信，有的人覺得設計的挺好，有的人就覺得不能傳送大的文件，不如QQ。等等，想發現用戶真正的需求，可以從以下幾點著手
1、觀察他的社交軟體，用心體會客戶是怎樣的人，有著怎樣的愛好。
2、用心交流，發現客戶需求。
3、可以通過做調查問卷發現需求。

⑤ 1、 什麼是培訓需求 2、 確定企業培訓需求的方法有哪些 3、 各種方法的使用范圍

1.培訓需求：簡單說就是你的客戶需要什麼。想要什麼。缺什麼。然後你們公司打算補充說明。有什麼地方需要改進的，同時又沒有什麼好的方法。這個就是培訓需求了。
2.方法其實很多，一般建議先了解一下他們企業的背景，企業文化，所在行業，企業性質，然後電話聯系，確認對方是不是需要培訓，如果需要培訓，大概的時間是什麼時候，打算在那些方面得到提升或者改進，打算投入的費用是多少（這個很重要，高了還好，要是低了，就很麻煩。基本上要花很長時間。），確認對方的意向，最後在是問卷調查，員工面談。
3.電話：范圍最大，只要對方有意向，有時間都可以去聯系
調查表：這個屬於拜訪的時候的利器，可以讓你從客戶手中的到很多資料。
拜訪：拜訪這種情況最好的前提是客戶能夠讓有分量的人出來和你溝通。要不再怎麼溝通都是扯淡，沒有什麼意思。最好是直接把公司老闆弄出來和你溝通。基本上這個就是一錘定音了。

⑥ 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。

⑦ 如何進行需求管理

需求管理源於業務需要，始於需求挖掘，繼而需求分析，需求定義，需求驗證。周而復始。

一，業務需要說明需求產生的原因，可能是高層制定的目標，中層對工作流程的調整，基層碰到無法解決的問題，用戶需要，外部環境變化，競爭對手策略變化或者政府政策調整等。
需求人員在明確業務需要時，首先明確干係人，其次獲取干係人要求/需求。可以採用的方法包括：行業基準（競品），業務規則分析（產品分析），頭腦風暴，焦點小組，功能分解，根源分析等。
二，需求挖掘階段的目標是找出干係人的真實需求。單方面的口頭描述或者規范章程都可能與實際需求相差甚遠，因此需要需求人員收集各方面需要，交叉驗證，合理推導，發掘出用戶的實際需求。
工作步驟：確認干係人，收集實際情況，整合多方面信息，確認實際需要。方法包括：訪談，觀察，問卷，焦點小組，頭腦風暴，可用性測試，競品分析，數據分析，文檔分析，咨詢專家等。
三，需求分析階段則是對已經收集的真實需求進行規整，包括兩部分內容，組織整理需求和對需求排優先順序。
組織整理需求採用相同粒度描述需求，並描述需求間關系。主要方法包括：功能分解，業務規則分析，數據模型，流程模型，范圍模型，用戶經歷，場景和用例，組織模型。
需求優先順序劃分通過定義需求的優先順序，為計劃安排提供有價值的參考。可以參考的定義維度包括：時間，預算，業務價值，業務和技術風險，實施難度，成功可能性，規范和政策，與其他需求的關系，與干係人的協議，緊急程度等。可採用3/4級優先順序定義，或者MoSCoW模型定義，其中M=必須 S=應該 C=能夠W=將要。
四，需求定義主要工作為根據前期整理的相關文檔整理需求說明。輸出包括：業務需要，需求陳述，組織整理後的需求以及需求優先順序。需求說明主要包括：業務需要，業務需求和系統需求。·
五，需求驗證包括需求檢驗和需求確認，即需求過程中的檢查和需求完成的測試。
需求跟蹤矩陣是個好東西，可以在需求分析階段產出。

⑧ 確定信息需求的三個步驟

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

1、需求優先順序的定義應根據當時的環境和實際情況，是否有足夠的理論支持和數據支持，滿足需求後的分析結果是否清晰等。當定義一個需求是否被確定為一個明確的需求時，這些都被考慮在內。

2、有四個要求優先：重要和緊急；重要和不緊急；緊急和不重要；不緊急和不重要。這四種情況也是我們處理需求優先的原則，即重要性＋緊迫性。

3、還應考慮需求的風險與價值之間的關系。高價值－高風險的功能需求應優先考慮，即優先考慮獲得高價值回報，而早期處理可以有效地消除重大風險。

4、對於高值低風險的功能需求，所提供的價值是等價的，但由於風險較低，可以以後進行。

5、對於低價值低風險的功能需求，應該排在第三位，放棄它們對產品總價值的影響很小，而且風險也很低。

6、對於低值高風險的功能需求，顯然最好盡量避免開發或推遲工作。

(8)需求確認方法有哪些擴展閱讀：

信息需求的內容構成

1、信息要求，包括信息內容和形式的要求。信息的內容反映了信息所屬的學科，如「生物信息」、「經濟信息」、「環境保護信息」；信息的形式多種多樣，如「知識信息」或「信息信息」、政策信息、市場信息或「產品信息」。

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

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

常常聽到許多朋友跟我埋怨，需求分析之難，就在於用戶自身就常常弄不清楚自己的需求。起初在需求確認的時候說得好好的，一到軟體上線的時候就不是那麼回事了，這可沒法整。但我們只要坐下來仔細分析就會發現，在需求分析的時候我們跟用戶是在空對空地討論問題。用戶不是專業人士，他也搞不清楚軟體到底會做成啥樣，所以你跟他確認的時候他就點頭了。但是，用戶不是傻子，當你軟體上線時，他拿到了實物了，知道軟體做成啥樣了，一旦不滿意他就開始提變更了。所以，需求分析的症結就在與這個實物。 既然症結在此，毫無疑問，我們就應當在需求分析階段拿出實物，用實物與用戶確認需求，這就是快速原型法的基本思想。快速原型法，簡稱原型法（Prototyping），是20世紀80年代提出的一種從設計思想、工具、手段都全新的系統開發方法。它摒棄了那種一步步周密細致地調查分析，然後逐步整理出文字檔案，設計開發，最後才能讓用戶看到軟體結果的繁瑣作法。當我們捕獲了一批業務需求以後，就立即使用快速可視化工具開發出一個原型，交給用戶去試用、補充和修改。再提出一些新的需求以後，再開發一版新的原型。原型法的關鍵就是這個快速開發。不用考慮性能、美觀、可靠，原型的目的就是模擬客戶的需求，與客戶進行確認的。整個需求分析的過程就是「捕獲需求->原型開發->確認需求->再捕獲需求」的過程。 原型開發的快速與模擬到什麼程度，是一對矛盾，我們要去把握。要快速開發，必然不可能和最終交付的軟體系統一模一樣，許多復雜問題被簡化，非關鍵性流程被忽略，這就是所謂的模擬。因此，模擬到什麼程度是關鍵，既能說明問題，又不耽誤時間。根據我的經驗，一般能拿出界面，並可以走通關鍵性流程就可以了。一些快速開發平台為快速原型法提供了可能。 當用戶拿到原型可以自己操作時，需求研討的氣氛立即變得不太一樣了。當用戶享受原型給他們帶來體驗的快感時，需求被源源不斷地被提出來。這時候的需求，就不再是枯燥無味的文字游戲，而是生動形象的圖形界面。日後，如果項目採用迭代開發，讓用戶看著軟體一點兒一點兒地成長，這又是多麼美妙的體驗啊。與此同時，你與用戶的信任也在一步一步建立起來，軟體風險在降低，項目將朝著正確方向前進。 快速原型法是美妙的，它給你與用戶帶來了從未有過的體驗。但美妙的同時，也會帶來一些的尷尬，不必要的誤會，我們一定要注意。最常見的誤會就是讓用戶將原型誤以為最終交付的系統。開發一個系統需要持續數月，但你倒好，幾天就搞定了，為什麼還要在這個系統上投入大量資金呢？如果對方領導開始有這樣的想法時，雙方就開發費用進行的談判就有一些不妙了。所以在給用戶看到原型前，一定要跟用戶解釋清楚。 既然是原型，必要的校驗、非正常操作的處理通通都被忽略。因此，當演示原型出錯時，用戶你可千萬不要較真喲！這丑話可得說在前頭，否則用戶跟你較起真來，你在用戶心目中的形象可就要大打折扣了。 我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）