第二階段 項目的需求分析
需求分析階段的主要工作是由需求顧問負責走訪用戶，從用戶訪談中歸納、抽取總結出用戶的需求，一般要經過定義用戶場景，定義用戶用例，編寫需求說明書三個主要步驟，如項目需求分析階段圖階段圖所示。軟件測試工程師在需求分析階段的工作主要是協助需求顧問或者開發工程師完成需求分析的輔助工作。
項目需求分析階段工作圖
需求分析階段的工作是項目經理帶領下，主要由需求顧問完成的。開發和測試團隊中的資
深工程師也會參與一部分需求說明書的編寫工作。項目組中不同角色的人員與交付物之間的關系如如項目需求分析階段各團隊與交付物關系圖所示。
項目需求分析階段項目團隊與交付物關系圖第四章 用戶場景
上一章的項目啟動會完成了項目的啟動和計劃階段，從本章起項目開始實施，進入正式開
發階段。軟件項目的開發首先是需求分析，而需求分析的第一項工作就是定義用戶場景。這一章的工作是定義用戶場景，由需求顧問負責完成。資深的開發工程師和測試工程師會參與其中一部分分析和設計工作。技術文檔工程師在這個階段的主要工作是協助需求顧問編寫場景定義，為后續的需求分析工作打下基礎。本章對用戶訪談、訪談整理、定義崗位職責、定義系統用戶及定義系統用戶場景等步驟做了詳細講解，并提供了相應的寫作訓練。
4.1 概述
定義用戶場景的工作過程比較長，中間的交付物比較多，工作量也比較大，技術文檔工程師需要協助需求顧問，參與其中的每一個步驟，并且在需求顧問的指導下編寫每一步交付物的內容，實施步驟和交付物如圖4-1所示。
圖4-1 定義用戶場景的交付物及實施流程圖
1.背景
定義用戶場景是確定系統需求的首要的工作。用戶場景的主交付物——《用戶場景描述》是嘗試模擬用戶的各種使用系統的情況，這是建立完善的測試用例的依據之一。定義
用戶場景需要從用戶訪談開始，再經過訪談整理、定義崗位職責、定義系統用戶、歸類用戶需求/導出系統模型等步驟中間工作，最后定義系統用戶場景。技術文檔工程師通過參與用戶場景的編寫來了解系統，熟悉系統，為后續其他技術文檔的編寫打下良好的基礎。
以本書使用的《公交運營調度系統》為例，由項目經理組織用戶訪談，需求顧問整理訪談內容后定義出崗位職責、系統用戶、系統模型和用戶場景，最終提交《用戶場景描述》。
2.交付物
《用戶場景描述》
3.團隊分工
技術文檔工程師在此階段主要與需求顧問緊密合作，根據訪談記錄整理出《訪談故事卡》；獲取系統用戶及其崗位職責信息，來完《崗位職責表》和《系統用戶表》；并獲取用戶場景信息，來最后完成《用戶場景描述》。并且還需要通過需求顧問的審核后，才能交付于整個開發團隊。
表4-1 項目計劃團隊分工
角色 | 任務 |
用戶 訪談 | 訪談 整理 | 定義 崗位職責 | 定義 系統用戶 | 定義 系統模型 | 定義 用戶場景 |
項 目 組 | 項目經理 | ☆ | | | | ☆ | |
需求顧問 | ☆ | ☆ | ☆ | ☆ | ☆ | ☆ |
技術專家 | | | | | ☆ | |
技術文檔工程師 | ☆ | ☆ | ☆ | ☆ | ☆ | ☆ |
開發工程師 | | | | | | |
測試工程師 | | | | | | |
網絡工程師 | | | | | | |
客 戶 | 項目責任人 | | ☆ | | | | |
項目發起人 | | ☆ | | | | |
機構資助人 | | ☆ | | | | |
客戶各級負責人 | | ☆ | | | | |
典型用戶 | | ☆ | | | | |
| | | | | | | |
表4-2 項目計劃團隊任務目標
角色 | 任務目標 |
項目組 | 項目經理 | 組織項目組走訪用戶，組織需求顧問和技術專家進行定義系統模型 |
需求顧問 | 主持用戶訪談并記錄談話內容，按照6W方式整理出訪談記錄，從訪談記錄中分析崗位職責，從崗位職責中定義系統用戶 |
需求顧問 技術專家 | 根據系統用戶定義系統用戶模型，最終確定用戶場景。 |
技術文檔工程師 | (1)從需求顧問獲取用戶訪談信息， (2)利用客戶訪談信息編寫故事卡， (3)將故事卡提交需求顧問審核 (4)依據需求顧問的意見進行修改 (5)經過需求顧問審核通過后向需求顧問提交故事卡 |
(1)從需求顧問獲取用戶方的崗位職責信息， (2)制作職責表， (3)將職責表提交需求顧問審核 (4)依據需求顧問的意見進行修改 (5)經過需求顧問審核通過后向需求顧問提交職責表 |
(1)從需求顧問獲取系統用戶信息， (2)制作系統用戶表， (3)將系統用戶表提交需求顧問審核 (4)依據需求顧問的意見進行修改 (5)經過需求顧問審核通過后向需求顧問提交系統用戶表 |
(1)按照需求顧問要求編寫用戶場景 (2)將用戶場景提交需求顧問審核 (3)依據需求顧問的意見進行修改 (4)經過需求顧問審核通過后向需求顧問提交用戶場景 |
開發人員 測試人員 | 協助項目經理、需求顧問、技術專家的工作 |
客戶 | 典型用戶 | 介紹業務并說明對系統的要求 |
項目責任人 項目發起人 機構資助人 客戶各級負責人 典型用戶 | 確認訪談記錄 |
| | |
4.知識目標
(1)了解需求分析的重要性。
(2)理解需求分析階段工作流程及主要交付物。
(3)了解用戶場景和用例的區別。
(4)了解崗位職責與系統用戶的關系。
(5)掌握用戶故事卡與系統需求的導出關系。
5.能力目標
(1)能夠獨立利用調查問卷和訪談調查表進行客戶用戶訪談，了解用戶對系統的要求。
(2)能夠獨立利用用戶故事卡整理訪談記錄，熟悉用戶業務。
(3)能夠獨立進行崗位、職責以及系統用戶定義。
(4)能夠在需求顧問指導下，進行系統需求模型的推導。
(5)能夠在需求顧問指導下，定義軟件的系統需求，為定義系統測試需求做好準備。
(6)能夠獨立撰寫用戶場景，在熟悉用戶場景的基礎上設計測試用例。
1.2實施步驟
1.步驟說明
定義用戶場景主要由需求顧問負責，需要下面幾步完成：
第一步 用戶訪談
走訪用戶，調查用戶需求，將訪談結果形成《用戶訪談原始記錄》。
第二步 訪談整理
對《用戶訪談原始記錄》進行整理，按6W的方式進行組織，整理成“故事卡”形式的文檔。
第三步 定義崗位職責
將“故事卡”進行總結、歸類，列出用戶單位中的每一個崗位，以及這個崗位從事的業務。
第四步 定義系統用戶
合并相同的職責，將職責相同的崗位合并為一個，形成系統用戶，崗位的職責形成系統用戶的業務需求。
第五步 歸類用戶需求，導出系統模型
根據系統用戶的業務需求推導出系統要實現的功能，以及為了實現這些功能系統應該具備的資源，包括網絡、數據庫和通信設備等。
第六步 定義系統用戶場景
根據崗位職責、系統用戶的定義，將場景明確、詳細地描述下來。
文檔交付物：第二步：《訪談故事卡》；第三步：《崗位職責表》第四步：《系統用戶表》；第五步：《用戶場景描述》
文檔質量要求：
?《訪談故事卡》所有訪談的結果需要按6W的方式進行組織，需要將整理后的結果與訪談對象書面確認。
?《崗位職責表》中的不能客戶方干系人的崗位，也不能有任何遺漏；
?《系統用戶表》定義出的系統用戶不能超出客戶方干系人的范圍，也不能有遺漏。
?《用戶場景描述》要分總場景和分場景來描述，分場景按照系統用戶的職能來劃分，每個分場景不能有重合的內容。
文檔作用/質量要求：
?《訪談故事卡》是需求分析階段所有分析的基礎，所有的工作和文檔都由此而來。
?《職責表》用于定義系統用戶，職責相近或相同的用戶被稱為系統用戶。
?《系統用戶表》的系統用戶將代替現實中的用戶，作為系統的角色參與所有的需求分析中來，因此定義出的系統用戶要全面，不能有遺漏，否則系統的功能將有缺陷。
?《用戶場景描述》是定義用戶用例的基礎，所有用例都會從場景中抽取出來。為了讓抽取工作更加準確，因此需要有清晰、明確的上下文環境，說明場景的發生背景及時間；需要從用戶的角度出發，描述用戶做什么，與系統的交互行為，同時需要描述用戶對出現問題的反應
文檔邏輯結構：
?《訪談故事卡》
o被訪人員的信息，包括姓名、職位、部門、談話時間等。
o用戶談話記錄，用戶談話的原始內容
o整理出來的故事：按照事件、緣由、流程、人物、時間、地點來描述
o用戶確認意見：用戶對談話整理成故事卡確認
?《崗位職責表》
o崗位名稱：用戶崗位的名稱
o職責名稱：該崗位這項職責的命名
o職責描述：職責內容
?《系統用戶表》
o用戶崗位：用戶在系統中被定義的崗位
o用戶職責：在某一崗位下用戶的職責
o用戶業務需求：某個用戶職責下的業務描述
?《用戶場景描述》
o用戶場景匯總：所有用戶場景的一個匯總表
o單個用戶場景描述：描述單獨一個用戶場景，主要包括場景名稱、場景代碼、場景描述三部分。
2． 完成環節
編寫《用戶訪談故事卡》。
訪談故事卡包含了被訪人員的信息、用戶訪談記錄、整理故事、公用信息、整理人及用戶和負責人的確認。
訪談故事卡模板如表4-7所示：
表4-7 用戶訪談故事卡表
用戶訪談故事卡 |
被訪人員信息（從訪談記錄中提取訪談對象） 姓名： 職位： 部門： 級別： |
用戶訪談記錄 | 整理故事 |
（跟該用戶有關的所有訪談記錄） | what（時間是什么） why（事件發生緣由） how（事件發生流程） |
以上所有公用： Who（用戶名） When（用戶故事發生時間） Where（用戶故事發生地點） |
整理人：（作者名稱） 訪談用戶確認：（用戶確認簽名） 負責人確認：（開發經理確認簽名） |
| |
編寫《崗位職責表》。
