需求分析的目標：是儘可能準確、全面、深入的理解業務。
1：理解“儘可能準確”
首先，需求分析，要做的事，肯定是去理解業務，但是要達到什麼樣的程度，才算是我們理解了這個業務呢？
第一個是“儘可能”，儘可能的意思，就是你不太可能百分之百的、完整的、準確的去理解，做不到。我們只能說是儘自己最大努力去理解，理解性的東西，你不可能做到百分之百的理解這些業務。
第二個詞叫“準確”，這個是特別重要的關鍵詞。準確的含義就是：對每個功能點的理解要沒有歧義，理解的這個功能點要不可再分，也就是說如果對一個功能點，不同的人有不同的理解，那這就是有歧義。
舉個例子來說，當我們看到需求調研文件上有這麼一句話，“這個使用者資料需要在介面上進行選擇”。出現這樣的句子，這個就是不準確的，為什麼呢？因為這句話他是有歧義的。
什麼樣的歧義呢？關鍵就在這個選擇上，大家怎麼選呢，是下拉選單選；還是checkbox選；還是像搜尋框一樣搜尋參照去選擇。你並沒有給我一個準確的描述，所以說，你告訴我介面上可以選擇使用者，對於看文件的人來說，這就是有歧義的，不同的人他可以有不同的理解，這樣是不行的。
當然，如果這個時候是配了原型介面，或者是有相應的html，上面已經準確的畫出來了，他就是下拉選單，或者說他就是checkbox，這沒有問題。但是如果單純只有文件，這個就是有歧義的。
第三個詞是“不可再分”。意思是這個功能點不能太大，不能說這個功能點還能夠裂變成很多小功能點。如果他還能夠裂變成很多小功能點的話，這個功能點的理解就是不夠準確的。
比如說在文件當中來這麼一句話：“要求能夠對日誌進行管理”。其實我們們最怕看到這種話，進行管理，怎麼管？有些什麼樣的功能？是隻對日誌做一個儲存，然後取出來進行檢視，還有沒有其他的真正管理性的功能？
這一個“管理”，它就可以再往下分出很多具體的功能。比如說，我還要把日誌儲存起來，又會涉及到要儲存多長時間的日誌；如何儲存？是集中式的儲存，還是分散式的儲存；對這些儲存的日誌，有沒有什麼其他的功能要求，比如說檢視，比如說審計，比如說進行資料分析，而資料分析，又涉及到要分析哪些東西？分析的演算法是什麼？
這些東西都屬管理的內容，你光給我一個要求對日誌進行管理，就這麼一句話，你讓架構師怎麼設計？你讓開發人員怎麼開發？這就是不夠準確。
看到這個地方，可能很多朋友就會在想，我們們自己的需求裡頭，看過太多這樣子的坑了，往往是一兩句話，就一筆帶過了好大一個功能塊，做著做著就發現問題了。最後為了去填坑，耗費出大量的人力和時間，我們可沒少吃這樣子的虧。
所以說，我們們現就要求，對於需求分析來說，一定要儘可能準確去理解。
2：理解“全面”
第二個，“全面”。這個比較容易理解，就是這個功能點，涉及到什麼細節功能，涉及到什麼樣的流程等等的，都應該分析到，不要漏東西。這個我們就不多講了。
3：理解“深入”
第三個，“深入”。這又有兩層含義，一個就是對自己功能點的一個深入，另一個是功能點之間的深入理解，也就是功能點之間的關係。
對自己功能點的深入，我們們來個例子，比如需求文件上是這麼寫的：“這個價格可以被價格管理員修改，修改後要進行稽核才能生效”，說的很清楚，對吧。但是你仔細往下去分析，就會發現問題了。
你看“價格可以被價格管理員修改”，這句話應該沒啥太大的問題。但是修改過後要進行稽核才能生效，問題就來了，既然是稽核，誰來稽核？稽核有沒有流程？稽核過後的結果，是回到價格管理人員，還是直接生效等等的。大家一看就知道這中間是有問題的了。
有人可能會說，這好像是對稽核功能理解不準確，不是我們說的最終的功能點，也可以這麼理解。
這裡強調的是深入，他有可能並沒有流程，但是我們深入思考一下，要進行稽核才能生效，那麼這個時候我們就要求明確，比方說誰來審、如何審、稽核結果對業務有什麼影響、有沒有稽核流程等等的。我們一定要把這些問題，都要考慮清楚，這才是需求分析真正要做的。
需求分析，不是叫你表面上把拿到的這些需求文件讀一遍，不是這樣子的，你讀完了覺得說這些字我都看懂了，然後大概意思也明白了，這樣子的需求分析是不到位的。一定要一個功能點一個功能點的，準確、全面、深入的去理解才行。
因為在這個過程當中，你會發現很多不明確的地方，而這些東西，現在如果不把它找出來，這些問題就往後推延，就遺留到開發期間，光寫這句話，程式人員根本沒有辦法去做的。
所以說，我們們越早分析清楚越好，這中間可能很多功能，需要我們在做架構設計，做概要設計、詳細設計的過程當中，就需要把它考慮進去，而不是說把這個任務，一直推到程式人員開發的時候。因此，架構師在做需求分析的時候一定要分析的特別的仔細。
再來看另外一個點，就是功能點之間的一些關係的深入理解，可能在需求文件裡面，並沒有提到A功能和B功能之間有什麼樣的聯絡。但是經過我們的深入分析，發現他們之間是有聯絡的。
看個簡單的例子，就來個大家熟悉的請假功能吧，當然請假是有流程的，但是這裡假設它是一個單一的功能，比方說叫“短時請假”的功能。這個功能要求請假人填寫請假單，然後由他的直接領導稽核，他的直接領導批准了，這個請假就透過了，請假成功；不同意的話，也就是請假不成功，就這麼簡單。
但是這個功能，你仔細來分析，又有幾個點，第一個，短時請假，請問啥叫短時？一天兩天三天還是幾個小時，這就意味著為了做短時請假，我們需要有一個配置這個時間限制的功能。這個時候就要想，整個系統裡面有沒有這樣子的配置功能，能夠去控制什麼是短時請假，什麼是長時間請假，是這個道理吧。可能由於這個分析，就引申出新的功能點來了，也可算是一個功能點之間的關係。
再看這句話，“由他的直接領導稽核”。什麼叫他的直接領導？可能有朋友會說，直接領導，不就是他所在的部門領導嗎？那不一定，如果他所在的部門比較大，他可能是在某一個專案組裡面，那專案組長或者TeamLeader算不算他的直接領導？
你看，這又引伸出來一個功能，就是能夠設定每個人的直接領導。這個功能，通常是由組織機構和人員管理子系統來提供的，這就是功能點之間的一個關係，如果組織機構和人員管理子系統那邊不提供這個功能，請問我怎麼判斷誰是他的直接領導呢？
這就是做深入理解，所以，需求分析要真正做好，不是那麼簡單的，是需要大家花很多力氣，去認真、仔細、反覆、深入的思考的。總之，大家需要理解，需求分析的目標就是：儘可能準確、全面、深入的去理解業務。就算我們不能百分之百做到，也要儘可能朝這個目標去努力。
為了大家更好的交流架構設計的思想和知識，大家可以加sishuok，拉你進架構設計群，一起共同學習，共同進步。