1. 前言

1.1 意圖和價值

意圖：明确需求，確定利益相關者的共同了解，并調整需求、計劃和工作産品。

價值：確定客戶的需求和期望得到滿足。

1.2 适用範圍

本過程文檔是項目經理需求開發人員（包括：售前市場人員、需求調研人員等）執行需求開發與管理過程活動的依據和指導。本過程适用于公司所有軟體項目，且貫穿于整個生命周期。

1.3 名詞術語

使用者需求

是使用者對要建立的系統的要求描述，它主要說明使用者“要做什麼”、“想做什麼”的問題。

軟體需求

也叫産品需求，是軟體産品能否滿足使用者需求的要求描述，它主要說明軟體産品“能做什麼”、“不能做什麼”的問題。

2. 過程定義

2.1 角色和職責

角色	職責描述
高層經理	1. 評審、準許使用者需求、産品需求等過程産品，并參與本過程域重要的活動； 2. 解決在實施本過程域中所遇到的無法解決的問題
項目經理	1. 為需求開發工作提供各種必要的環境和條件； 2. 制訂需求開發計劃，并跟蹤維護該計劃； 3. 負責聯系使用者和需求人員進行需求開發工作； 4. 參與評審本過程域的工作産品； 5. 完成或協助完成本過程域的工作産品； 6. 對需求進行變更管理、跟蹤控制； 7. 向高層經理報告本過程域的實施情況；
需求開發人員	1. 負責對市場、客戶的需求調研； 2. 收集、分析、細化、導出和描述使用者需要、期望、限制和接口，并把它們轉換成使用者需求； 3. 完成需求開發，編寫《使用者需求說明書》和《産品需求規格說明書》等需求文檔； 4. 負責對需求的後期跟蹤； 5. 負責執行需求的變更。
美工	1. 根據使用者需求和産品需求，在需求開發人員的指導下，完成開發原型Demo的制作； 2. 和需求開發人員一起，向使用者進行開發原型Demo示範。
項目組成員	參加需求開發與管理活動的評審。
客戶	1. 配合并參與需求的調研活動； 2. 評審并确認需求開發的所有文檔； 3. 對《使用者需求說明書》和《産品需求規格說明書》、需求Demo等進行确認；
CCB	1. 評審需求文檔是否滿足了使用者的真實意願。 2. 審批需求變更申請。
CM	1. 為評審後的需求文檔進行配置管理。
QA	1. 檢查和監督需求管理活動的有效性和一緻性。 2. 将檢查出來的問題及時通報給項目經理及項目組成員，并跟蹤問題直到關閉。

2.2 入口準則

需求開發人員已經确定；

初步的《項目計劃》已經通過評審。

2.3 輸入

初步的《項目計劃》；

《項目合同》；

《技術解決方案》；

客戶原始需求文檔。

2.4 過程活動

需求階段包括需求開發和需求管理兩個過程活動。

需求開發過程

需求開發過程是擷取使用者需求并對使用者需求進行分析整理形成軟體需求的過程。需求開發過程可以包括使用者需求調研、使用者需求分析、軟體需求定義和軟體需求評審四個過程，也可以根據具體情況對該過程進行裁減。

需求開發的結果文檔包括使用者需求類文檔、軟體需求類文檔、有時為了滿足軟體産品前期設計的需要，也會制作形成業務模型、資料字典、系統開發原型（Demo）文檔等。

所有的需求文檔經過使用者和開發方雙方評審認可并簽字後，形成項目的需求基線。

需求管理過程

需求管理是在需求文檔基線化後，對需求實作的跟蹤以及當需求發生變更時，對需求變更進行控制和管理的過程。

需求管理包括變更控制、版本控制、需求跟蹤過程。需求管理同時包括變更的需求及相關需求之間的關系管理。

2.4.1 需求開發過程

需求開發過程

2.4.1.1 使用者需求調研

在項目正式立項後，項目經理組建需求開發團隊，需求開發人員根據初步《項目計劃》、客戶原始需求文檔（包括：市場人員從客戶那裡得到的初步需求文檔，投标檔案中定義的技術方案内容等），确定需求調研時間及需求擷取相關幹系人，并将此活動更新到《幹系人計劃》中，同時制定出《需求調研計劃》。在識别需求擷取幹系人時，需求開發人員需考慮以下幾準則：

1.相關幹系人要具備足夠的業務經驗。

2.相關幹系人要具有較強的表達能力。

3.相關幹系人至少具備初級的計算機水準。

在需求開發人員開始進行使用者需求調研之前，要進行充分的事前準備。需要準備的工作包括：

1.需求開發人員要提前了解該行業的标準、相關檔案、公司規章制度等。

2.需求開發人員從組織資産庫中尋找類似項目的需求資料，對相關需求資料有一個深入了解，以便迅速了解可以重用的業務需求内容，為與客戶深入、專業的需求溝通打下基礎。

3.需求開發人員确定需求調研方式，具體方式包括：客戶主動提供的需求說明文檔，與使用者面談或電話訪談或會議訪談、參觀使用者的工作流程、向使用者群體發調查問卷、與同行專家交談、分析已經存在的同類軟體産品等。

4.需求開發人員根據標明的調研方式，準備好《使用者需求調查單》。

需求開發人員根據《需求調研計劃》開展調研工作。調研工作需要需求開發人員和使用者協同完成。調研中需求調研人員要随時做好記錄，事後填寫好《使用者需求調查單》，作為原始使用者需求，有進行組織會議訪談的要填寫《需求訪談會議紀要》。

需求開發人員根據需求調研的訪談成果，對使用者的原始需求進行分析整理，提取需求的精華，對使用者需求進行歸納總結，把相同的需求進行歸類，把文檔盡可能的用使用者容易了解的語言撰寫（包括：用例圖/用例簡述/用例規約描述等）。按照歸納總結的使用者需求點，需求開發人員編寫《使用者需求說明書》。

《使用者需求說明書》的主要内容包括：

需求産生的背景

需求目标要求

需求内容範圍

使用者角色

功能性需求的描述

限制條件

非功能性要求等。

《使用者需求調查單》、《使用者需求說明書》編寫完成後，需要得到使用者和開發方雙方的共同确認，确認的方式開始是正式的、也可以是非正式的。一般通過内/外部評審會議、使用者簽字或非正式的其他方式（如确認郵件等）确認即可。

使用者需求确認後，需求開發人員建立《需求跟蹤矩陣》，并将使用者需求項填入《需求跟蹤矩陣》中。

使用者需求調研活動可參考《需求調研指南》。

2.4.1.2 使用者需求分析

使用者需求分析的目的是為了明确使用者需求的具體細節以及軟體産品實作的可行性，把使用者需求合理的轉化成軟體産品需求。使用者需求分析的主要内容包括：

分析使用者需求的實作可行性

在允許的成本、性能要求下，需求開發人員要分析每項使用者需求進行軟體産品實作的可行性，同時明确與每項需求實作相聯系的風險，包括與其它需求的沖突，對外界因素的依賴和技術障礙等。

确定需求的優先級别

應用需求分析方法來确定系統特性或單項需求實作的優先級别。以優先級為基礎确定軟體産品将包括哪些特性或哪類需求。

建立業務模型（可選）

有時為了滿足軟體産品前期設計的需要，或者需求開發人員對比較複雜的使用者需求難以了解時，一般對需求進行模組化分析，以幫助軟體開發人員更好地了解需求。

根據使用者需求分析得到的需求描述，借助于需求分析工具建立相應的業務模型。根據項目的實際情況，選擇不同的模組化方法。如：采用結構化的需求分析方法或采用面向對象的需求分析方法，通過UML方法來進行建立業務模型。

建議使用Rational Rose、MS Visio等模組化工具進行需求的模組化分析，通過分析系統的功能模型、結構模型和行為模型，進行系統模組化。模組化的過程包括系統功能模組化、系統資料模組化和體系結構模組化，在需求開發階段應至少完成功能模組化。功能模組化的方式包括靜态模組化和動态模組化。靜态模組化要求畫出用例圖、主要的類圖和對象圖，動态模組化要求畫出主要的狀态圖、時序圖、協作圖和活動圖等。另外在用例圖中，需标明每個用例的業務描述、業務資料、業務流程、入口條件、輸出結果、異常處理等要素。

建立資料字典（可選）

資料字典是使用者需求中的各類實體（業務對象、資料對象、業務流程對象等）的專業化名稱解釋，它能夠保證使用者和開發方對需求溝通、了解的一緻性，同時也是後續進行資料庫對象設計的最重要依據之一。

2.4.1.3 産品需求定義

首先，需求開發人員進行産品需求定義，把使用者需求向軟體需求轉化前，要确認《使用者需求說明書》已經通過了使用者确認。

由需求開發人員根據《使用者需求說明書》，對使用者需求進行更加詳細的專業化定義，形成使用者需求到軟體需求的映射。完成《産品需求規格說明書》的編寫。

當需求開發人員或使用者不能确定需求時，可以考慮實作一個系統開發原型（DEMO），這樣使得許多概念和可能發生的事更為直覺明了。使用者通過評價原型将使項目參與者能更好地互相了解所要解決的問題。注意要找出需求文檔與原型之間所有的沖突之處。

系統如果建立原型，則需向使用者示範原型，或請使用者試用原型系統，記錄使用中的問題并修訂原型直至客戶滿意。原型的格式和内容由項目經理、美工以及客戶協商自定。

※由于《使用者需求說明書》與《産品需求規格說明書》在内容上存在很多的共同之處，有時為了項目的具體需要，兩個文檔可以考慮合并成一個文檔。但合并成一個文檔時需注意：

1.要明确使用者需求和産品需求之間的對應關系，建立起使用者需求和産品需求之間的映射表（通過映射表可以建立起使用者需求和産品需求之間的需求跟蹤矩陣）；

2.使用者需求和産品需求之間的對應關系，特别是軟體産品無法實作的使用者需求内容，要在合并文檔中明确記錄，并向使用者詳細說明情況，取得雙方的溝通一緻；

3.合并的文檔内容要用使用者易于了解的語言進行表述，切勿使用軟體專業性強而使用者無法了解或了解有歧義的語言，一般考慮使用用例圖/用例規約的方式。

4.合并的文檔不僅僅給使用者看，還要滿足軟體産品後續設計的需要，是以内容的描述盡可能正确、完整、易于了解、無歧義。

2.4.1.4 産品需求評審

産品需求評審的目的是為了確定使用者和開發方雙方對需求的了解一緻，消除歧義，并取得雙方之間的共同認可。評審時由項目經理邀請客戶、相關幹系人參加，要對《産品需求規格說明書》中的内容逐條逐項進行驗證，如果發現存在問題，則由需求開發人員繼續調研，加以修改，直至評審通過。

軟體需求評審要注意如下幾點：

1.明确說明使用者需求和軟體産品需求之間的映射關系，對軟體産品不能實作或暫時無法實作的使用者需求，需求開發人員要向使用者詳細說明原因，取得使用者的認可。

2.可以通過示範系統原型（Demo）方式，直覺形象的向使用者進行軟體産品需求的示範，取得使用者的認可。

3.軟體需求确認不同于使用者需求的确認，使用者需求的确認可以是非正式（如郵件确認），軟體産品需求确認必須是正式的，《産品需求規格說明書》必須得到使用者的書面确認。産品需求确認後，形成正式的軟體産品需求基線，作為後續需求變更控制的基礎。

2.4.2 需求管理過程

需求管理過程包括：需求的變更控制、需求的實作跟蹤兩個方面。軟體需求包括 3 個不同的層次――業務需求、使用者需求和功能需求。除此之外，每個系統還有各種非功能需求。需求的分類是軟體需求階段必不可少的工作，它可以指導開發人員了解不同的行業的業務、了解使用者的真實需求，清楚這些之後确立好功能項；當開發人員對整體需求有了明确的目标後，就可以按部就班快速有效地進行功能項開發，一般就不會背離系統開發需求的初衷。

1、業務需求

業務需求（Business requirement）表示組織或客戶高層次的目标。業務需求通常來自項目投資人、購買産品的客戶、實際使用者的管理者、市場營銷部門或産品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目标。使用前景和範圍（ vision and scope ）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（ project charter 或 market requirement ）文檔。

2、使用者需求

使用者需求（user requirement）描述的是使用者的目标，或使用者要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達使用者需求的有效途徑。也就是說使用者需求描述了使用者能使用系統來做些什麼。

3、功能需求

功能需求（functional requirement）規定開發人員必須在産品中實作的軟體功能，使用者利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（ behavioral requirement ），因為習慣上總是用“應該”對其進行描述：“系統應該發送電子郵件來通知使用者已接受其預定”。功能需求描述是開發人員需要實作什麼。

4、非功能性需求

4-1、系統需求（system requirement）用于描述包含多個子系統的産品（即系統）的頂級需求。系統可以隻包含軟體系統，也可以既包含軟體又包含硬體子系統。人也可以是系統的一部分，是以某些系統功能可能要由人來承擔。

4-2、業務規則包括企業方針、政府條例、工業标準、會計準則和計算方法等。業務規劃本身并非軟體需求，因為它們不屬于任何特定軟體系統的範圍。然而，業務規則常常會限制誰能夠執行某些特定用例，或者規定系統為符合相關規則必須實作某些特定功能。有時，功能中特定的品質屬性（通過功能實作）也源于業務規則。是以，對某些功能需求進行追溯時，會發現其來源正是一條特定的業務規則。

4-3、功能需求記錄在軟體需求規格說明（ SRS ）中。 SRS 完整地描述了軟體系統的預期特性。 SRS 我們一般把它當作文檔，其實， SRS 還可以是包含需求資訊的資料庫或電子表格；或者是存儲在商業需求管理工具中的資訊；而對于小型項目，甚至可能是一疊索引卡片。開發、測試、品質保證、項目管理和其他相關的項目功能都要用到 SRS 。除了功能需求外， SRS 中還包含非功能需求，包括性能名額和對品質屬性的描述。

4-4、品質屬性（quality attribute）對産品的功能描述作了補充，它從不同方面描述了産品的各種特性。這些特性包括可用性、可移植性、完整性、效率和健壯性，它們對使用者或開發人員都很重要。其他的非功能需求包括系統與外部世界的外部界面，以及對設計與實作的限制。

4-5、限制（constraint）限制了開發人員設計和建構系統時的選擇範圍，如局限于軟體工程學科。

注：厘清楚那些是業務需求、哪些是使用者需求、哪些是功能性需求和非功能性需求對軟體的開發有着重大的指導意義，絕不可以以偏概全，錯誤地去揣摩使用者的心思；對于開發者而言，所有軟體功能的開發我們都應該一一征求使用者的意見，對需求有了清晰的認識後再進行實質性的開發工作。

2.4.2.1 需求變更控制

1、需求變更申請

對于一、二級變更，變更申請人必須填寫《需求變更申請單》，送出項目經理。三級變更可以不填寫《需求變更申請單》，直接告知項目經理即可；

2、變更評估

項目經理對變更申請進行變更影響分析、評估，确定是否變更、變更影響範圍及變更時機。

3、變更決策

對于三級變更，項目經理直接審批是否變更及變更時機，并進行後續的變更實施處理；

對于一、二級變更，需要送出CCB（軟體配置控制委員會）、高層經理審批是否變更及變更時機。

如果允許變更，項目經理安排變更任務，必要時制定詳細的變更計劃。變更内容主要有：

更新受影響的《項目計劃》、《項目進度表》等管理文檔；

更新受影響的各類技術文檔（需求、設計、開發、測試文檔等）；

更新項目配置庫；

如果不允許變更，則直接跳轉到“6、變更溝通存檔”步驟。

4、變更實施

變更責任人根據變更任務實施變更。

項目經理或CCB進行變更後的審批及釋出，通知受影響的組或個人。對于影響較小的變更可以暫時不更新基線，對于影響較大的變更（需更新基線時），由相關責任人送出《基線建立申請單》，審批通過後建立新的基線。

5、變更驗證

項目經理對變更進行跟蹤驗證、直到變更結果和預期相符，相關内容進行了更新，工作産物符合版本管理要求為止。

QA監督變更過程活動，如有協商不一緻的問題，則記錄到《不一緻項問題跟蹤表》中，并送出給高層。

6、變更溝通存檔

将變更後的内容通知可能會受到影響的人員，并将變更記錄彙總歸檔，如提出的變更在變更決策時被否決，其初始記錄也應與儲存。

需求變更按照嚴重程度，分為一、二、三級變更：

² 一級變更

是指該變更會導緻工作量延遲超出整個工程過程階段計劃總工作量的10%（或超過10個工作日）的變更，對項目的進度、成本、品質等關鍵要素造成嚴重影響，需要重新定義需求工作，大量開發代碼需要重新編寫。

² 二級變更

是指該變更會導緻工作量延遲整個工程過程階段計劃總工作量的5～10%（或超過5個工作日，小于10個工作日）的變更，對項目的進度、成本、品質等關鍵要素未造成重大影響。

² 三級變更

是指該變更會導緻工作量延遲小于整個工程過程階段計劃總工作量的5%（或小于5個工作日）的變更，幾乎不會對項目的進度、成本、品質等關鍵要素造成較大影響。

三種級别的需求的變更均可以由項目經理、需求開發人員或者相關使用者提出，需求變更提出後，交予項目經理确認，由項目經理分析變更影響，初步确定變更級别。

确認為一、二級的需求變更，經項目經理送出CCB。如果CCB同意了該變更申請，則由項目經理組織項目組成員和需求開發人員進行需求變更工作，即重新進行需求開發、需求确認，更新《使用者需求說明書》和《産品需求規格說明書》，填寫《需求變更記錄表》，需求開發人員及時更新《需求跟蹤矩陣》。如果變更申請被拒絕，CCB則需要在變更申請中說明理由，項目則繼續按原計劃進行。

确認為三級的需求變更，需求的變更人無需填寫《需求變更申請書》，經項目經理确認後将變更項填入《需求變更記錄表》中即可，然後直接進行後續的變更操作，無需再交由CCB進行評審。但當三級變更數量達到20條以上範圍時，或累積産生的影響達到一、二級變更的影響時，應當引起項目經理高度注意，查找問題所在，并送出使用者确認。

所有的一、二級變更項，須得到使用者的确認簽字，三級的需求變更定期告知使用者即可，無須使用者的正式确認簽字；但當三級變更累積産生的影響達到一、二級變更的影響時，則需要提請使用者予以确認簽字。

所有的一、二級變更項經過處理後，需要變更需求相關文檔的版本号，從VX.Y版本變更到VX.(Y+1)版本，超出整個工程過程階段計劃總工作量的20%或成本超出整個工程過程階段計劃總成本的20%以上的一級變更，從VX.Y版本直接變更到V(X+1).0版本。

2.4.2.2 需求跟蹤

當《使用者需求說明書》編寫完成，經過需求評審、使用者簽字後，需求開發人員建立需求跟蹤矩陣，需要填寫具體使用者需求編号，需求類别，目前狀态等。

需求跟蹤矩陣建立完成後，需求開發人員需要在以下時機成熟時更新該矩陣：

l 每周例會時：

需求開發人員在每周例會上根據本周完成的需求或與此需求相關的工作産品完成情況更新《需求跟蹤矩陣》。

l 軟體需求評審通過時：

《産品需求規格說明書》及其附件内容（業務模型、資料字典、系統Demo等）評審通過并且使用者确認簽字後，需求開發人員更新《需求跟蹤矩陣》。

l 項目裡程碑時：

在項目進入裡程碑階段（需求結束、系統測試結束等）時，也要及時進行更新。需求開發人員更改所有相關需求文檔，以及相應的工作産品，使得每一個軟體的需求均能夠與後續工作成果保持一緻。

l 需求變更時：

當需求發生變更時，項目變更或者需求開發人員發現需求與項目實施過程存在不符合項時，也要及時更新《需求跟蹤矩陣》。

2.5 輸出

² 《使用者需求調研記錄》及《使用者需求調查單》

² 《使用者需求說明書》

² 《産品需求規格說明書》

² 系統開發原型Demo、業務模型、資料字典等

² 《需求評審報告》

² 《需求跟蹤矩陣》

² 《需求變更申請單》

² 《需求變更記錄》

2.6 出口準則

項目結項。

2.7 過程度量

№	度量點	執行人	度量時機\|頻率	存儲位置
M-1	需求變更數	需求開發人員	每周	《需求跟蹤矩陣》
M-2	需求變更工作量	需求開發人員	每周	《需求跟蹤矩陣》

2.8 裁剪說明

裁剪對象	類型（過程活動或工作産品）	裁減要素（增加、删除、修改）	裁減條件
産品	業務模型、資料字典	删除	使用者需求易于了解時
産品	系統開發原型（Demo）	删除	使用者需求易于了解時

3. 相關指南

《需求調研指南》

《用例指南》

附件：

需求調研指南

1. 引言

在需求調研中最常見的技術就是：

使用者訪談

問卷表

小組會議

上述的各種技術在特定場合都能很好發揮作用，應該好好的考慮在何時使用哪項技術。在大多數項目中，調研需求不可能隻采用某個技術。實際情況中，項目組會根據不同的使用者情況采用不同的方法。

2. 使用者訪談

使用者訪談一般在下列情況使用

² 需要與少數幾個人，進行大量的知識交流

² 需求開發團隊能夠與他們集中進行面對面會談

² 無法一次性集中收集所有涉衆的使用者需求

使用者訪談一般會經曆五個階段：

² 訪談前準備

² 計劃和安排訪談日程

² 訪談開始和結束

² 引導訪談

² 後繼的訪談整理工作

2.1 準備訪談

在進行訪談前，需求分析者應該很好的了解組織結構，行業定位和項目範圍和項目目标，訪談會涉及下面内容：

² 組織機構情況（組織機構、組織業務、發展目标、未來規劃）

² 部門目标的陳述

² 已有業務業務系統、程式手冊

² 已有系統的各類業務文檔

² 要建設系統的需求目标、需求範圍、

需求分析者應該了解一般的行業術語（術語表）并且還要熟悉行業上的業務問題。

2.2 計劃訪談日程

準備清單，列出主要話題或問題。這些問題可以找出未意識到的重點，還能有邏輯的引導訪談進行。安排訪談應遵循自上而下的進行。首先訪談組織、部門或地區的上司，然後才是他們下屬的雇員。在邀請對方進行會談時，要解釋這次會談的目的，一般會涉及哪些領域、哪些角色人員、以及大緻需要的時間。

2.3 訪談開始和結束

開始訪談時，先介紹你自己，陳述這次訪談的目的，談談被訪談者關心的事，并說明有一些簡短的會談記要，在整理後會交給對方審閱。一般被訪談者認為需求開發者試圖找到他們工作中的缺陷。使他們擺脫這種觀點。可以讨論他們所熟悉的日常工作的過程。好的訪談者會讓被訪談者作為主講人。是以，需求開發人員應該尋找一些問題讓被訪談者對他們開誠布公：

例如：

“怎樣的變化将使你的工作更簡單或更有效？”這個問題暗示被訪談者提出改進意見；

當清單中的所有領域都讨論過後，提出下面問題：

“還有什麼問題我們沒有讨論嗎？”或是 “我們還需要讨論些别的内容嗎？” 這些問題鼓勵被訪談者提出所有應該被讨論的問題。

在訪談的内容組織上，要至上而下、分層次進行内容的交流讨論。比如：先訪談使用者需求的背景、目标、範圍，然後從目标、範圍中層層展開具體的需求項，再逐項讨論需求項的細節業務流程、操作人員、前後置條件等内容。

結束會談時，一般會簡短的總結讨論過的問題，重點指出會談的要點，并說出你的了解。這使被訪談者知道你認真傾聽了談話，而且有機會澄清誤解。在總結會談以及整個會談中，需求分析者應采取客觀的态度，避免帶個人色彩的評論，觀察或結論。最後，你必須感謝被訪談者參加這次訪談。如有必要，詢問被訪談者能否在近期再參加一次簡短的後繼訪談活動。

2.4 引導訪談

在訪談中避免提封閉性的問題，因為被訪談者通常會簡短的回答完這樣的問題，然後等待下一個問題。這樣就像是偵探在審問犯人。封閉性的問題：（誰，哪裡，什麼時間，哪一個）：

² 限制了被訪談者提供資訊的類型，層次和數量。

² 通常提供了二選一的回答，暗示了較極端或不确定性的回答。

² 一般用于澄清問題，探索性提問或僅是希望得到回報資訊

² 花費較少的時間得到細節資訊

² 比較容易作筆記

² 有時隻能得到很少的資訊

² 可能導緻被訪談者無法自由提供資訊

² 對相關術語和詞彙的要求高

在開始一個議題時，一般會用開放性的問題，便于被訪談者展開思路。然後，漸漸轉為結論性問題，這樣能幫助證明你的了解。太多的關閉性問題會導緻收集的資訊不完整，太多的開放性問題可能導緻需求分析者的了解失誤。

為了會談後的整理需要，一般會使用簡明的符号來做筆記，否則做筆記會使你分心。最好将筆記本放在被訪談者視線外。需求開發者的筆記有助于會談後回顧要點和會談時形成的想法。最好是會談時指定一個記錄員。使用錄音機也是個好主意。雖然會談後整理資訊會耗費些時間，因為需求開發人員需要聽完整個記錄。不特别推薦使用錄音機，這會使被訪談者有被脅迫的感覺；而且傾聽錄音，記錄其中要點也是耗時較多的工作。無論如何，音頻視訊記錄有優點也有缺點。認真傾聽有助維持需求分析者和被訪談人之間的資訊交流，維持互相之間适當的回報。

認真傾聽有五個關鍵方法：

1. 詢問開放性的問題

開放性問題無法簡單的用事或否來回答，應此被訪談者就會提供更多的資訊。開放性問題一般會使用這些詞語做開頭，如什麼，怎麼樣或是告訴我。而不會使用諸如能夠，要作或是何時這樣的詞語。列舉一個需要詳盡解釋的問題，“告訴我，當顧客打進電話時，什麼情況發生？”

開放性問題：（什麼，為什麼，多麼）

l 涉及比較寬廣，加在被訪談者上的限制很少

l 用來确定了解範圍。被訪談者會使用明确的回答或是模拟示範來傳達需求開發人員不了解的内容

l 可以得到被訪談者的行業詞彙，概念和可參考的知識架構

l 有助于增強了解，得到一些潛在的理論

2. 使用适當的表達

避免使用有感情傾向，讓人分心或是難以了解的語言。類似于問題存在于，讨厭的處理過程或是無法控制這樣的有感情傾向的語言容易暗示某種結論。避免使用讓人分心語言。這些語言包括過多的縮寫詞或首字母縮寫，顯示自己才識的語言，有争議性語言，俗語，俚語以及行話。

3. 暗示相信被訪談者

人類會使用說話的語氣，眼神接觸，面部表情，身體姿勢和身體的移動來傳達某種資訊。正确使用，會使被訪談者提供更多的資訊。例如，在訪談中避免眼睛接觸會被了解為缺乏興趣，或是對其他人更感興趣。适當的眼神接觸會傳達出感興趣，關注，開放的接受并且尊重别人的見解。太頻繁的眼神接觸會被誤解為盯着對方。在我們的文化中，如果兩個陌生人間眼神接觸時間過長則意味着挑戰。在其他的一些文化中，會被認為是侵犯隐私。點頭表示了解，暗示接受；類似的，表示關注的姿勢：端正坐着略向前傾。

缺少經驗的需求開發人員通常會犯下面的錯誤：

i. 靠在椅子後背上，雙手合攏抱在胸前。這種姿勢暗示了不太接受正在講述的内容，也顯示出需求開發人員處于不安的狀态。

ii. 看着屋内的物品或是直盯着窗戶，而不是看着被訪談人。這表明需求開發人員更甯願在其他的地方做其他事，被放談者通常會縮短訪談的過程。

iii. 忙于做筆記或是經常翻閱筆記。較之傾聽而言，需求開發人員對自己的記錄更感興趣會使被訪談者好奇，到底他記錄了什麼。

iv. 坐得太遠或太近。坐得太遠像是暗示被訪談者會威脅到需求開發人員，坐得太近又顯得不恰當地親密，被訪談者會感覺不自在。

4. 重述被訪談者的回答

重述回答是指需求開發人員用自己的語言複述被訪談者的陳述。這顯示了兩者間進行了有效地溝通，需求開發人員了解了被訪談者的陳述，重述回答一般用在以下場合：

² 訪談者描述一個問題時。這時，需求開發人員的複述表明聽見并了解了訪談者的問題。

² 當需求開發人員想檢查他的了解是否正确時。這個技巧大多是遇到複雜的陳述時，或是多人參與時，每個人對同一問題有各自不同的見解。

² 需求開發人員希望鼓勵訪談者時。重述回答會暗示被訪談者擴充或是詳細說明他曾說過的内容。

重述回答也能克制住因某種原因，不願配合的人。

需求開發人員必須保持中立。例如，如果被訪談者批評現有管理模式，需求開發人員不應該贊同他的批評或是為現有管理模式辯護。需求開發人員隻需要表達出被訪談者的感覺是可了解的。

重述問題常見的錯誤：

² 重複被訪談者的話，例如，完全重複被訪談者的話而不是使用其他的表達方式。一段話講完後被完全重複一遍，會使被訪談者感覺不安。

² 過多重述回答将使被訪談者分心。

² 改變或是歪曲被訪談者真實的意願。重述應該盡可能的接近被訪談者的意思。

² 在複述結束時提高聲音。這個習慣會使複述變成一個問題，會暗示被訪談者回答是或否，而不是讓被訪談者擴充他的解釋。

這兒有個例子顯示了有效的及無效的複述；

被訪談者的回答：顧客沒有支付帳單，我們也會繼續銷售産品給他們。

無效的複述：在你們處理定單前為什麼不檢查顧客的信用狀态？（扭曲了被訪談者的意思）

有效的複述：系統也會處理有信用危險的顧客的定單。（鼓勵被訪談者擴充發揮）

5. 有效的使用沉默

在提問結束時允許被訪談者收集整理他們的想法。當被訪談者回答不完整時，鼓勵他們繼續。在會談已文字記錄後，使用封閉性問題可以澄清了解。

3. 問卷表

問卷表是需求調研時廣泛使用的另一種工具，它采用了統計分析的方法，顯得更科學。問卷表一般在下列情況中使用：

² 需訪談的個體太多

² 需要回答容易确定的細節問題

² 當你希望有個詳細的結果時

準備問卷表時，注意以下情況：

² 使問卷表盡可能的簡短。用多個短小的問卷表替代一個長的問卷表。如果在回答了前15-20個問題後，長的問卷表會使使用者感覺厭煩，他們就不會對其餘的問題做出正确的判斷。通常，一個問卷表包含的問題不超過10-15。

² 估計回答問題需要的時間，并在問卷表開頭标明這個時間，已便讓回答者做出相應的安排。

² 確定問題是前後一緻的，沒有讓人含混的了解。

² 為了保證不會了解含混，讓與回答者關系密切的人員來進行問卷調查，并保證他們對問題的了解是正确的。

² 在制定問題前，先确定你需要得到怎樣的答案。

² 分别列出所有可能的答案。

² 一旦所有的需求和問題都準備好了，把需求點當作X軸，問題當作Y軸。確定所有的需求能被問題覆寫。最後，剔除掉與需求無關的問題。

4. 小組會議

小組會議一般在下列情況中使用：

² 資訊平均的分布一小部分個人中

² 無法個别的會見所有的涉衆

² 一系列的訪談已經結束，團隊需要在同一平台下得到所有的回答者

在小組會議中，每個人都可講出自己的想法。團隊的答案一般比個人的答案好。小組會議可以減少一部分需求沖突，繞開紛繁的情況得到需求清單

如果小組會議管理不好，容易出現下列情況

1. 少數與會者控制了讨論

2. 一部分與會者缺乏參與讨論的積極性

為避免這種情況，需求開發人員要推動讨論的進行。要鼓勵缺乏積極性的與會者參與讨論，先直接向他們提一些封閉性問題，然後逐漸轉為開放性問題。

首要的技巧像提一些開放性問題，複述回答來确認了解，建立清楚的議程，指定記錄員記錄會議等都可使用。

其他一些注意事項：

² 提前确定會議地點，在發出與會邀請時提供路線圖。這在一些大公司尤為重要，并不是每個人都熟悉整個辦公大樓。

² 提前制定座位安排，平均分布需求開發人員，這樣確定所有的回答都能被聽到。

² 如果可能，在會議開始時宣布一些希望大家遵守的基本準則，如尊重别人的觀點，關閉手機等。

² 牢牢控制讨論的話題。

² 如果可能，使用錄音機，這樣能更專注于讨論。

² 好好的準備小組會議，所做準備要“N”倍于個人訪談的準備，這裡的“N”是指參與讨論的涉衆人數。

² 如果這個會議是最終确定需求，而不是探詢需求，可采用原型示範的方法。

在小組讨論結束時，感謝大家抽出時間參與讨論，告訴大家整理确認需求的計劃并傳閱會議紀要。

《需求開發和管理過程》附《需求調研指南》