繞不過去的坎---需求分析需求.分析師也好，系統(tǒng)分析師也好，架構(gòu)師也好乃至PM都有一道繞不過去的坎，那就是需求分析。需求分析也繞不過需求收集。
需求收集的要點：
1，參與人。很重要。廣義上是指各種干系人，如客戶方，自己方的.具體的軟件操作員可以是直接參與人，但也可能是代理參與人，比如聲訊話務(wù)員，并不是系統(tǒng)的直接參與者，而是代理人。嗯，可以理解成別人請話員操作軟件。甚至打電話進(jìn)來的也是一個代理人，他幫別人辦理業(yè)務(wù)。也有可能有數(shù)據(jù)權(quán)限要求。
2，用例。描述業(yè)務(wù)場景。通俗一點講即參與人要辦的事情。
3，邊界。邊界有兩種意義。一種是技術(shù)實現(xiàn)層面，比如mvc模式中的V。另一種是業(yè)務(wù)層面的，指本用例需要達(dá)到的目標(biāo)。
以上三點，UML中有業(yè)務(wù)用例圖表示。但是僅此還不夠。俺給加上第
4，業(yè)務(wù)規(guī)則。即完成業(yè)務(wù)的約束條件。這個單獨抽出非常重要。有些業(yè)務(wù)規(guī)則最終可能會實現(xiàn)為一個系統(tǒng)用例。比如出國需要辦理出入境業(yè)務(wù)。如果在電腦上實現(xiàn)預(yù)約，當(dāng)然要考慮辦理中心排班情況，比如除法定節(jié)假日以外星期一至星期六都工作。因為每年的法定節(jié)假日不是固定的，那我們需要做一個日期是否工作日的排班表出來。這條業(yè)務(wù)規(guī)則即變?yōu)橐粋€系統(tǒng)用例，有人機(jī)交互界面。在預(yù)約出入境時就成了預(yù)約的前置條件。還有其它的業(yè)務(wù)規(guī)則比如報表的計算公式等。可見業(yè)務(wù)規(guī)則是如此重要。可以抽出來弄成單獨的文檔。
系統(tǒng)分析員或需求分析師需要根據(jù)業(yè)務(wù)需求做出系統(tǒng)用例。系統(tǒng)用例在人機(jī)交互應(yīng)用中是指人做什么，然后電腦做什么的描述。
pm會跟用戶聊到需求。架構(gòu)師需要了然關(guān)鍵需求及可能存在風(fēng)險的需求，盡早考慮解決方案。需求分析師也好，架構(gòu)師也好，基本上應(yīng)該擅長業(yè)務(wù)領(lǐng)域模型建模。業(yè)務(wù)領(lǐng)域模型可能映射成數(shù)據(jù)架構(gòu)，即數(shù)據(jù)的存儲方式，比如數(shù)據(jù)庫和文件等。如何正確的建立領(lǐng)域模型？
1，不要放過業(yè)務(wù)場景中的名詞。比如合同，銷售單。
2，不要放過業(yè)務(wù)場景中的動名詞，比如取款。描述可能一是條取款流水記錄，如某人在某個時間某個地點用某種方式取了多少款。
3， 應(yīng)當(dāng)收集業(yè)務(wù)中用到的一些資料如銷售單，出貨單，甚至是公司章程如請假制度管理等。
參與人和業(yè)務(wù)規(guī)則往往容易被忽視掉，這會帶來需求變更。那么問題來了，這些東西如何映射成程序中的對象？如下圖中的商場的小票聯(lián).應(yīng)該怎么建數(shù)據(jù)庫表呢？有沒有方法呢？當(dāng)然有，那就是找出發(fā)票中有哪些對象。根據(jù)對象建數(shù)據(jù)表。
分析過程：
1，問問自己，小票是對象嗎? 當(dāng)然是.因為它有自己的屬性。比如開票人，銷售的商品。在商場pos系統(tǒng)里這個對象其實就是銷售單對象。
2,銷售時間是一個對象嗎？不是。因為它只是一個時間字符串，本身沒有其它屬性。
3,可樂汽水及商品編號當(dāng)然是一個對象。這容易理解。
4，金額3.1元也是一個基本屬性，它屬于什么對象？銷售單本身嗎？顯然不是。它跟可樂汽水這個商品合起來才是一個對象，描述的是銷售單什么價格銷售了什么產(chǎn)品,應(yīng)當(dāng)單獨建立一個表。如果有多個商品？那很容易擴(kuò)充，銷售單有一個LIST<銷售明細(xì)> 的屬性。
對象本身具有良好的繼承性，換句話講按對象模型建立的數(shù)據(jù)庫表基本上都是很容易擴(kuò)展的，在增加新功能的時候不至于大動干戈。架構(gòu)師則根據(jù)此設(shè)計數(shù)據(jù)架構(gòu)視圖，比如銷售單查詢響應(yīng)要求，大數(shù)據(jù)量的水平，垂直分庫，數(shù)據(jù)庫讀寫分離等。