前言
在《軟件工程導論》這門課上，我們學習了需求的獲取與分析技術。所以在本次團隊項目中，我們也是充分利用了該技術，最終完成了本項目的需求分析。以下是我們團隊的需求分析的過程以及一些心得體會：
團隊介紹
項目名稱：合同管理系統
指導老師：戴牡紅、邊耐政
小組名稱：麓南匪幫
小組成員：謝英祺（PM）、陳文康、何沁澤、盧永昌、蘇國超、木熱阿地力·買買提江
項目背景
項目選擇的背景依托於某公司內部“營銷一體化平台—合同管理系統建設項目”，該項目旨在將該公司整個市場經營活動全方位地信息化管理，打造專業的市場營銷體系平台，規范營銷過程，提高企業營銷管理水平，提升企業經濟效益。
該公司在整個市場經營活動過程中，會涉及到許多的采購和銷售合同，對這些合同進行合理、有效、規范的管理是一個公司經營管理工作的重要環節。該公司對於合同的管理使用傳統的人工擬制合同、人工歸檔紙質合同的方案，在該公司經營過程中往往會產生合同擬制、審計、歸檔周期長，合同管理難度大，查閱效率低等問題。
在此背景下，建立一個計算機管理的合同管理系統是該公司對於合同管理的迫切需求。按照公司對合同管理系統的應用需求和系統設計，提出合同管理系統的建設方案，實現合同主數據結構化管理，合同擬制、審核過程規范化管理，合同附件數字化管理，合同數據權限精細化管理，提高公司信息化管理能力。
需求分析過程
在本次的項目過程中，需求分析分為四個階段：
- 需求獲取
- 建立需求模型
- 需求驗證
- 迭代修改
需求獲取
需求的獲取往往是需求工程中最關鍵、也是最困難的部分。在項目開始前，必須要盡可能准確地獲取和理解用戶需求，才能為后續的數據庫設計和編碼過程做鋪墊。
針對我們的合同管理項目，我們采取了一系列的需求獲取方式：
1. 與戴老師進行訪談式需求交流
在確定了團隊所選項目，並在網上提前對合同管理流程有了初步的了解之后，接下來我們便向戴老師了解本次項目的具體需求。在此過程中，主要是戴老師來進行敘述。
訪談，作為需求獲取的手段之一，十分適合老師與學生之間的面對面交流，是一種十分有效並且符合當前應用場景的需求獲取手段。
我們團隊與戴老師總共進行了三次面對面的訪談交流，每次交流時，一人負責錄制交流的音頻、一人負責做好會議記錄、另一人向老師詢問一些細節性的問題。當與老師交流結束之后，小組再根據交流音頻和會議記錄對需求進行細化並形成具體的需求文檔。
這種交流方案使得我們能夠准確地記錄和理解老師所提出的需求，不會發生 “開會時聽不懂，開會后記不得” 的情況。
2. 收集並閱讀與合同管理相關的文獻資料
與戴老師取得聯系之后，戴老師為我們推薦了2篇寫得比較好的關於合同管理系統的學術論文，這極大地節省了我們項目組盲目地尋找文檔材料的時間。這兩篇論文為我們初步確定了合同管理的業務流程，並在后續確定系統的功能、項目的原型界面以及數據庫的設計方面發揮了至關重要的作用。
根據初步的業務流程，我們也在網上搜索了一些關於合同擬定、合同審批、合同管理方面的一系列文獻資料，並且請教了法學院的同學和老師。
最終才把我們所要實現的合同管理系統的整個業務流程搞清楚、搞明白，並且完整地制定了系統對合同管理的流程圖：
3. 進行誘導型訪談
客戶的真實需求往往具有隱蔽性，客戶可能並不知道自己想要什么、或者客戶的表達不夠准確與清晰，這時就需要誘導客戶來表達自己的內心想法，從而獲取真正的需求。
在我們進行需求獲取時，老師對於某些需求的說明十分模糊，例如：對於合同審核這一功能點的討論中，老師僅僅要求的是與主流企業相同，這一點讓我們十分費解。於是我們通過查找資料，最終擬定了兩種合同審核方案（方案A、B）。所以我們的問題從：“合同審核功能應該怎么做？” 轉變為 “請問方案A和方案B哪個符合您的預期？”。這時，即使兩種方案都不符合老師的預期，老師也會從中選擇一種相對來說比較好的方案，然后指出其中的問題。對於我們而言，也有了明確的目標。
通過這種誘導方式，我們最終解決了許多具有模糊性、不確定性的客戶需求。
建立需求模型
需求模型能夠幫助整個團隊在任意階段都能清晰地了解到整個系統的功能分類、用戶角色的權限分類以及系統的總工作流程，是需求分析過程中不可缺少的一環。
需求模型有很多種，我們項目使用的是user-case用例圖：
制作系統用例圖
需求獲取完成之后，項目組對需求進行分析並且划分出了系統的功能模塊，大致分為：
- 用戶管理模塊
- 權限控制模塊
- 合同管理模塊
- 合同審批模塊
- 工作台視圖模塊
不同的角色具有不同的模塊訪問管理權限。根據這種模塊划分，我們完成了系統用例圖的制作：
系統用例圖不僅用於結構化需求建模，還有利於后續業務代碼的編寫、系統業務舉例以及幫助程序員了解系統工作流程。
需求驗證
制作系統原型界面
通過訪談確定好“客戶”需求之后，本組就開始了界面原型的制作：
設計完成之后，我們向戴老師演示了一下我們的合同原型，戴老師對我們的合同原型比較滿意，但也指出了一些不足，如合同的資金進度不可以直接更改。我們后續也及時更正了這些問題。
原型設計進一步確定和驗證了我們組對項目需求的理解，並且使得最終產品提前現實化，消除了我們和客戶在需求理解上的差異。
迭代修改
當完成了需求獲取、需求模型以及需求驗證之后，在小班討論課上，我們向邊老師展示了項目的原型界面以及系統功能點。邊老師從事過比較多的項目開發，為我們提供了許多意見，如：合同的審批涉及到許多的部門人員，是否需要考慮使用流程模板來實現；並指出了一些不足，如：沒有考慮到合同在審核過程中出現變更和中止的情況。當我們查詢了一些資料后發現，確實存在合同擬定之后發生變更和中止的情況。
在收集完老師們的建議之后，最終對需求進行迭代修改並與老師們進一步確認。
需求分析中出現的問題
1. 對合同管理流程不熟悉，老師講述需求時大家一頭霧水
問題描述：由於本項目組的同學在平時都沒有接觸過有關合同的事務，所以在老師第一次為我們講解項目需求的時候，大家都是聽得一頭霧水。歸根結底還是對業務流程不熟悉。
問題解決：在下一次訪談交流之前，PM督促大家仔細閱讀了老師提供的合同論文，並且在每周的小組會議上為小組成員詳細講解了合同流程。最終才能理解老師所提出的需求場景。
2. 客戶並不（確切地）知道他們想要什么
問題描述：戴老師作為我們的客戶，也是第一次接收合同管理類的項目，雖然戴老師對合同流程具有一定的了解，但並沒有真實的合同項目經驗。所以對於系統的某些功能點，老師也不清楚細節是怎樣的，提出了一些模糊性的描述。
問題解決：采取誘導型的訪談方式，讓老師從對未知需求的描述轉變為對已知方案的選擇，再對已知的方案進行修改迭代，最終確定下真實可靠的客戶需求。
3. 合同流程不滿足企業級的真實流程
問題描述：在小班討論課中，邊老師指出：我們初步制定的合同項目流程的主觀性太強，考慮的東西太少，並沒有意識到企業級的合同管理流程的復雜性，與真實的流程存在偏差。
問題解決：在課后我們同邊老師進行了交流，明確了項目的缺口：不同合同的審核流程是不同的，擬定審核流程也應該加入項目需求當中；並且小組成員也親自上手使用了企業級的合同助手這款軟件，從中也體會到了流程的復雜，最終將我們的項目需求也加以完善。
4. 只關注了主干流程，而忽略了可能存在的分支流程
問題描述：該問題是在擬定需求文檔時發現的。雖然我們已經熟悉了合同流程，但是卻只是把握住了整體，對於流程中的一些細枝末節的處理並不到位。例如：合同擬定后如果需要修改？合同審核的流程是否需要因合同而異？……
問題解決：當我們意識到這些細枝末節的問題時，在下次的小組會議上，小組成員們互相交流了自己的意見，並且最終與老師進行協商，明確了分支流程的處理。
總結心得
1. 良好的組內溝通十分重要
在本次需求分析中，給我們印象最深的便是需要頻繁的溝通了。在之前的個人項目和結對項目中，這種感覺並不明顯，但是在團隊項目中，愈發感覺到溝通的重要性。口頭溝通是最有效的溝通辦法，很多項目組成員喜歡遇到問題就悶頭干活，不好意思問，遇到問題有可能是任務本身有問題，也有可能是你的認識不到位，某些知識不具備等導致的。大家在一起交流溝通才能真正發現問題的本質。
2. 要頻繁地與客戶（老師）交流
我們所構建的項目需求，一切都是來源於客戶的。所以在確定項目需求時，一定不能根據自己的思維去空想客戶的需求，一定要多和客戶進行交流，了解客戶的想法。甚至有時候客戶都不清楚自己想要的是什么，這時我們應該引導客戶深入觀察和挖掘需求。
3. 掌握相關的行業知識
就拿我們的合同項目來說吧，項目組對於合同流程的把握必須比任何人都要清楚，這樣才能做出沒有問題、沒有瑕疵的系統。
這一點在項目剛開始時，我們做得並不夠好，認為最后老師會為我們講述合同的管理流程。這樣的后果就是進行需求交流的時候，老師的需求我們都聽進去了，但卻聽不太懂。這樣的溝通方式，既不能有效的發現問題，也容易延誤項目時間。后來我們才發現，只有自己真正懂了、真正了解了，才能清晰項目結構，才能明白客戶的真實訴求。
4. 會議前做好充足的准備
在我看來，會議前的准備時間應該遠遠大於會議時間。無論是我們自己還是客戶，在交流了很長時間后，會失去熱情和耐心，從而導致需求獲取不真實、需求捕獲不充分等一系列問題。
如果在會議前，就能想好：客戶可能會提出哪些需求？有哪些地方是需要特別注意的？哪些業務流程對於我們開發人員來說還不太熟悉？在會議時再快速地交流解決，這樣就能大大降低會議的時間，提高會議的效率。
5. 會議時嚴格做好會議記錄
每次開會，無論是小組會議還是客戶訪談，都應該做好會議記錄。一來能夠幫助參會人員更加集中注意，切身參與到會議內容中，了解本次會議的目的；二來可以記錄下本次會議所制定的目標，用於下次會議前的任務檢驗；三來可以整體把握住項目的執行的進度，是否稍快或稍慢，是否需要加緊進度。
6. 深究細節
在很多情況下，客戶所能提供給你的只是他們想到的功能需求，很多問題並不在他們考慮的范圍之內，所以可能會忽略掉細節性的東西。作為項目成員，我們應該比客戶多考慮一步，多深究一些細節。
需求分析並不僅僅是拿到用戶的需求，側重點應該是進行分析，是否遺漏了什么，並就細節同客戶進行咨詢溝通，最終確定最詳細的業務流程。
7. 質量把控，減少返工
項目時間緊，大家就會一頭扎到工作中，想盡快弄出個東西來。“磨刀不負砍柴工”等大道理大家都懂，但事到臨頭還是明知故犯，結果往往是工作質量差、返工一大堆。做一個事情只有兩種選擇，一種就是不做，一種就是認真做好，任何帶有缺陷的工作，會在將來帶來無窮無盡的“后患”。
剛進行到編碼階段的我們對此感觸頗深。編碼時，無論是前端還是后端，幾乎都會將需求分析時制作的用例圖和原型界面作為參考。如果我們的原型界面制作不夠詳細或是用例圖功能點缺失，就會直接導致編碼出現差錯，就避免不了修改原型和用例圖。
在這里我認為我們項目組都做得比較好，無論是需求獲取、需求建模還是需求驗證階段，大家的原型界面、用例圖都是按照最高標准繪制的，都是考慮到了所有可能的功能，為我們的編碼階段做了良好的鋪墊。