需求分析
在具體的研究需求分析之前，我們先了解一下軟件工程這個(gè)概念。軟件工程分為三個(gè)層次，過(guò)程層、方法層、工具層。在最基礎(chǔ)的過(guò)程層，最重要的就是一組被稱為關(guān)鍵過(guò)程區(qū)域（KPAs）的框架（KPA的概念在討論CMM的書中有詳細(xì)的概念說(shuō)明）。關(guān)鍵過(guò)程區(qū)域構(gòu)成了軟件項(xiàng)目的管理控制的基礎(chǔ)，并且確立了上下文各區(qū)域的關(guān)系，其中規(guī)定了技術(shù)方法的采用、工程產(chǎn)品的，模型、文檔、數(shù)據(jù)、報(bào)告、表格等，等的產(chǎn)生、里程碑的建立、質(zhì)量的保證及變化的適當(dāng)管理。方法層主要是過(guò)程在技術(shù)上的實(shí)現(xiàn)。它解決的問(wèn)題是如何做。軟件工程方法涵蓋了一系列的任務(wù)：需求分析、設(shè)計(jì)、編程、測(cè)試、維護(hù)。同時(shí)他還包括了一組基本原則，控制了每一個(gè)的關(guān)鍵過(guò)程區(qū)域。工具層就很好理解了，他對(duì)過(guò)程層和方法層提供了自動(dòng)和半自動(dòng)的支持。這些輔助工具就稱為CASE。
可以看到需求分析的位置，但是事實(shí)上需求分析是跨越了軟件工程的三個(gè)層次的。這一點(diǎn)是和其他的過(guò)程是一樣的。當(dāng)然我們這里比較重點(diǎn)強(qiáng)調(diào)的是在軟件工程的方法層，同時(shí)也涉及到一些過(guò)程層的思想，至于工具層則不再我們的討論之列，但是會(huì)提到一些很適合在需求分
析時(shí)應(yīng)用的工具，諸如Word、Excel、Visio等。
方法
需求分析都包括了哪些方法呢？這里列舉出在《需求分析》一書中推薦的一些方法，
1) 繪制系統(tǒng)關(guān)聯(lián)圖，這種關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡(jiǎn)單模型。同時(shí)它也明確了通過(guò)接口的信息流和物質(zhì)流。
2) 創(chuàng)建用戶接口原型，當(dāng)開(kāi)發(fā)人員或用戶不能確定需求時(shí)，開(kāi)發(fā)一個(gè)用戶接口原型—一個(gè)可能的局部實(shí)現(xiàn)—這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過(guò)評(píng)價(jià)原型將使項(xiàng)目參與者能更好地相互理解所要解決的問(wèn)題。注意要找出需求文檔與原型之間所有的沖突之處。
3) 分析需求可行性，在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每
項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)，包括與其它需求的沖突，對(duì)外界因素的依賴和技術(shù)障礙。
4) 確定需求的優(yōu)先級(jí)別，應(yīng)用分析方法來(lái)確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)別。以優(yōu)先級(jí)為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。當(dāng)允許需求變更時(shí)，在特定的版本中加入每一項(xiàng)變更，并在那個(gè)版本計(jì)劃中作出需要的變更。
5) 為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說(shuō)明極好的補(bǔ)充說(shuō)明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對(duì)話框圖、對(duì)象類及交互作用圖。
6) 創(chuàng)建數(shù)據(jù)字典，數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開(kāi)發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確保客戶與開(kāi)發(fā)小組是使用一致的定義和術(shù)語(yǔ)。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。
7) 使用質(zhì)量功能調(diào)配，（QFD）是一種高級(jí)系統(tǒng)技術(shù)，它將產(chǎn)品特性、屬性與對(duì)客戶的重
要性聯(lián)系起來(lái)。該技術(shù)提供了一種分析方法以明確那些是客戶最為關(guān)注的特性。QFD將需求分為三類：期望需求，即客戶或許并未提及，但如若缺少會(huì)讓他們感到不滿意；普通需求；興奮需求，即實(shí)現(xiàn)了會(huì)給客戶帶去驚喜，但若未實(shí)現(xiàn)也不會(huì)受到責(zé)備（Zultner 1993;Pardee 1996）。
記住一點(diǎn)，不要試圖在你的項(xiàng)目中把這些方法都用上去，四個(gè)現(xiàn)代化并不是一夜就可以實(shí)現(xiàn)的。同樣，嘗試著使用你認(rèn)為對(duì)你很有幫助的方法，確實(shí)收到效果之后，在考慮繼續(xù)學(xué)習(xí)方法。因?yàn)樯厦嫣岬降亩际切枨蠓治龅拇蠓椒ǎ聦?shí)上還有很多很多的方法可以采用，例如，采用SRS模板、指明需求的來(lái)源、為每項(xiàng)需求注上標(biāo)號(hào)、記錄業(yè)務(wù)規(guī)范、創(chuàng)建需求跟蹤能力矩陣、審查需求文檔、以需求為依據(jù)編寫測(cè)試用例、編寫用戶手冊(cè)、確定合格的標(biāo)準(zhǔn)。
業(yè)務(wù)建模
很多人都沒(méi)有意識(shí)到業(yè)務(wù)需求階段應(yīng)該做些什么事情，實(shí)際上業(yè)務(wù)建模是最重要的一件事
情。不要覺(jué)得業(yè)務(wù)建模這個(gè)詞很深?yuàn)W，讓人模不著頭腦。其實(shí)所有做過(guò)需求分析的人都做過(guò)業(yè)務(wù)建模，比如你了解企業(yè)的運(yùn)作模式就是一種你腦海中的業(yè)務(wù)建模。但是大多數(shù)人都沒(méi)有科學(xué)的、系統(tǒng)的、文檔化的做過(guò)業(yè)務(wù)建模。
業(yè)務(wù)建模的目的在于：
了解目標(biāo)組織（將要在其中部署系統(tǒng)的組織）的結(jié)構(gòu)及機(jī)制。
了解目標(biāo)組織中當(dāng)前存在的問(wèn)題并確定改進(jìn)的可能性。
確保客戶、最終用戶和開(kāi)發(fā)人員就目標(biāo)組織達(dá)成共識(shí)。
導(dǎo)出支持目標(biāo)組織所需的業(yè)務(wù)需求。
上面的話是不是很抽象呢，其實(shí)沒(méi)有什么復(fù)雜的：人和電腦是完全不同的思想（思維方式）。所以，原先適合人的業(yè)務(wù)流程對(duì)于計(jì)算機(jī)來(lái)說(shuō)可不一定合適的，為了最大限度的利用計(jì)算機(jī)，必須要了解原先的業(yè)務(wù)流程并對(duì)此加易改造（流程自動(dòng)化），當(dāng)然這些動(dòng)作需要得到用戶的許可。有些人認(rèn)為說(shuō)只有ERP這種大系統(tǒng)才需要對(duì)業(yè)務(wù)流程進(jìn)行重組，但是
實(shí)際上，不論是部門級(jí)的MIS系統(tǒng)，還是社會(huì)級(jí)的電子商務(wù)系統(tǒng)，都需要對(duì)業(yè)務(wù)流程進(jìn)行改造，所不同的只是改造的程度。
業(yè)務(wù)建模很重要的一點(diǎn)是在分析企業(yè)流程的同時(shí)分析出基礎(chǔ)企業(yè)對(duì)象（Common Business Object）（這個(gè)詞我翻譯的不好，如果大家有更好的翻譯，請(qǐng)告訴我）。任何企業(yè)都有最基礎(chǔ)的一些元素，例如銀行的CBO就有帳戶，制造業(yè)的CBO就有訂單等。有一次我的一個(gè)在企業(yè)應(yīng)用方面研究多年的朋友告訴我一個(gè)秘訣，他說(shuō)，企業(yè)的CBO無(wú)非是4個(gè)：客戶、員工、產(chǎn)品和供應(yīng)商（銀行的供應(yīng)商應(yīng)該稱為同業(yè)）。其他的所有CBO都是在這四個(gè)CBO的基礎(chǔ)上發(fā)展起來(lái)的。比如說(shuō)CBO中客戶和產(chǎn)品是多對(duì)多的關(guān)系，根據(jù)關(guān)系數(shù)據(jù)的理論，任何多對(duì)多的關(guān)系都可以拆分成多個(gè)一對(duì)多或一對(duì)一的關(guān)系。你就可以在這兩個(gè)類之間引入訂單類，客戶和訂單之間是一對(duì)多，訂單和產(chǎn)品之間又是一對(duì)多，這樣一個(gè)多對(duì)多的關(guān)系就拆分成兩個(gè)一對(duì)多的關(guān)系，而新的訂單類也就順理成章的產(chǎn)生了。在訂單類產(chǎn)生時(shí)，你可能還會(huì)加入一個(gè)關(guān)聯(lián)類：業(yè)務(wù)員類。而業(yè)務(wù)員類又是從員工類繼承下來(lái)的。所以呢，企業(yè)的四種CBO通過(guò)不同的組合，不同的關(guān)系，能夠形成企業(yè)運(yùn)作的許許多多的CBO。
CBO是做業(yè)務(wù)建模的基礎(chǔ)，在此基礎(chǔ)上，通過(guò)評(píng)估業(yè)務(wù)狀態(tài)，說(shuō)明當(dāng)前業(yè)務(wù)，確定業(yè)務(wù)流
程，改進(jìn)業(yè)務(wù)流程的定義，設(shè)計(jì)業(yè)務(wù)流程實(shí)現(xiàn)，改進(jìn)角色和職責(zé)，研究流程自動(dòng)化，開(kāi)發(fā)領(lǐng)域模型等一系列在RUP中定義的工作流程實(shí)現(xiàn)業(yè)務(wù)建模的目標(biāo)。
需求獲取
需求獲取(requirement elicitation)是需求工程的主體。對(duì)于所建議的軟件產(chǎn)品，獲取需求是一個(gè)確定和理解不同用戶類的需要和限制的過(guò)程。獲取用戶需求位于軟件需求三個(gè)層次的中間一層。業(yè)務(wù)需求決定用戶需求，它描述了用戶利用系統(tǒng)需要完成的任務(wù)。從這些任務(wù)中，分析者能獲得用于描述系統(tǒng)活動(dòng)的特定的軟件功能需求，這些系統(tǒng)活動(dòng)有助于用戶執(zhí)行他們的任務(wù)。
需求獲取是在問(wèn)題及其最終解決方案之間架設(shè)橋梁的第一步。獲取需求的一個(gè)必不可少的結(jié)果是對(duì)項(xiàng)目中描述的客戶需求的普遍理解。一旦理解了需求，分析者、開(kāi)發(fā)者和客戶就能探索出描述這些需求的多種解決方案。參與需求獲取者只有在他們理解了問(wèn)題之后才能開(kāi)始設(shè)計(jì)系統(tǒng)，否則，對(duì)需求定義的任何改進(jìn)，設(shè)計(jì)上都必須大量的返工。把需求獲取集
中在用戶任務(wù)上—而不是集中在用戶接口上—有助于防止開(kāi)發(fā)組由于草率處理設(shè)計(jì)問(wèn)題而造成的失誤。
需求獲取、分析、編寫需求規(guī)格說(shuō)明和驗(yàn)證并不遵循線性的順序，這些活動(dòng)是相互隔開(kāi)、增量和反復(fù)的。當(dāng)你和客戶合作時(shí)，你就將會(huì)問(wèn)一些問(wèn)題，并且取得他們所提供的信息（需求獲取）。同時(shí)，你將處理這些信息以理解它們，并把它們分成不同的類別，還要把客戶需求同可能的軟件需求相聯(lián)系（分析）。然后，你可以使客戶信息結(jié)構(gòu)化，并編寫成文檔和示意圖（說(shuō)明）。下一步，就可以讓客戶代表評(píng)審文檔并糾正存在的錯(cuò)誤（驗(yàn)證）。這四個(gè)過(guò)程貫穿著需求分析的整個(gè)階段。
需求獲取可能是軟件開(kāi)發(fā)中最困難、最關(guān)鍵、最易出錯(cuò)及最需要交流的方面。需求獲取只有通過(guò)有效的客戶—開(kāi)發(fā)者的合作才能成功。分析者必須建立一個(gè)對(duì)問(wèn)題進(jìn)行徹底探討的環(huán)境，而這些問(wèn)題與產(chǎn)品有關(guān)。為了方便清晰地進(jìn)行交流，就要列出重要的小組，而不是假想所有的參與者都持有相同的看法。對(duì)需求問(wèn)題的全面考察需要一種技術(shù)，利用這種技術(shù)不但考慮了問(wèn)題的功能需求方面，還可討論項(xiàng)目的非功能需求。確定用戶已經(jīng)理解：對(duì)
于某些功能的討論并不意味著即將在產(chǎn)品中實(shí)現(xiàn)它。對(duì)于想到的需求必須集中處理并設(shè)定優(yōu)先級(jí)，以避免一個(gè)不能帶來(lái)任何益處的無(wú)限大的項(xiàng)目。
需求獲取是一個(gè)需要高度合作的活動(dòng)，而并不是客戶所說(shuō)的需求的簡(jiǎn)單謄本。作為一個(gè)分析者，你必須透過(guò)客戶所提出的表面需求理解他們的真正需求。詢問(wèn)一個(gè)可擴(kuò)充（open-ended）的問(wèn)題有助于你更好地理解用戶目前的業(yè)務(wù)過(guò)程并且知道新系統(tǒng)如何幫助或改進(jìn)他們的工作。調(diào)查用戶任務(wù)可能遇到的變更，或者用戶需要使用系統(tǒng)其它可能的方式。想像你自己在學(xué)習(xí)用戶的工作，你需要完成什么任務(wù)？你有什么問(wèn)題？從這一角度來(lái)指導(dǎo)需求的開(kāi)發(fā)和利用。
還有，探討例外的情況：什么會(huì)妨礙用戶順利完成任務(wù)？對(duì)系統(tǒng)錯(cuò)誤情況的反映，用戶是如何想的？詢問(wèn)問(wèn)題時(shí)，以“還有什么能” ,”當(dāng)?時(shí)，將會(huì)發(fā)生什么”“你有沒(méi)有曾經(jīng)想過(guò)” ,“有沒(méi)有人曾經(jīng)”為開(kāi)頭。記下每一個(gè)需求的來(lái)源，這樣向下跟蹤直到發(fā)現(xiàn)特定的客戶。
有些時(shí)候，嘗試著問(wèn)一些“愚蠢”的問(wèn)題也有助于客戶打開(kāi)話匣子。如果你直接要求客戶寫
出業(yè)務(wù)是如何實(shí)現(xiàn)的，客戶十有八九無(wú)法完成。但是如果你嘗試著問(wèn)一些實(shí)際的問(wèn)題，例如：“以我的理解，你們收到訂單后，會(huì)...”。客戶立刻就會(huì)指出你的錯(cuò)誤，并滔滔不絕的開(kāi)始談?wù)摌I(yè)務(wù)，而你，就在一邊仔細(xì)的聆聽(tīng)吧。這一招就叫做“拋磚引玉”。
需求討論會(huì)上必須要使用筆記本電腦，還要指定一個(gè)打字熟練的人把所有的討論記錄下來(lái)，記錄的同時(shí)還要做一定的整理。如果不這樣做，那么你結(jié)束會(huì)議的時(shí)候就會(huì)發(fā)現(xiàn)，所有的討論只剩下一個(gè)模糊的印象，需求對(duì)你來(lái)說(shuō)仍然是一件遙遠(yuǎn)的事情。在座談?dòng)懻撝螅浵滤懻摰臈l目(item)，并請(qǐng)參與討論的用戶評(píng)論并更正。及早并經(jīng)常進(jìn)行座談?dòng)懻撌切枨螳@取成功的一個(gè)關(guān)鍵途徑，因?yàn)橹挥刑峁┬枨蟮娜瞬拍艽_定是否真正獲取需求。進(jìn)行深入收集和分析以消除任何沖突或不一致性。
盡量把客戶所持的假設(shè)解釋清楚，特別是那些發(fā)生沖突的部分。從字里行間去理解以明確客戶沒(méi)有表達(dá)清楚但又想加入的特性或特征。Gau 和Weinberg（1989）提出使用“上下文無(wú)關(guān)問(wèn)題”—這是一個(gè)高層次的問(wèn)題，它可以獲取業(yè)務(wù)問(wèn)題和可能的解決方案的全部信息。客戶對(duì)這些問(wèn)題的回答諸如“產(chǎn)品要求怎樣的精確度”或“你能幫我解釋一下你為什么不
同意某人的回答嗎？”這些回答可以更直接地認(rèn)識(shí)問(wèn)題，而這是封閉（clo-end）問(wèn)題所不能做到的。
需求獲取利用了所有可用的信息來(lái)源，這些信息描述了問(wèn)題域或在軟件解決方案中合理的特性。一個(gè)研究表明：比起不成功的項(xiàng)目，一個(gè)成功的項(xiàng)目在開(kāi)發(fā)者和客戶之間采用了更多的交流方式（Kiel and Carmel 1995）。與單個(gè)客戶或潛在的用戶組一起座談，對(duì)于業(yè)務(wù)軟件包或信息管理系統(tǒng)（MIS）的應(yīng)用來(lái)說(shuō)是一種傳統(tǒng)的需求來(lái)源。直接聘請(qǐng)用戶進(jìn)行獲取需求的過(guò)程是為項(xiàng)目獲得支持和買入（buy-in）的一種方式。
盡量理解用戶用于表述他們需求的思維過(guò)程。充分研究用戶執(zhí)行任務(wù)時(shí)作出決策的過(guò)程，并提取出潛在的邏輯關(guān)系。流程圖和決策樹(shù)是描述這些邏輯決策途徑的好方法。
在需求獲取的過(guò)程中，你可能會(huì)發(fā)現(xiàn)對(duì)項(xiàng)目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業(yè)務(wù)和客戶的值，此時(shí)獲取過(guò)程將會(huì)拖延。如果項(xiàng)目范圍太小，那么客戶將會(huì)提出很重要的但又在當(dāng)前產(chǎn)品范圍之
外的需求。當(dāng)前的范圍太小，以致不能提供一個(gè)令人滿意的產(chǎn)品。需求的獲取將導(dǎo)致修改項(xiàng)目的范圍和任務(wù)，但作出這樣具有深遠(yuǎn)影響的改變，一定要小心謹(jǐn)慎。
正如經(jīng)常所說(shuō)的，需求主要是關(guān)于系統(tǒng)做什么，而解決方案如何實(shí)現(xiàn)是屬于設(shè)計(jì)的范圍。這樣說(shuō)雖然很簡(jiǎn)潔，但似乎過(guò)于簡(jiǎn)單化。需求的獲取應(yīng)該把重點(diǎn)放在“做什么”上，但在分析和設(shè)計(jì)之間還是存在一定的距離。你可以使用假設(shè)“怎么做”來(lái)分類并改善你對(duì)用戶需求的理解。在需求的獲取過(guò)程中，分析模型、屏幕圖形和原型可以使概念表達(dá)得更加清楚，然后提供一個(gè)尋找錯(cuò)誤和遺漏的辦法。把你在需求開(kāi)發(fā)階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應(yīng)該看成是對(duì)設(shè)計(jì)者選擇的一種限制。
需求獲取討論會(huì)中如果參與者過(guò)多，就會(huì)減慢進(jìn)度。人數(shù)大致控制在5到7人是最好的。這些人包括客戶、系統(tǒng)設(shè)計(jì)者、開(kāi)發(fā)者和可視化設(shè)計(jì)者等主要工程角色。相反地，從極少的代表那里收集信息或者只聽(tīng)到呼聲最高、最有輿論影響的用戶的聲音，也會(huì)造成問(wèn)題。這將導(dǎo)致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數(shù)用戶的需要。最好的權(quán)衡在于選擇一些授權(quán)為他們的用戶類發(fā)言的產(chǎn)品代表者，他們也被同組用戶類的其它代表所支持。
沒(méi)有一個(gè)簡(jiǎn)單、清楚的信號(hào)暗示你什么時(shí)候已完成需求獲取。當(dāng)客戶和開(kāi)發(fā)者與他們的同事聊天、閱讀工業(yè)和商業(yè)上的文獻(xiàn)及在早上沐浴時(shí)思考時(shí)，他們都將對(duì)潛在產(chǎn)品產(chǎn)生新的構(gòu)思。你不可能全面收集需求，但是下列的提示將會(huì)暗示你在需求獲取的過(guò)程中的返回點(diǎn)。
1. 如果用戶不能想出更多的使用實(shí)例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來(lái)確定使用實(shí)例的。
2. 如果用戶提出新的使用實(shí)例，但你可以從其它使用實(shí)例的相關(guān)功能需求中獲得這些新的使用實(shí)例，這時(shí)也許你就完成了收集需求的工作。這些新的使用實(shí)例可能是你已獲取的其它使用實(shí)例的可選過(guò)程。
3. 如果用戶開(kāi)始重復(fù)原先討論過(guò)的問(wèn)題，此時(shí)，也許你就完成了收集需求的工作。
4. 如果所提出的新需求比你已確定的需求的優(yōu)先級(jí)都低時(shí)，也許你就完成了收集需求的工
作。
5. 如果用戶提出對(duì)將來(lái)產(chǎn)品的要求，而不是現(xiàn)在我們討論的特定產(chǎn)品，也許你就完成了收集需求的工作。
以上知識(shí)大致上討論需求分析應(yīng)該如何做，實(shí)際上對(duì)于需求分析的方法有很多很多，已經(jīng)形成了一定的理論，當(dāng)然這種理論比較偏向與方法學(xué)，而方法學(xué)的應(yīng)用主要還是要靠個(gè)人。所以，大家在實(shí)際應(yīng)用的時(shí)候，不妨結(jié)合自己的實(shí)際，有選擇性的采用一些方法，那你就是成功的。
