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