當一個諾大的軟件工程項目結束之後，對於技術人員來說，提心吊膽的感覺遠遠大於滿心歡喜的心情，這是因為客戶往往對於我們所完成的項目一臉嫌棄，總是要求我們改這改那，這往往會讓我們失去對項目的滿腔熱血。那麽為什麽客戶會經常對我們的“勞動成果”不屑一顧？當我們對客戶的需求沒有真正理解清楚時，我們做出來的東西客戶必然不滿意。客戶只知道他不滿意，但怎樣才能使他滿意呢？他不知道，於是就在一點兒一點兒試，於是這種反復變更就這樣發生了。如果我們明白了這一點，深入地去理解客戶的業務，進而想到客戶的心坎兒上去，最後做出來的東西必然是客戶滿意的。記住，當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麽提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。

　　知道問題的所在，那麽我們該如何去做軟件的需求分析？以及軟件需求與分析需求我們掌握哪些必要的內容？總結來說，我們需要做到以下幾點：相識——用以了解客戶的性格與習慣愛好；交流——用以充分了解客戶的真正需求；討論——與同事討論分析客戶的需求；畫圖表——對所了解到的需求進行顯示；靈活——對於用戶的需求靈活變通；總結——需求分析結束之後要做的工作。接下來將對以上一點要掌握的內容進行分析講解。

　　相識。所有任務的第一步就是與客戶見面（當然並不是全都如此），通俗來講，兩者的關系是雇主和雇傭的關系，因此我們往往是以一種謙卑和客氣的態度和客戶交流，適當的謙卑是有必要的，但過於的謙卑卻常常給項目日後的進程帶來風險。為什麽這麽說呢？過於的謙卑，處處都是

　　交流。首先是研討會，在會上我們應該多和客戶交談，對於客戶的不合實際的需求，我們應該勇於提出，並且給予能讓客戶滿意的建議，畢竟相對於客戶來說，我們更加專業，另外，用專業術語更能給客戶安全感，從而能更加聽從我們的意見和建議。交流是一個叠代的過程，經常和用戶交談，能更加深入了解客戶，更好地捕捉到客戶的所有需求，最終才能做出讓用戶滿意的軟件。

　　討論。對於自己辛辛苦苦“討來”的客戶的所有需求，在我看來，自己的見解往往是片面的，對於客戶的種種需求，我們無法全面理解，此時，和同職業的人討論更能深入解決自己疑惑的問題。

　　畫圖表。當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往采用想到哪裏做到哪裏的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個疏忽都可能對項目研發帶來風險。因此，我們應當采用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同類型的軟件項目其分析方法可能存在差異，但一般來說，信息化管理類軟件項目通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。功能角色分析與用例圖，功能角色分析是對系統宏觀的、整體的需求分析，它用簡短的圖形繪制出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。

　　靈活。與客戶相比我們是專業的，不能死死只看客戶的需求，有些需求甚至是難以實現的，我們不能不知變通地直接上手，此時，我們需要先和客戶商討然後提出意見，對該功能進行修改，換一種方式去實現。

　　總結。編寫需求規格說明書，用戶需求規格說明書與產品需求規格說明書的差別並不大。領域驅動設計所提倡的就是要讓用戶、需求分析員、開發人員站在一個平臺，使用統一的語言，來表達大家都清楚明白的概念。從這個角度將，需求規格說明書就應當是一個，不區分用戶需求規格說明書和產品需求規格說明書。

01軟件需求概論