取得成功的軟件項目是創(chuàng)建在取得成功的需求基本以上的，而高品質的需求來自用戶與開發(fā)人員中間有效溝通與協(xié)作。當用戶有一個難題能夠利用計算機系統(tǒng)來處理，而開發(fā)人員逐漸協(xié)助用戶處理這個問題，溝通交流就開始了，溝通的技巧就看起來至關重要了。

需求獲取可能是開發(fā)軟件中最艱難、最重要、容易錯誤及最必須交流的主題活動。對需求的獲取通常有不正確的了解：用戶了解需求是啥，大家所需做的便是和她們溝通交流從她們那邊獲得需求，只需問用戶系統(tǒng)的總體目標特點，什么叫要進行的，哪些的系統(tǒng)能合適商業(yè)服務必須就可以了，可是事實上需求獲取并并不是想像的那樣簡易，這條溝通交流之途鋪滿了荊棘。最先需求獲取要界定難題范疇，系統(tǒng)的界限通常是難以確立的，用戶不了解技術性完成的關鍵點，那樣導致了系統(tǒng)總體目標的搞混。

次之是對難題的了解，用戶對電子計算機系統(tǒng)的工作能力和限定欠缺掌握，一切一個系統(tǒng)都是會有很多的用戶或是不一樣種類的用戶，每一個用戶只了解自身必須的系統(tǒng)，而不清楚系統(tǒng)的總體狀況，她們不清楚系統(tǒng)做為一個總體如何工作效能更強，都不太清晰這些工作中能夠交到手機軟件進行，她們不清楚需求是啥，換句話說怎樣以一種精準的方法來敘述需求，她們必須開發(fā)人員的幫助和具體指導，可是用戶與開發(fā)人員中間的溝通交流非常容易發(fā)生阻礙，忽視了這些被覺得是"很確立的信息內容。最終是需求的確定，由于需求的多變性通常伴隨著時間的變化造成變化，使之無法確定。為了更好地擺脫之上的難題，務必有機構的實行需求的獲取主題活動。

需求獲取主題活動提議要進行的11個每日任務換句話說流程分別是明確需求全過程、撰寫新項目主視圖和范疇文本文檔、用戶群歸類、挑選用戶代表、挑選用戶代表、創(chuàng)建關鍵團隊、明確應用案例、舉辦協(xié)同大會、剖析用戶工作內容、明確品質特性、查驗問題報告和需求器重。自然應當依據機構和新項目的詳細情況開展適度的裁掉，例如依據新項目和用戶狀況把需求獲取大會改為調查問卷或是研討這些。

1、撰寫新項目主視圖和范疇文本文檔

系統(tǒng)的需求包含四個不一樣的層級：業(yè)務流程需求、用戶需求和作用需求、非多功能性需求。業(yè)務流程需求表明了給予給用戶新系統(tǒng)的最開始權益,體現了組織架構或用戶對系統(tǒng)、商品高端的總體目標規(guī)定，他們在新項目主視圖與范疇文本文檔中給予表明。用戶需求文本文檔敘述了用戶應用商品務必要進行的每日任務，這在應用案例文本文檔或計劃方案腳本制作表明中給予表明。作用需求界定了開發(fā)人員務必完成的手機軟件作用，促使用戶能進行她們的每日任務，進而達到了業(yè)務流程需求。

非多功能性需求是用戶對系統(tǒng)優(yōu)良運行明確提出的期待，包含了便捷性、反應速率、容錯性、可擴展性這些品質特性。需求獲取便是依據系統(tǒng)業(yè)務流程需求去得到系統(tǒng)用戶需求，隨后根據需求剖析獲得系統(tǒng)的作用需求和非作用需求。新項目主視圖和范疇文本文檔就是以高端上敘述系統(tǒng)的業(yè)務流程需求，應當包含高層住宅的商品業(yè)務流程總體目標，評定難題解決方法的商業(yè)服務和技術性可行性分析,全部的應用案例和作用需求都務必遵循的規(guī)范。而范疇文本文檔界定了新項目商品所包含的全部工作中及造成商品常用的全過程。新項目有關工作人員對新項目的總體目標和范疇能達成一致,全部團隊都應當把注意力集中在項目目標和范疇上。

2、用戶群歸類

系統(tǒng)用戶在許多層面存有著差別，比如：應用系統(tǒng)的頻率和水平、主要用途和電子計算機系統(tǒng)專業(yè)知識、所應用的系統(tǒng)特點、所開展的業(yè)務流程全過程、訪問限制、自然地理上的合理布局及其本人的素養(yǎng)和愛好這些。依據這種差別，你能把這種不一樣的用戶分為不一樣的用戶類。與UML中Usecase的Actor定義一樣，用戶類不一定都指人，還可以包含別的運用系統(tǒng)、插口或是硬件配置，那樣做促使與系統(tǒng)界限外的插口也變成系統(tǒng)需求。將用戶群歸類并梳理分別特性，并詳細說明出他們的個性特征及每日任務情況，將有利于需求的獲取和系統(tǒng)設計方案。

3、挑選用戶代表

不太可能對全部的用戶都開展需求獲取，那樣做時間不允許實際效果也不一定好，因此 要鑒別出可以明確需求和掌握工作流程的用戶做為每類用戶的代表。每類用戶最少挑選一位能真真正正代表她們需求的人做為代表而且可以做出管理決策，用戶代表通常是該類用戶中三類人：對新項目有決策權的領導干部、了解工作流程的權威專家、系統(tǒng)最后用戶。

每一個用戶代表者代表了一個特殊的用戶類，并在那一個用戶類和開發(fā)人員中間當做關鍵的插口，用戶代表從她們所代表的用戶類中搜集需求信息內容，與此同時每一個用戶代表又承擔融洽她們所代表的用戶在需求表述上的不一致性和不兼容模式。

4、創(chuàng)建關鍵團隊

一般 用戶和開發(fā)人員不自覺的都是有一種"大家和她們"的念頭，造成一種對立面關聯，把彼此之間放到對立，每一方都界定自身的"界限"，只想要自身的權益而忽視另一方的念頭。她們根據文本文檔、紀錄和會話來溝通交流，而不是做為一個協(xié)作的總體去鑒別和明確需求達到目標。實踐經驗證明那樣的方式 是有誤的，不容易給彼此產生一點好處,良好的溝通關聯沒有創(chuàng)建造成 了誤會和忽視關鍵的信息內容。僅有當彼此參加者都搞清楚要取得成功自身需要什么，與此同時也了解要取得成功另一方必須什么時，才可以創(chuàng)建起一種合作關系。

為了更好地創(chuàng)建合作關系一般 采用一種聯機的方法來獲取需求，創(chuàng)建一個由用戶代表和開發(fā)人員構成的協(xié)同工作組做為需求獲取的關鍵團隊。協(xié)同工作組將承擔鑒別需求、剖析解決方法和商議矛盾，工作組組員能夠選用大會、電子郵箱、綜合辦公系統(tǒng)等方法開展溝通交流，但溝通交流時要留意下列標準：小組會應當由中立方米來機構和主持人，用戶和開發(fā)人員都需要參與;溝通交流事先要明確提前準備和參加的標準;議案要確立并遮蓋全部關鍵環(huán)節(jié)，但信息內容來源于應當隨意;溝通交流總體目標要確立，并告之全部的組員。

5、明確應用案例

從用戶辦事處搜集她們將應用系統(tǒng)進行所需每日任務的敘述，討論用戶與系統(tǒng)間的交互技術和會話規(guī)定，這就是應用案例，一個單一的應用案例很有可能包含進行某種每日任務的很多邏輯性有關每日任務和互動次序。應用實例方法給需求獲得產生的益處來自于該方式 是用于每日任務為管理中心和以用戶為管理中心的見解，相比應用以作用為管理中心和以開發(fā)人員為管理中心的方式 ，應用實例方法能夠使用戶更清晰地了解和了解到新系統(tǒng)容許她們干什么和如何做。描繪應用案例的情況下要留意應用簡約直接的描述，盡可能應用主動語態(tài)，"系統(tǒng)"或是"用戶"做為謂語，例如"用戶遞交用戶登陸密碼，系統(tǒng)認證用戶登陸密碼是不是恰當"，也有一點在敘述中不必設計方案頁面關鍵點，例如"用戶從下拉列表中挑選產品類別"。應用案例為之后寫用例情景敘述中的基本上途徑和拓展途徑給予了素材圖片。

6、舉辦協(xié)同大會

最普遍的需求獲得方式 是召開工作會議或是談話，協(xié)同大會是覆蓋面廣的、簡單的討論會，也是關鍵團隊組員中間一種非常好的溝通交流方式 ，該大會根據密切而集中化的討論得到將用戶意味著與開發(fā)者間的合作方關聯付諸實踐實踐活動并能從而擬出需求文本文檔的底稿。協(xié)同大會的第一個議案便是系統(tǒng)的重要性和合理化，務必全部組員都愿意系統(tǒng)是必需的并且有效的。下面就可以討論應用案例明細，明細能夠打印出成實紙掛在墻壁、寫在教室黑板上或制成演試原材料。對每一個明細合拼除掉反復項，再加上填補內容就可以獲得一份總的明細，留意防止選用負面信息的"很差""不行得通"去否認用戶的念頭，這種念頭都應當保存出來做為被評定的清單項工程，那樣維護了工作組組員對外開放的邏輯思維。最終對明細開展討論，大會組員務必查驗每一個應用案例，在把他們列入需求以前決策其是不是在新項目所界定的范疇內，產生最后的需求匯報。

在開展討論時，也應當防止受不成熟的關鍵點的危害，在對系統(tǒng)需求獲得的共識以前，用戶能非常容易地在一個表格或提示框中列舉一些精準設計方案，假如這種關鍵點都做為需求記下來，她們會給接著的設計過程產生多余的限定，應保證用戶參加者將注意力集中在與所討論的話題討論合適的抽象性層上，關鍵便是討論干什么而不是如何做。這里有一點很重要便是要讓用戶了解針對一些作用的討論并不代表著將要在系統(tǒng)中完成它，更不必做暗示著或是服務承諾何時進行需求。在討論以后，記錄下來所討論的內容，并請參加討論的用戶評價并更改，由于僅有給予需求的優(yōu)秀人才能明確是不是真真正正獲得需求。當最終取得了一份詳盡精確的需求報告的情況下，大會即使取得成功完成了?？墒且逦枨笕^程自身便是一個迭代更新的全過程，在之后的全過程主題活動中難以避免的即將改動和健全這一份匯報。

7、剖析用戶工作內容

剖析用戶工作內容觀查用戶實行業(yè)務流程每日任務的全過程，根據剖析應用案例獲得系統(tǒng)的用例圖。定編用例圖文本文檔將有利于確立系統(tǒng)的應用案例和作用需求，統(tǒng)一建模語言的應用有利于與用戶進一步溝通交流。每一個用例的敘述應包含：序號,為每一個用例分派一個唯一的序號，為需求的追朔給予了便捷;參加者，與這一用例互動的actor;前提條件，逐漸用例前所務必具有的系統(tǒng)情況;后置攝像頭標準，用例進行后系統(tǒng)做到的情況;基本上途徑，用例進行的關鍵線路，也是用戶期待的途徑;拓展點，基本上途徑的發(fā)枝，表明出現意外狀況;字段名表明，途徑中名字的進一步溶解表明，對之后類特性的界定和數據庫查詢字段名設計方案起功效;設計方案管束，完成用例的非作用管束。寫基本上途徑時應當應用積極句子;語句以actor或是系統(tǒng)做為謂語;一句表明一個actor姿勢，一句表明系統(tǒng)姿勢，交叉式主要表現互動;不必涉及到頁面關鍵點，例如"用戶在輸入框鍵入名字，下拉列表挑選種類"。

用例：用戶申請注冊，用戶申請注冊變成系統(tǒng)vip會員

序號

UC1

參加者用戶

前提條件

用戶瀏覽系統(tǒng)，系統(tǒng)運作一切正常

后置攝像頭標準

系統(tǒng)紀錄用戶申請注冊信息

基本上途徑

1.用戶要求申請注冊。

2.系統(tǒng)表明申請注冊頁面。

3.用戶遞交申請注冊信息。

4.系統(tǒng)認證申請注冊信息是不是恰當。

5.系統(tǒng)轉化成用戶名和登陸密碼，儲存申請注冊信息。

6.系統(tǒng)表明"認證成功"信息，進到vip會員網頁頁面。

拓展點

4a.用戶給予的信息有誤：

4a1.系統(tǒng)提醒鍵入恰當信息

4a2.回到3

補充說明

申請注冊信息包含=用戶實名認證+電話+發(fā)傳真+Email+通訊地址通訊地址=省區(qū)+大城市+街道社區(qū)+郵政編碼

設計方案管束

申請注冊反應速度不可以超出3秒

8、明確品質特性

在作用需求以外再考慮一下非作用的品質特性，及其明確因為獨特的商業(yè)服務應用場景對系統(tǒng)明確提出的作用或特性上的管束，這會使你的商品做到并超出顧客的期待。對系統(tǒng)怎樣能非常好地實行一些個人行為或讓用戶采用某一對策的闡述便是品質特性，它是一種非作用需求。征求這些敘述有效特點的建議：便捷、簡單、直覺性、用戶友善、可擴展性、穩(wěn)定性、安全系數和精確性。你即將和用戶一起商議精準界定她們模糊不清的和主觀性言語的真真正正含意，而且要將品質特性分派到每一個用例的設計方案管束中去。

9、查驗問題報告

根據查驗當今早已運作系統(tǒng)的問題報告來進一步健全需求顧客的問題報告及填補需求為新系統(tǒng)或最新版本給予了很多豐富多彩的改善及提升特點的念頭，承擔給予用戶適用及協(xié)助的人能為搜集需求全過程給予極有使用價值的信息。

10、需求器重

假如顧客規(guī)定的作用與現有的系統(tǒng)很類似，則可查詢需求是不是有充足的協(xié)調能力以容許器重一些現有的手機軟件部件。業(yè)務流程模型和領域建模式需求器重的最好是方式 ，像剖析方式和策略模式一樣，需求也是有自身的方式。