測試需求分析概述軟件工程分為三個(gè)層次，過(guò)程層、方法層、工具層。在最基礎的過(guò)程層，最重要的就是一組被稱(chēng)為關(guān)鍵過(guò)程區域（KPAs）的框架（KPA的概念在討論CMM的書(shū)中有詳細的概念說(shuō)明）。關(guān)鍵過(guò)程區域構成了軟件項目的管理控制的基礎，并且確立了上下文各區域的關(guān)系，其中規定了技術(shù)方法的采用、工程產(chǎn)品的，模型、文檔、數據、報告、表格等，等的產(chǎn)生、里程碑的建立、質(zhì)量的保證及變化的適當管理。方法層主要是過(guò)程在技術(shù)上的實(shí)現。它解決的問(wèn)題是如何做。軟件工程方法涵蓋了一系列的任務(wù)：需求分析、設計、編程、測試、維護。同時(shí)他還包括了一組基本原則，控制了每一個(gè)的關(guān)鍵過(guò)程區域。工具層就很好理解了，他對過(guò)程層和方法層提供了自動(dòng)和半自動(dòng)的支持。這些輔助工具就稱(chēng)為CASE。
可以看到需求分析的位置，但是事實(shí)上需求分析是跨越了軟件工程的三個(gè)層次的。這一點(diǎn)是和其他的過(guò)程是一樣的。當然我們這里比較重點(diǎn)強調的是在軟件工程的方法層，同時(shí)也涉及到一些過(guò)程層的思想，至于工具層則不再我們的討論之列，但是會(huì )提到一些很適合在需求分析時(shí)應用的工具，諸如Word、Excel、Visio等。
需求分析都包括了哪些方法呢？這里列舉出在《需求分析》一書(shū)中推薦的一些方法，
1. 繪制系統關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統與系統外部實(shí)體間的界限和接口的簡(jiǎn)單模型。同時(shí)它也明確了通過(guò)接口的信息流和物質(zhì)流。
2. 創(chuàng )建用戶(hù)接口原型，當開(kāi)發(fā)人員或用戶(hù)不能確定需求時(shí)，開(kāi)發(fā)一個(gè)用戶(hù)接口原型—一個(gè)可能的局部實(shí)現—這樣使得許多概念和可能發(fā)生的事更為直觀(guān)明了。用戶(hù)通過(guò)評價(jià)原型將使項目參與者能更好地相互理解所要解決的問(wèn)題。注意要找出需求文檔與原型之間所有的沖突之處。
3. 分析需求可行性，在允許的成本、性能要求下，分析每項需求實(shí)施的可行性，明確與每項需求實(shí)現相聯(lián)系的風(fēng)險，包括與其它需求的沖突，對外界因素的依賴(lài)和技術(shù)障礙。
4. 確定需求的優(yōu)先級別，應用分析方法來(lái)確定使用實(shí)例、產(chǎn)品特性或單項需求實(shí)現的優(yōu)先級別。以?xún)?yōu)先級為基礎確定產(chǎn)品版本將包括哪些特性或哪類(lèi)需求。當允許需求變更時(shí)，在特定的版本中加入每一項變更，并在那個(gè)版本計劃中作出需要的變更。
5. 為需求建立模型，需求的圖形分析模型是軟件需求規格說(shuō)明極好的補充說(shuō)明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數據流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對話(huà)框圖、對象類(lèi)及交互作用圖。
6. 創(chuàng )建數據字典，數據字典是對系統用到的所有數據項和結構的定義，以確保開(kāi)發(fā)人員使用統一的數據定義。在需求階段，數據字典至少應定義客戶(hù)數據項以確?？蛻?hù)與開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。分析和設計工具通常包括數據字典組件。
7. 使用質(zhì)量功能調配，（QFD）是一種高級系統技術(shù)，它將產(chǎn)品特性、屬性與對客戶(hù)的重要性聯(lián)系起來(lái)。該技術(shù)提供了一種分析方法以明確那些是客戶(hù)最為關(guān)注的特性。QFD將需求分為三類(lèi)：期望需求，即客戶(hù)或許并未提及，但如若缺少會(huì )讓他們感到不滿(mǎn)意；普通需求；興奮需求，即實(shí)現了會(huì )給客戶(hù)帶去驚喜，但若未實(shí)現也不會(huì )受到責備（Zultner 1993;Pardee 1996）。
記住一點(diǎn)，不要試圖在你的項目中把這些方法都用上去，四個(gè)現代化并不是一夜就可以實(shí)現的。同樣，嘗試著(zhù)使用你認為對你很有幫助的方法，確實(shí)收到效果之后，在考慮繼續學(xué)習方法。因為上面提到的都是需求分析的大方法，事實(shí)上還有很多很多的方法可以采用，例如，采用SRS模板、指明需求的來(lái)源、為每項需求注上標號、記錄業(yè)務(wù)規范、創(chuàng )建需求跟蹤能力矩陣、審查需求文檔、以需求為依據編寫(xiě)測試用例、編寫(xiě)用戶(hù)手冊、確定合格的標準。
很多人都沒(méi)有意識到業(yè)務(wù)需求階段應該做些什么事情，實(shí)際上業(yè)務(wù)建模是最重要的一件事情。不要覺(jué)得業(yè)務(wù)建模這個(gè)詞很深奧，讓人模不著(zhù)頭腦。其實(shí)所有做過(guò)需求分析的人都做過(guò)業(yè)務(wù)建模，比如你了解企業(yè)的運作模式就是一種你腦海中的業(yè)務(wù)建模。但是大多數人都沒(méi)有科學(xué)的、系統的、文檔化的做過(guò)業(yè)務(wù)建模。
業(yè)務(wù)建模的目的在于：
1.了解目標組織（將要在其中部署系統的組織）的結構及機制。
2.了解目標組織中當前存在的問(wèn)題并確定改進(jìn)的可能性。
3.確?？蛻?hù)、最終用戶(hù)和開(kāi)發(fā)人員就目標組織達成共識。
4.導出支持目標組織所需的業(yè)務(wù)需求。
上面的話(huà)是不是很抽象呢，其實(shí)沒(méi)有什么復雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業(yè)務(wù)流程對于計算機來(lái)說(shuō)可不一定合適的，為了最大限度的利用計算機，必須要了解原先的業(yè)務(wù)流程并對此加易改造（流程自動(dòng)化），當然這些動(dòng)作需要得到用戶(hù)的許可。有些人認為說(shuō)只有ERP這種大系統才需要對業(yè)務(wù)流程進(jìn)行重組，但是實(shí)際上，不論是部門(mén)級的MIS系統，還是社會(huì )級的電子商務(wù)系統，都需要對業(yè)務(wù)流程進(jìn)行改造，所不同的只是改造的程度。
業(yè)務(wù)建模很重要的一點(diǎn)是在分析企業(yè)流程的同時(shí)分析出基礎企業(yè)對象（Common Business Object）（這個(gè)詞我翻譯的不好，如果大家有更好的翻譯，請告訴我）。任何企業(yè)都有最基礎的一些元素，例如銀行的CBO就有帳戶(hù)，制造業(yè)的CBO就有訂單等。有一次我的一個(gè)在企業(yè)應用方面研究多年的朋友告訴我一個(gè)秘訣，他說(shuō)，企業(yè)的CBO無(wú)非是4個(gè)：客戶(hù)、員工、產(chǎn)品和供應商（銀行的供應商應該稱(chēng)為同業(yè)）。其他的所有CBO都是在這四個(gè)CBO的基礎上發(fā)展起來(lái)的。比如說(shuō)CBO中客戶(hù)和產(chǎn)品是多對多的關(guān)系，根據關(guān)系數據的理論，任何多對多的關(guān)系都可以拆分成多個(gè)一對多或一對一的關(guān)系。你就可以在這兩個(gè)類(lèi)之間引入訂單類(lèi)，客戶(hù)和訂單之間是一對多，訂單和產(chǎn)品之間又是一對多，這樣一個(gè)多對多的關(guān)系就拆分成兩個(gè)一對多的關(guān)系，而新的訂單類(lèi)也就順理成章的產(chǎn)生了。在訂單類(lèi)產(chǎn)生時(shí)，你可能還會(huì )加入一個(gè)關(guān)聯(lián)類(lèi)：業(yè)務(wù)員類(lèi)。而業(yè)務(wù)員類(lèi)又是從員工類(lèi)繼承下來(lái)的。所以呢，企業(yè)的四種CBO通過(guò)不同的組合，不同的關(guān)系，能夠形成企業(yè)運作的許許多多的CBO。 CBO是做業(yè)務(wù)建模的基礎，在此基礎上，通過(guò)評估業(yè)務(wù)狀態(tài)，說(shuō)明當前業(yè)務(wù)，確定業(yè)務(wù)流程，改進(jìn)業(yè)務(wù)流程的定義，設計業(yè)務(wù)流程實(shí)現，改進(jìn)角色和職責，研究流程自動(dòng)化，開(kāi)發(fā)領(lǐng)域模型等一系列在RUP中定義的工作流程實(shí)現業(yè)務(wù)建模的目標。
