需求分析之道——需求分析要做什麼。
需求分析是架構師開始做架構設計的第一步，對架構師來講非常非常的重要。因為需求分析能夠告訴我們，到底我們要做什麼，架構設計就是為了去完成這件事情而做的。
接下來，我們就從實戰的角度來講一講，需求分析的一些方法，都是我們們多年經驗的總結，也許聽上去或者說大家看上去，沒有那麼高大上，但是是非常實用的知識，從幾10萬的小專案到數千萬的大專案都可以用得上這些方法。
我們們要做一件事情，首先要緊盯目標，這樣你才能夠找到自己前進的方向；然後再盯腳下的路，找到具體做事的方法。一步一步，認認真真去做，最終達到這個目標。這裡也一樣，先來看看需求分析的目標是什麼？
一：需求分析的目標：
是儘可能準確、全面、深入的理解業務。
關於這個話題，內容比較多，特別在上一篇《深入理解需求分析的目標》詳細講述了，這裡就不再囉嗦了。
二：識別重難點業務
第二個大的任務，就是識別重難點業務。這個可能要求架構師有一定的業務經驗，這個也算是架構師的一個基本功。拿到需求過後，架構師要能夠快速的識別出裡面的一些重難點的業務，足夠的業務經驗，就能告訴我們，要做這樣子的業務，裡面有哪些功能是非常重要的，有哪些業務可能是比較難做的，也就是我們們俗稱的重難點的業務。
識別出重難點業務有什麼樣的作用呢？就是接下來，在進行分析設計的時候，我們要重點去考慮這些重點業務、難點業務的實現，如果能夠把重難點的業務都解決了，一般來說，常規的、相對普通一些的業務功能，我們們的架構設計，是能夠很好的去滿足的。
這些重難點業務，很可能會影響到我們們後面的，包括像技術選型、具體的架構設計、架構形式，可能都會受到它的影響。
畢竟，軟體只是一個工具，工具嘛，不就是用來幹活的嗎？軟體是用來幹什麼的呢？就是幫助使用者或者客戶，實現業務活動的工具。架構設計是幹什麼的呢？架構設計是為了把軟體造好，也可以說它是為了軟體服務的，開發和製作軟體這個工具。
所以，我們要去識別重難點業務，軟體就是來解決這些業務問題的，肯定首先盯的，就是要解決重難點的業務，這些解決了，那些普通業務肯定能解決。是這個道理吧。
我們們的架構設計，就是在考慮，我怎麼能夠把這個軟體做好。因此，對於重難點業務的把握，可能就直接決定了架構設計的成敗，我們們一定要非常非常的重視。
這一點對於經驗弱一些的架構師，可能就是一個小小的問題了，因為剛開始，他可能不能很快的去識別這些重難點的業務，但這個也沒有關係，即使你剛開始沒有識別出來，那你就儘量驗證的全面一些。比方說，做完你的架構設計了，在做架構驗證的時候，你就多挑一些業務來驗證你的這個架構設計，這樣也能夠避免出現一些問題。
三：識別非功能需求，還有質量約束
第三的一個，要去識別非功能需求，還有質量約束。
啥叫非功能需求呢？就是除去我們們的業務功能需求之外的，剩下的這些需求，統稱為非功能性需求，通常也是軟體質量約束的一部分。
比如說，我們對這個系統提出了一些要求，但不是功能性的，常見的有：效能方面的要求，可靠性方面的要求，可擴充套件性方面的要求，可維護性方面的要求等等的。當然也還有其他的，比如說安全的要求，備份、恢復的要求等等，這些要求對於架構設計的影響也是非常非常大的。
很多都是架構設計要重點考慮的一些問題，比如說像效能問題，可靠性問題，高併發問題，海量資料的問題，可擴充套件的問題等。這些對我們們做架構設計都是有非常大的影響的，所以，在做需求分析的時候，就要把這些識別出來。
最後想要強調一點，需求分析對架構師而言，是非常非常重要的。可以這麼說，需求分析是架構師做架構設計的起點，需求分析沒有做好，後面的全部都是在瞎做。
因為，需求分析會告訴我們：到底要做什麼？如果說，連要做什麼，我們都不知道，那你想想，如果一片迷茫的情況下，就去做所謂的架構設計，請問這個架構設計為誰做的？做來幹什麼？
現在有一些所謂的架構師，輕業務而重技術，成天高談闊論很多新的技術，各種技術大詞、名詞滿天飛，為了技術而技術。但是他忘了架構設計的初心，架構設計的目的是為了軟體服務的，是為了更好的去開發和製作軟體這個工具，僅此而已，不是為了你去炫耀技術的。
可以毫不客氣的說這些人，根本就算不上是真正的架構師，我們可以稱之為是偽架構師，或者說是PPT架構師，有那麼一句話：“離開業務場景談架構設計，那就是在耍流氓”。所以說，大家一定要重視起來，業務很重要，需求分析很重要。
為了大家更好的交流架構設計的思想和知識，大家可以加sishuok，拉你進架構設計群，一起共同學習，共同進步。