先說結(jié)論：

業(yè)務(wù)需求 + 用戶需求===（進(jìn)行需求分析）====>系統(tǒng)需求（軟件需求規(guī)格說明書）。

1.2.3 需求分析

軟件需求是指用戶對新系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望。根據(jù)IEEE軟件工程標(biāo)準(zhǔn)詞匯表，軟件需求是指用戶解決問題或達(dá)到目標(biāo)所需的條件或能力，是系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他規(guī)定文檔所需具有的條件或能力，以及反應(yīng)這些條件或能力的文檔說明。

需求分析：就是把雜亂無章的用戶要求和期望轉(zhuǎn)化為無二義性、完整性、一致性、可測試性、確定性、可跟蹤性、正確性、必要性的用戶需求（業(yè)務(wù)需求+用戶需求=系統(tǒng)需求）。其作用是可以檢測和解決需求之間的沖突，發(fā)現(xiàn)系統(tǒng)的邊界，并詳細(xì)描述出系統(tǒng)需求

（1）需求層次

①業(yè)務(wù)需求，反應(yīng)企業(yè)各客戶對系統(tǒng)高層次的目標(biāo)要求，據(jù)之可以確定項(xiàng)目的視圖和范圍；

②用戶需求，從用戶的角度描述用戶的具體目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)；

③系統(tǒng)需求[1]，即從系統(tǒng)的角度說明軟件的需求，包括功能需求（也稱行為需求，從系統(tǒng)角度說明系統(tǒng)應(yīng)當(dāng)實(shí)現(xiàn)的功能，用戶通過這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。）、非功能需求（系統(tǒng)應(yīng)具備的屬性和品質(zhì)，比如軟件可維護(hù)性、效率等質(zhì)量屬性）和設(shè)計(jì)約束（也稱限制條件或補(bǔ)充規(guī)約，比如必須使用國產(chǎn)數(shù)據(jù)庫系統(tǒng)等）。

可以說：業(yè)務(wù)需求從企業(yè)角度出發(fā)、用戶需求從具體使用者角度出發(fā)、系統(tǒng)需求中的功能需求則是從具體系統(tǒng)出發(fā)；業(yè)務(wù)需求相當(dāng)于戰(zhàn)略、用戶需求相當(dāng)于戰(zhàn)術(shù)、系統(tǒng)需求中的功能需求則是系統(tǒng)對具體戰(zhàn)術(shù)、戰(zhàn)略的具體實(shí)現(xiàn)。

（2）質(zhì)量功能部署（QFD）是一種將用戶要求轉(zhuǎn)化為軟件需求的技術(shù)，其目的是最大限度地提升軟件工程過程中用戶的滿意度。包括：

①常規(guī)需求，用戶認(rèn)為系統(tǒng)應(yīng)當(dāng)做到的功能或性能，實(shí)現(xiàn)越多用戶會越滿意；

②期望需求，用戶想當(dāng)然認(rèn)為系統(tǒng)應(yīng)具備的功能或性能，但并不能正確描述自己相要的這些功能或性能需求。期望需求未實(shí)現(xiàn)，用戶會感到不滿意；

③意外需求[2]，也稱興奮需求，是用戶要求之外的功能或性能，實(shí)現(xiàn)這些功能用戶會更高興，但不實(shí)現(xiàn)也不影響用戶購買的決策

（3）需求分析方法

①結(jié)構(gòu)化分析方法（SA），該方法建立的模型核心是數(shù)據(jù)字典，圍繞核心有三個(gè)層次模型，分別是數(shù)據(jù)模型（用E-R圖描述）、功能模型（用DFD圖描述）和行為模型（也稱狀態(tài)模型，用STD圖描述）。

u實(shí)體聯(lián)系圖（E-R圖）：描述實(shí)體、屬性，以及實(shí)體之間的關(guān)系（如右圖）。

u ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數(shù)據(jù)流圖（Data Flow Diagram, DFD）從數(shù)據(jù)傳遞和加工的角度，描述系統(tǒng)內(nèi)各個(gè)部件的功能和數(shù)據(jù)在它們之間傳遞情況；

u狀態(tài)轉(zhuǎn)換圖（State Transform Diagram, STD）指出特定事件的結(jié)果將執(zhí)行哪些動作（如處理數(shù)據(jù)等），從而描述系統(tǒng)的狀態(tài)和引起系統(tǒng)狀態(tài)轉(zhuǎn)換的事件。

②面向?qū)ο蠓治龇椒ǎ∣OA）。OOA的基本任務(wù)是運(yùn)用OO的方法，對問題域進(jìn)行分析和理解，正確認(rèn)識其中的事物及它們之間的關(guān)系，找出描述問題域和系統(tǒng)功能所需的類和對象，定義它們的屬性和職責(zé)，以及它們之間所形成的各種聯(lián)系，最終產(chǎn)生一個(gè)符合用戶需求，并能直接反映問題域和系統(tǒng)功能的OOA模型及其詳細(xì)說明。其核心工作是建設(shè)系統(tǒng)的用例模型與分析模型。OOA模型獨(dú)立于具體實(shí)現(xiàn)，即不考慮與系統(tǒng)具體實(shí)現(xiàn)有關(guān)的因素，這也是OOA與OOD的區(qū)別所在?？梢哉fOOA的任務(wù)是“做什么”，OOD的任務(wù)是“怎么做”。該模型包括用例模型和分析模型。

u構(gòu)建“用例模型”步驟：識別參與者、合并需求獲得用例、細(xì)化用例描述、調(diào)整用例模型

u建立“分析模型”步驟：定義概念類、確定類之間的關(guān)系（UML的4種關(guān)系）、為類添加職責(zé)、建立交互圖等。其中前三個(gè)步驟可統(tǒng)稱為CRC[3]建模。

（4）需求文檔：軟件需求規(guī)格說明書（Software Requirement Specification，SRS）,一般包括范圍、引用文件、需求、合格性規(guī)定、需求可追蹤性、尚未解決的問題、注解、附錄。

（5）需求驗(yàn)證：驗(yàn)證方法是需求評審、需求測試。

[1] 注《計(jì)算機(jī)軟件文檔編制規(guī)范》(GB/T8567-2006)中將系統(tǒng)需求分為三大類：功能需求、業(yè)務(wù)需求（包括：接口、資源、性能、可靠性、安全性、保密性等）、數(shù)據(jù)需求。

[2] 意外需求，控制在開發(fā)人員手中，開發(fā)人員可以選擇實(shí)現(xiàn)更多的意外需求，以便得到高滿意、高忠誠度的用戶，也可以基于成本等考慮選擇不實(shí)現(xiàn)任何意外需求。

[3] CRC：Class-Responsibility-Collaborator，類-責(zé)任-協(xié)作者