本篇不是為業務分析人員寫的，不會細緻講解需求分析的方方面面，業務分析師可以看徐鋒的《軟體需求最佳實踐》，或者王海鵬翻譯的《掌握需求過程》。本篇立足於架構師視角，講解需求分析過程中應了解的過程和方法，以及需要特別關注的點。
開發者拿到的往往是乙個個的方案，方案來自於需求，那麼開發者拿到的需求是怎麼來的？乙個叫願景分析乙個叫需求分析，願景分析產生市場/產品需求文件，需求分析產生軟體需求規格說明書。說起來玄乎，我們直接看看這兩個文件長什麼樣：
《軟體架構設計》第5章 需求分析 產品需求文件
《軟體架構設計》第5章 需求分析 軟體需求規格說明書
開發團隊需要用產品需求文件來評估需求是否可接受，從這個角度來思考，你需要哪些資訊？首先你要知道背景和目標，開發團隊要仔細「問」清楚客戶真實的目標，有時候客戶所提的並不是真正的想要的東西，知道目標和背景，開發團隊才能深入問下去。其次要知道價值和代價，比如花幾十萬cycle做乙個收益不大的事情，此類需求就不能接受。如果已經接受了需求，那麼範圍和侷限性就顯得非常重要，所謂範圍，就是把系統作為乙個黑盒，劃清楚系統與外部的邊界。
軟體需求規格說明書是用來指導系統分析的，系統分析是初步的高層設計。為了進行系統分析，我們需要哪些資訊呢？做什麼，規格說明書裡對「做什麼」的描述非常詳細，因為它描述了用例，輸出了用例圖。用例還是在從外部看軟體系統，但用例描述了外部看到的所有可能的情況。我們把「做什麼」姑且叫做功能需求，質量屬性和約束是另外兩個非常重要的需求型別，實際專案中常會把質量屬性和約束漏掉，蓋因規劃和需求分析師不關心或不知道如何關心質量屬性和約束，這樣導致的乙個問題就是功能需求瘋狂進，架構腐化和畸變加速，產品質量下降，最後無法繼續承接需求。功能需求、質量屬性、約束對架構影響的原理不同。
功能：架構師通過功能發現職責，將職責分配到子系統，確定介面和互動機制，來推動架構設計；
質量：基於功能的架構設計，進一步考慮質量要求，細化、調整、推倒重來，來完善架構設計；
約束：直接制約設計決策，有的能夠轉化為功能和質量屬性。
功能不必說，功能是主要賣點，因為有無數人關心功能，軟體的功能性大部分能得到保證；約束也不必說，功能必須在一定約束下才能正常合入和驗證；但質量就不好說了，架構師無法時刻監督，質量沒人關心，劣化在長期累積下才會顯現出它的危害，有乙個辦法就是進行架構度量，把質量轉化為合入的約束，自然能夠得到應有的關注。
上圖來自iso25010軟體質量模型，描述了軟體質量涉及到的各個方面。
我們可以實時度量效能、複雜度、依賴程度、風格一致性等，可以事後度量高可用性、安全性、可靠性、健壯性、可移植性，事後度量意義不大，而且不是所有的指標都能有效地度量，所以質量和度量應該是架構師工作的重點區域。
需求分析，分析需求
1.何為需求 我們吧需求兩個漢字拆分開來看 需 需要 求 要求 即需要的要求，表示想要某種東西的堅定願望 這裡插入乙個小故事，某個小男孩在上小學二年級的時候，不經意間接觸到了一種叫psp的神奇玩具，就下定決心回家找家長要，一開始小孩的父親不贊同給小孩買那個東西，後來在小孩的再三請求，甚至為此寫了份保...
介面需求分析
1 引言 軟體的 介面 是人與計算機之間的媒介。使用者通過軟體的介面來與計算機進行資訊交換。因此，軟體介面的質量，直接關係到軟體系統的效能能否充分發揮，能否使使用者準確 高效 輕鬆 愉快地操作。所以軟體的友好性 易用性對於軟體系統至關重要。目前，國內軟體開發者在軟體的設計過程中很注重軟體的開發技術及...
需求分析 需求文件（需求分析結果）的作用
需求分析學習指導目錄 1 在需求方面達成一致 需求是一種反覆進行的過程，涉及到各種各樣具有不同背景和要求的使用者，需求文件必須有助於需求分析師與使用者之間的溝通，以及需求分析師與軟體設計師和測試工程師之間的溝通 2 為軟體設計提供基礎 需求文件必須為軟體設計人員提供精確的輸入，因為設計人員不是應用領...