需求獲取

當軟件項目以招標方式確定開發單位時，“標書”往往可以作為初步的需求陳述。用户需求陳述可能由用户單方面寫出。也可能由系統分析員配合用户共同寫出。需求陳述的內容包括問題範圍、功能需求、應用環境及假設條件等。此外。對採用的軟件工程標準、模塊構造準則、將來可能做的擴充及可維護性要求等方面的內容，也都要做適當描述。總之，需求陳述應該闡明“做什麼”而不是“怎樣做”。它應該描述用户需求而不是提出解決問題的方法；應該指出哪些是系統必要的屬性，哪些是可選的屬性；應該避免對設計策略施加過多的約束；也不要描述系統的內部結構，否則會限制系統實現的靈活性。

需求獲取是開發者、用户之間為了定義新系統而進行的交流。需求獲取是需求分析的前提，需求獲取是獲得系統必要的特徵，或者是獲得用户能接受的、系統必須滿足的約束。由於用户是其各自領域的專家，對開發的系統應該如何做，已經有了總體考慮，但這些用户通常不具備軟件開發方面的技術和經驗。而與此相對，開發者在軟件開發方面具有豐富的經驗，但瞭解用户和用户的領域相關知識較少。如果雙方所理解的領域內容在系統分析、設計過程出現問題，通常在開發過程的後期才會被發現，將會使整個系統交付延遲，或上線的系統無法或難以使用，最終所開發的系統以失敗告終，導致出現嚴重的軟件危機。例如，遺漏的需求(丟失了系統必須支持的功能)或錯誤的需求(不正確的功能描述或不可用的用户界面)。需求獲取的目標，就是為了提高開發者與用户之間溝通的能力，進而構造應用系統的領域模型。

在面向對象的方法中，開發者選擇用户易於理解的表達方式，通常使用用例來獲取軟件的需求。用例通過描述“參與者”和“系統”之間的交互來描述系統的行為。用例方法最主要的優點在於它是用户導向的，用户可根據自己所對應的用例來不斷細化自己的需求。此外，使用用例還可方便地得到系統功能的測試用例。 ^[1] 

對於不同規模及不同類型的項目，需求獲取的過程不會完全一樣。下面給出需求獲取過程的參考步驟。

所謂應用領域，即目標系統的應用環境，如銀行、電信公司等。如果系統分析員對該領域有了充分了解，就可以建立一個業務模型，描述用户的業務過程，確定用户的初始需求。然後通過迭代，更深入地瞭解應用領域，之後再對業模型進行改進。

在項目開始之前，應當在所有利益相關方面建立一個共同的願景，即定義項目範圍和高層需求。項目範同描述系統的邊界以眨與外部事物(包括組織、人、硬件設備、其他軟件等)的關係。高層需求不涉及過多的細節，主要表示系統需求的概貌。

需求獲取的主要目標是理解用户需求，因而客户的參與是生產出優質軟件的關鍵因素。因此，首先確定目標系統的不同用户類型；然後挑選出每一類用户和其他利益相關方的代表，並與他們一起工作；最後確定誰是項目需求的決策者。

用户類可以是人，也可以是與系統打交道的其他應用程序或硬件部件。如果是其他應用程序或硬件部件，則需要以熟悉這此係統或硬件的人員作為用户代表。

確定了項目範圍和高層需求，並確定了用户類及用户代表後，就需要獲取更具體、完整和詳細的需求。

具體到當前待開發的應用系統，確定系統的業務工作流和主要的業務規則。採取需求調研的方法獲取所需的信息。例如，針對信息系統的需求調研方法如下。

(1)調研用户的組織結構、崗位設置、職責定義，從功能上區分有多少個子系統，劃分系統的大致範圍，明確系統的目標。

(2)調研每個子系統的工作流程、功能與處理規則，收集原始信息資料。用數據流來表示物流、資金流、信息流三者的關係。

(3)時凋研內容事先準備，針對不同管理層次的用户詢問不同的問題，列出問題清單。將操作層、管理層、決策層的需求既聯繫又區分開來，形成一個需求的層次。

必須對上面步驟取得的需求資料進行整理和總結，確定對軟件系統的綜合要求，即軟件的需求。並提出這些需求實現條件，以及需求應達到的標準。這些需求包括功能需求、性能需求、環境需求、可靠性需求、安全保密需求、用户界面需求、資源使用需求、軟件成本消耗與開發進度需求等。 ^[2] 

這是一種理解商業功能和商業規則的最有效方法。面談過程需要認真的計劃和準備。其基本要點如下。

(1)面談之前：確立面談目的；確定要包括的相關用户；確定參加會議的項目小組成員；建立要討論的問題和要點列表；複查有關文檔和資料；確立時間和地點；通知所有參加者有關會議的目的、時間和地點。

(2)進行面談時：衣着得體；準時到達、尋找異常和錯誤情況；深入調查細節；詳細記錄；指出和記錄下未回答條目和未解決問題。

(3)面談之後：複查筆記的準確性、完整性和可理解性；把所收集的信息轉化為適當的模型和文檔；確定需要進一步澄清的問題域；適當的時候向參加會議的每一個人發一封感謝信。

需求專題討論會也許是需求獲取的一種最有力的技術。項目主要風險承擔人在短暫而緊湊的時間段內集中在一起，一般為一或兩天，與會者可以在應用需求上達成共識、對操作過程儘快取得統一意見。參加會議的人員包括主持人、用户、技術人員、項目組人員。

專題討論會具有以下優點。

(1)協助建立一支高效的團隊，圍繞項目成功的目標；

(2)所有的風險承擔人都暢所欲言；

(3)促進風險承擔人和開發閉隊之間達成共識；

(4)揭露和解決那些妨礙項同成功的行政問題；

(5)能夠很快地產生初步的系統定義。

可用於確認假設和收集統計傾向數據，問卷需要快速叫答，允許匿名方式。存在問題的是：相關的問題不能事先決定；問題背後的假設對答案造成偏頗。如“這符合你的期望嗎?”難以探索一些新領域：難以繼續用户的模糊響應。在完成最初的面談和分析後，問卷調查可作為一項協作技術收到良好的效果。

掌握用户如何實際使用一個系統以及到底用户需要哪些信息，最好的辦法是親自觀察用户是如何完成實際工作的。 一般方法如下。

(1)對辦公室進行快速瀏覽，瞭解佈局、設備要求和使用、工作流總體情況；

(2)安排幾個小時觀察用户是如何。實際完成他們的工作的，理解用户實際使用計算機系統和處理事務的細節；

(3)像用户一樣接受訓練和做實際工作，發現關鍵問題和瓶頸。

一個軟件原型是所提出的新產品的部分實現，幫助開發人員、用户以及客户更好地理解系統的需求，它比開發人員常用的技術術語更易於理解。建立原型可以解決在產品開發的早期階段需求不確定的問題，用户、經理和其他非技術項目風險承擔者發現在確定和開發產品時，原型可以使他們的想象更具體化，如建立基於Web的應用系統原理，使用HTML進行界而設計。

隨着面向對象技術的發展，基於用例的方法任需求獲取和建模方面應用越來越廣泛。用例建模是以任務和用户為中心的，開發和描述用户需要系統做什麼。另外，用例幫助於開發人員理解用户的、業務和應用領域，並可以運用面向對象分析和設計方法將用例轉化為對象模型。

用例建模的基本步驟入下。

(1)確定系統的參與者：參與者是與系統交互的外部實體，它既可以是人員也可以是外部系統或硬件設備。

(2)確定場景：場景是對人們利用計算機系統過程做了什麼和體驗了什麼的敍述性描述，它從單個參與者的角度觀察系統特性的具體化和非正式的描述。

(3)確定系統用例：用例描述了一個完整的系統事件流程，其重點在於參與者與系統之間的交互而不是內在的系統活動，並對參與者產生存價值的可觀測結果。

(4)確定用例之間的關係：在確定出每一個參與者的用例之後，需要將參與者和特定的用例聯繫起來，最終繪製出系統的用例圖。

(5)編寫用例描述文檔：單純使用用例圖並不能提供用例所具有的全部信息，因此需要使用文字描述那些不能反映在網形上的信息。用例描述是關於角色與系統如何交互的規格説明，要求清晰明確，沒有二義性。在描述用例時，應該只注重外部能力，不涉及內部細節。 ^[2]