軟件行業需(xu)求(qiu)工作(zuo)(zuo)主(zhu)要由需(xu)求(qiu)分析(xi)師負(fu)責，需(xu)要完成對用戶(hu)需(xu)求(qiu)的(de)(de)調研(yan)、分析(xi)、整理，從而將用戶(hu)需(xu)求(qiu)轉換為可供開發的(de)(de)功(gong)能需(xu)求(qiu)。但隨(sui)著互聯網思維的(de)(de)普(pu)及(ji)，軟件行業也越(yue)來(lai)越(yue)強調產品(pin)經(jing)理的(de)(de)作(zuo)(zuo)用，或許并不(bu)是(shi)互聯網思維的(de)(de)關系，而是(shi)隨(sui)著公司(si)的(de)(de)發展，必須尋求(qiu)由項目盈利(li)模式(shi)向產品(pin)盈利(li)模式(shi)轉變(bian)，從而催生出(chu)產品(pin)經(jing)理的(de)(de)角色，以及(ji)對其的(de)(de)重(zhong)視(shi)。

對于軟(ruan)件(jian)行(xing)業的(de)產品經理來(lai)說(shuo)，最核心的(de)職責還是跟需求分析師一樣，是從(cong)需求到產出原型的(de)過程(cheng)。在(zai)這個過程(cheng)中主要使用的(de)需求分析方法是面向對象需求分析方法。

面向對象需求分析方法

面向對(dui)(dui)象需(xu)求(qiu)(qiu)分析(xi)方(fang)法是通(tong)過統一建模(mo)語言 UML對(dui)(dui)用戶需(xu)求(qiu)(qiu)進(jin)行調研和(he)分析(xi)，并整(zheng)理出功能需(xu)求(qiu)(qiu)的分析(xi)方(fang)法。

需求分析過程

前面已經講到需(xu)(xu)(xu)求(qiu)分析(xi)過程就是要(yao)將用戶需(xu)(xu)(xu)求(qiu)轉換為可(ke)供開發(fa)的功能(neng)需(xu)(xu)(xu)求(qiu)，為了達到這目的需(xu)(xu)(xu)要(yao)開展(zhan)一系列需(xu)(xu)(xu)求(qiu)活動(dong)。

收集并分析問題

在開展一(yi)項需(xu)求工(gong)作(zuo)之(zhi)前，都會從任(ren)(ren)務提出人哪(na)里得到(dao)客戶(hu)的(de)想法（任(ren)(ren)務提出人不一(yi)定是(shi)客戶(hu)，可(ke)能是(shi)銷(xiao)售(shou)同事(shi)、項目經理或維護經理）。但任(ren)(ren)務描述可(ke)能會比(bi)較粗(cu)糙(cao)，也較為含糊，還不足以指導后(hou)續的(de)需(xu)求工(gong)作(zuo)。

因(yin)(yin)此當(dang)你收到一項任(ren)務(wu)時(shi)，如果(guo)不了(le)解情(qing)況，那么(me)必須向任(ren)務(wu)提(ti)出(chu)人(ren)咨(zi)詢清(qing)楚，客戶(hu)(hu)(hu)為什么(me)提(ti)出(chu)這項任(ren)務(wu)，需要(yao)達到什么(me)目的(de)，也就(jiu)是盡量了(le)解任(ren)務(wu)提(ti)出(chu)的(de)背(bei)景。如果(guo)你不了(le)解客戶(hu)(hu)(hu)所提(ti)要(yao)求涉及的(de)業務(wu)背(bei)景，或(huo)不了(le)解前因(yin)(yin)后果(guo)，將對后續的(de)梳理(li)疑(yi)問和(he)用戶(hu)(hu)(hu)訪(fang)談(tan)造成很大的(de)影(ying)響。

接下來(lai)(lai)就(jiu)要有(you)針(zhen)對性的(de)補充相關(guan)的(de)知識背景(jing)，例如戶政客戶需要建設一(yi)項重戶人員注銷的(de)功能(neng)，那就(jiu)需要了解一(yi)下是(shi)不是(shi)最(zui)近有(you)新的(de)政策出來(lai)(lai)，或(huo)是(shi)不是(shi)最(zui)近公(gong)安部有(you)檢(jian)查，查出本省的(de)重戶人員較多而(er)被(bei)通(tong)報了。這對后(hou)續(xu)功能(neng)實現可能(neng)起作用，也可能(neng)不起作用，但一(yi)定會(hui)對后(hou)續(xu)用戶訪談的(de)交流(liu)帶(dai)來(lai)(lai)極(ji)大的(de)好處(chu)。

在搞懂用戶(hu)要求的過(guo)程(cheng)中，你(ni)會產(chan)生很多疑(yi)(yi)問，這(zhe)(zhe)時需要將(jiang)疑(yi)(yi)問分類整理好，為(wei)下一步用戶(hu)訪談提(ti)供基礎(chu)。梳理疑(yi)(yi)問需要以用戶(hu)場景為(wei)指導，可(ke)沿著“誰要什么功能，達到(dao)什么目的”這(zhe)(zhe)一思路(lu)進行整理。

雖然在(zai)需(xu)求(qiu)調研階(jie)段不(bu)應該(gai)過(guo)多地(di)思考功(gong)(gong)能(neng)(neng)實(shi)現，不(bu)過(guo)絕(jue)大部(bu)分情況(kuang)(kuang)都(dou)是在(zai)原有功(gong)(gong)能(neng)(neng)的(de)(de)基(ji)(ji)礎上(shang)提(ti)出新的(de)(de)需(xu)求(qiu)，全新的(de)(de)系統建設(she)反而較少(shao)。這(zhe)種情況(kuang)(kuang)下很難不(bu)基(ji)(ji)于現有功(gong)(gong)能(neng)(neng)思考新需(xu)求(qiu)的(de)(de)實(shi)現。我認為無需(xu)太嚴格區(qu)分需(xu)求(qiu)的(de)(de)每個階(jie)段，在(zai)現有的(de)(de)功(gong)(gong)能(neng)(neng)基(ji)(ji)礎上(shang)先構思解(jie)決(jue)方案是沒有問題(ti)(ti)(ti)(ti)的(de)(de)，只要能(neng)(neng)基(ji)(ji)于用戶場(chang)景(jing)，最(zui)終能(neng)(neng)滿足用戶需(xu)要即可(ke)(ke)。因此這(zhe)時可(ke)(ke)以基(ji)(ji)于大概(gai)地(di)功(gong)(gong)能(neng)(neng)實(shi)現的(de)(de)解(jie)決(jue)方案為出發來(lai)梳理細(xi)節問題(ti)(ti)(ti)(ti)，例(li)如考慮到實(shi)現某個功(gong)(gong)能(neng)(neng)或操作(zuo)時會有什么問題(ti)(ti)(ti)(ti)，就把(ba)問題(ti)(ti)(ti)(ti)記下來(lai)。但需(xu)要跟客戶核(he)實(shi)的(de)(de)問題(ti)(ti)(ti)(ti)應該(gai)還(huan)是以業務問題(ti)(ti)(ti)(ti)為主，如果只是些交互或操作(zuo)層面上(shang)的(de)(de)問題(ti)(ti)(ti)(ti)，大可(ke)(ke)等到原型設(she)計時，再進(jin)一(yi)步細(xi)化，或內(nei)部(bu)討(tao)論(lun)解(jie)決(jue)。

用戶訪談

用戶訪(fang)談不是(shi)(shi)簡單的(de)將(jiang)問(wen)題(ti)清單拿出來一個(ge)個(ge)問(wen)，問(wen)題(ti)清單只是(shi)(shi)輔助，主(zhu)要(yao)是(shi)(shi)你自己(ji)要(yao)明白自己(ji)想要(yao)搞懂的(de)是(shi)(shi)什么。可(ke)以(yi)將(jiang)問(wen)題(ti)進行(xing)分(fen)類，整理每類問(wen)題(ti)的(de)核心，然后基于核心向外發(fa)散(san)。

最先要明確(que)的是(shi)從大的范圍來看(kan)，整(zheng)個(ge)需(xu)(xu)求需(xu)(xu)要實現的功能是(shi)給誰用的，達(da)到什么目的。再對細分的小(xiao)需(xu)(xu)求進行確(que)認，還(huan)是(shi)給誰用，達(da)到什么目的。最終理出(chu)每個(ge)用戶場景的角色(se)和目的，方(fang)便后續需(xu)(xu)求分析及功能驗證。

用戶(hu)訪(fang)談(tan)時，很(hen)重要(yao)的一項(xiang)(xiang)技(ji)能(neng)是挖掘客戶(hu)原話背(bei)后的真實需求，以及通過一定的提問技(ji)巧來幫助你完成(cheng)訪(fang)談(tan)。下面(mian)是關于用戶(hu)訪(fang)談(tan)時的一些提問技(ji)巧，以某項(xiang)(xiang)目(mu)客戶(hu)提出報表需要(yao)導出為(wei)PDF為(wei)例。

1、用各種角色的身份進行提問
例：誰需要這個PDF文檔？高層領導、檔案管理員、部門經理？
2、進行反向提問（逆向提問）
例：不做這個功能會有什么影響？（體現該功能的重要性）
3、進行外延（發散、深入）提問
例：PDF文檔有什么格式要求？
例：為什么需要做這個功能？
4、對原話的每一部分進行提問
例：什么報表(biao)需要導(dao)出為(wei)PDF？

根據用戶(hu)訪(fang)談的(de)結果，形成(cheng)一(yi)個個的(de)用戶(hu)場(chang)景，最后將用戶(hu)場(chang)景組裝成(cheng)一(yi)個完整(zheng)的(de)故事，這(zhe)個故事就(jiu)是整(zheng)個業(ye)務過程。

結構建模

每(mei)個系統或功能(neng)都會涉及(ji)到不(bu)同角色、業務(wu)概(gai)念(nian)和物品等，這(zhe)些事物之間會有很(hen)多(duo)關(guan)系，發生(sheng)很(hen)多(duo)事情。特別(bie)是(shi)當我們(men)剛接觸新的業務(wu)時，最(zui)急迫需要解決的問題就是(shi)理(li)清楚這(zhe)些業務(wu)概(gai)念(nian)以及(ji)他們(men)之間的關(guan)系。

類(lei)圖能幫(bang)助我們識別(bie)出這(zhe)些角色(se)、業務(wu)概(gai)念、物品等，并(bing)理(li)清他們的(de)關系(xi)，這(zhe)個過程就是機構建模。類(lei)圖除了分析業務(wu)需(xu)求(qiu)作(zuo)(zuo)用外，還起來指導原型(xing)設計(ji)的(de)作(zuo)(zuo)用。一方面是在(zai)設計(ji)時能理(li)清每個實體有哪些項(xiang)目；另(ling)一方面是功能與功能之間的(de)關系(xi)，一對(dui)一和一對(dui)多的(de)設計(ji)方式是完全不一樣(yang)的(de)。

行為建模

行為建模是通過活動圖描述業務活動流程的過程。在梳理用戶場景時會得到具體的業務事件，也對業務事件的辦理過程有了大概的了解。接下來需要通過活動圖對業務事件的過程進行明確，盡量使用泳道圖明確各個活動的使用角色，即使是單角色的流程也應該明確標出角色名稱。
業(ye)務流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)分(fen)(fen)為生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)、管(guan)(guan)理(li)(li)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)和(he)支持性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)。生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)是流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)中最重(zhong)要的(de)(de)部(bu)分(fen)(fen)，是企業(ye)/組(zu)織價值體現的(de)(de)核心(xin)；管(guan)(guan)理(li)(li)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)是對生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)的(de)(de)管(guan)(guan)控，通(tong)常是有管(guan)(guan)理(li)(li)層發(fa)現的(de)(de)，對一(yi)些質(zhi)量、效(xiao)率進行(xing)監督的(de)(de)控制性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)；支持性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)是對生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)的(de)(de)一(yi)種補(bu)充，通(tong)常是由協作(zuo)部(bu)門、本部(bu)門員工執(zhi)行(xing)的(de)(de)工作(zuo)。如果拿(na)軟(ruan)件開發(fa)過程(cheng)(cheng)(cheng)(cheng)(cheng)來比喻的(de)(de)話，需求(qiu)分(fen)(fen)析(xi)、軟(ruan)件設計、軟(ruan)件編(bian)碼、軟(ruan)件測(ce)試是生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)；項目(mu)管(guan)(guan)理(li)(li)、質(zhi)量保證是管(guan)(guan)理(li)(li)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)；而(er)(er)文檔配置等屬于(yu)支持性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)。通(tong)常生(sheng)(sheng)產(chan)(chan)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)是最容(rong)易標識的(de)(de)，而(er)(er)管(guan)(guan)理(li)(li)性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)和(he)支持性(xing)(xing)(xing)(xing)流(liu)程(cheng)(cheng)(cheng)(cheng)(cheng)比較(jiao)容(rong)易忽略，因此在需求(qiu)分(fen)(fen)析(xi)時要特別(bie)注意。

功能建模

用例圖的作用主要是將活動圖中不在系統范圍內的部分過濾掉，只保留可以通過系統實現的活動。對于每一個人機交互的活動，需要細化分析其事件流，也就是當前活動里人機交互的詳細過程，這個過程也可以通過活動圖繪制。
用例中的事件流是原型設計的重要輸入來源，另一個輸入來源是類圖中的對象屬性及對象間的關系。
用(yong)例(li)圖(tu)示(shi)例(li)如(ru)下圖(tu)所示(shi)：

在完成用(yong)例圖后，需要進一步細化用(yong)例說明：

經過一系(xi)列建模分(fen)析(xi)后，基(ji)本的功能都(dou)已經明確，這(zhe)時需要對功能進行(xing)有(you)(you)效(xiao)地組合(he)，聚合(he)成有(you)(you)機(ji)的整體。一般會以業務和角色兩個(ge)維度(du)進行(xing)分(fen)析(xi)。