軟件需求分析主要方法問(wèn)題(軟件需求的分析方法)
1.軟件需求的分析方法
軟件需求分析方法大體分為如下四類(lèi)：結構化方法、面向對象方法、面向控制方法和面向數據方法。限于篇幅，將主要從結構化方法和面向對象方法以及RUP三個(gè)方面進(jìn)行簡(jiǎn)要的探討。 面向對象（Object Oriented, OO）的方法把分析建立在系統對象以及對象間交互的基礎之上，使得我們能以3個(gè)最基本的方法框架——對象及其屬性、分類(lèi)結構和集合結構來(lái)定義和溝通需求。面向對象的問(wèn)題分析模型從3個(gè)側面進(jìn)行描述，即對象模型（對象的靜態(tài)結構）、動(dòng)態(tài)模型（對象相互作用的順序）和功能模型（數據變換及功能依存關(guān)系）。需求工程的抽象原則、層次原則和分割原則同樣適用于面向對象方法，即對象抽象與功能抽象原則是一樣的，也是從高級到低級、從邏輯到物理，逐級細分.每一級抽象都重復對象建模（對象識別）一動(dòng)態(tài)建模（事件識別）一功能建模（操作識別）的過(guò)程，直到每一個(gè)對象實(shí)例在物理（程序編碼）上全部實(shí)現為止。
面向對象需求分析（OORA）利用一些基本概念來(lái)建立相應模型，以表達目標系統的不同側面。盡管不同的方法所采用的具體模型不盡相同，但都無(wú)外乎用如下五個(gè)基本模型來(lái)描述軟件需求：
整體—部分模型：該模型描述對象（類(lèi)）是如何由簡(jiǎn)單的對象（類(lèi)）構成的。將一個(gè)復雜對象（類(lèi)）描述成一個(gè)由交互作用的若干對象（類(lèi)）構成的結構的能力是OO途徑的突出優(yōu)點(diǎn)。該模型亦稱(chēng)聚合模型。
分類(lèi)模型：分類(lèi)模型描述類(lèi)之間的繼承關(guān)系。與聚合關(guān)系不同，它說(shuō)明的是一個(gè)類(lèi)可以繼承另一個(gè)或另一些類(lèi)的成分，以實(shí)現類(lèi)中成分的復用。
類(lèi)—對象模型：分析過(guò)程必須描述屬于每個(gè)類(lèi)的對象所具有的行為，這種行為描述的詳細程度可以根據具體情況而定。既可以只說(shuō)明行為的輸入、輸出和功能，也可以采用比較形式的途徑來(lái)精確地描述其輸入、輸出及其相應的類(lèi)型甚至使用偽碼或小說(shuō)明的形式來(lái)詳細刻畫(huà)。
對象交互模型：一個(gè)面向對象的系統模型必須描述其中對象的交互方法。如前所述，對象交互是通過(guò)消息傳遞來(lái)實(shí)現的。事實(shí)人對象交互也可看作是對象行為之間的引用關(guān)系。因此，對象交互模型就要刻畫(huà)對象之間的消息流。對應于不同的詳細程度，有不同的消息流描述分析，分析人員應根據具體館況而選擇。一般地，一個(gè)詳細的對象交互模型能夠說(shuō)明對象之間的消息及其流向，并且同時(shí)說(shuō)明該消息將激活的對象及行為。一個(gè)不太詳細的對象交互模型可以只說(shuō)明對象之間有消息，并指明其流向即可。還有一種狀況就是介于此兩者之間。
狀態(tài)模型：在狀態(tài)模型中，把一個(gè)對象看作是一個(gè)有限狀態(tài)機，由一個(gè)狀態(tài)到另一狀態(tài)的轉變稱(chēng)作狀態(tài)轉換。狀態(tài)模型將對象的行為描述成其不同狀態(tài)之間的通路。它也可以刻畫(huà)動(dòng)態(tài)系統中對象的創(chuàng )建和廢除，并稱(chēng)由對象的創(chuàng )建到對象的廢除狀態(tài)之間的退路為對象的生存期。
狀態(tài)模型既可以用狀態(tài)轉換因的圖形化手段，又可用決策表或稱(chēng)決策矩陣的形式來(lái)表。 RUP(Rational Unified Process)是Rational公司開(kāi)發(fā)和維護的過(guò)程產(chǎn)品。RUP是工程化的軟件開(kāi)發(fā)過(guò)程，它提供了在開(kāi)發(fā)機構中分派任務(wù)和責任的紀律化方法。RUP不僅僅是一個(gè)簡(jiǎn)單的過(guò)程，而是一個(gè)通用的過(guò)程框架，可用于各種不同類(lèi)型的軟件系統、各種不同的應用領(lǐng)域、各種不同類(lèi)型的組織、各種不同的功能級別以及各種不同的項目規模。RUP的突出特點(diǎn)可以由以下三個(gè)關(guān)鍵詞來(lái)體現——用例驅動(dòng)、以構架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構架提供了一種結構來(lái)指導迭代過(guò)程中的工作，而用例則確定了目標井驅動(dòng)每次迭代的工作。
進(jìn)行需求分析的基礎是要獲得用戶(hù)的需要，為了完成這一工作，必須建立業(yè)務(wù)模型，通過(guò)描述業(yè)務(wù)規則、業(yè)務(wù)邏輯，明確業(yè)務(wù)過(guò)程并對其進(jìn)行規范、優(yōu)化。對于一個(gè)系統，在建立業(yè)務(wù)模型時(shí)，應從3個(gè)方面來(lái)描述其特性：功能、行為、數據，對應于這些特性。 基于上述分析可知，結構化分析方法與面向對象分析方法的區別主要體現在兩個(gè)方面：
* 將系統分解成于系統的方式不同。前者將系統描述成一組交互作用的處理，后者則描述成一組交互作用的對象。
* 子系統之間的交互關(guān)系的描述方式不一樣。前者加工之間的交互是通過(guò)不太精確的數據流來(lái)表示的，而后者對象之間通過(guò)消息傳遞交互關(guān)系。
因此，面向對象軟件需求分析的結果能更好地刻畫(huà)現實(shí)世界，處理復雜問(wèn)題，對象比過(guò)程更具有穩定性，便于維護與復用。
2.需求分析有哪些方法
三種需求分析的方法：結構化分析方法、面向對象的分析方法、面向問(wèn)題域的分析方法。
結構化的分析方法是傳統的分析法，它的好處是在需求階段可以不需要精確地定義系統，只需要根據業(yè)務(wù)框架確定系統的功能范圍，以及每個(gè)功能的處理邏輯和業(yè)務(wù)規則，功能需求規格書(shū)等。因為不需要精確描述，因此描述系統的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來(lái)描述系統。在系統開(kāi)發(fā)以前，一般還可以采用更為直觀(guān)的原型系統方式和最終用戶(hù)進(jìn)行交流和確認，因此對業(yè)務(wù)需求的要求會(huì )低一些，業(yè)務(wù)需求階段的周期相對容易控制；通過(guò)業(yè)務(wù)全景圖，最終用戶(hù)也能了解系統的功能；通過(guò)功能活動(dòng)圖和業(yè)務(wù)規則的描述，也可以相對精確地描述業(yè)務(wù)系統；因為沒(méi)有嚴格的標記語(yǔ)言，可以采用適當的篇幅描述適當的系統。當然，這種方法的缺點(diǎn)也是明顯的，分析人員和業(yè)務(wù)人員之間可能缺乏共同語(yǔ)言，機器不能識別業(yè)務(wù)需求書(shū)，在設計階段還需要繼續和用戶(hù)確認一部分功能。
面向對象的分析方法的最大好處是在需求階段，就能夠非常精確地描述一個(gè)系統，采用程序語(yǔ)言的方式和最終用戶(hù)交流（最終用戶(hù)必須要熟悉這種語(yǔ)言），能夠在項目一開(kāi)始就發(fā)現很多問(wèn)題，避免在開(kāi)發(fā)的過(guò)程中出現需求的反復，而且在系統設計和開(kāi)發(fā)階段不需要最終用戶(hù)參與。在實(shí)施上，一般可以采用場(chǎng)景、業(yè)務(wù)功能等方式來(lái)描述，比較適合于業(yè)務(wù)流程環(huán)節多的系統，或者軟件產(chǎn)品的開(kāi)發(fā)。但是，我們也要看到，在現實(shí)中，絕大多數的應用系統都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點(diǎn)和困難也是顯而易見(jiàn)的：首先，用戶(hù)要非常清楚地知道最終的業(yè)務(wù)系統應該是什么樣，或者采用一種抽象的方式能夠確定最終的應用系統；其次，因為最終用戶(hù)不需要參與設計和開(kāi)發(fā)階段的工作，所以雙方確定業(yè)務(wù)需求的過(guò)程也會(huì )比較長(cháng)；同時(shí)，因為是精確描述，因此描述系統的語(yǔ)言是非常邏輯化的，一般通過(guò)某種方式可以使機器識別業(yè)務(wù)需求，采用這種方式寫(xiě)的業(yè)務(wù)需求是非常格式化的，一方面描述一個(gè)系統需要的信息非常多，可能使需求說(shuō)明的篇幅非常長(cháng)，不便于理解和閱讀；另外由于通過(guò)抽象的方式來(lái)推演最終系統的運行方式，對業(yè)務(wù)人員的要求非常高。
3.軟件需求分析在軟件工程中的作用,有哪些軟件需求分析的方法
軟件工程中包含需求、設計、編碼和測試四個(gè)階段，其中需求工程是軟件工程第一個(gè)也是很重要的一個(gè)階段，需求分析是要決定“做什么，不做什么”。
在一個(gè)軟件項目中，軟件需求包括三個(gè)不同的層次-業(yè)務(wù)需求、用戶(hù)需求和功能需求-也包括非功能需求：業(yè)務(wù)需說(shuō)明了提供給客戶(hù)和產(chǎn)品開(kāi)發(fā)商的新系統的最初利益，反映了組織機構或客戶(hù)對系統、產(chǎn)品高層次的目標要求。
軟件開(kāi)發(fā)，能否獲得成功，最重要的是需求分析的工作。因此，軟件需求分析能力和水平，對軟件項目至關(guān)重要。
一般的分析方法和步驟如下：
⑴首先調查組織機構情況 包括了解該組織的部門(mén)組成情況，各部門(mén)的職能等，為分析信息流程作準備。
⑵然后調查各部門(mén)的業(yè)務(wù)活動(dòng)情況 包括了解各個(gè)部門(mén)輸入和使用什么數據，如何加工處理這些數據，輸出什么信息，輸出到什么部門(mén)，輸出結果的格式是什么。
⑶協(xié)助用戶(hù)明確對新系統的各種要求 包括信息要求、處理要求、完全性與完整性要求。
⑷確定新系統的邊界 確定哪些功能由計算機完成或將來(lái)準備讓計算機完成，哪些活動(dòng)由人工完成。由計算機完成的功能就是新系統應該實(shí)現的功能。
常用的調查方法有：
⑴跟班作業(yè) 通過(guò)親身參加業(yè)務(wù)工作來(lái)了解業(yè)務(wù)活動(dòng)的情況。這種方法可以比較準確地理解用戶(hù)的需求，但比較耗費時(shí)間。
⑵開(kāi)調查會(huì ) 通過(guò)與用戶(hù)座談來(lái)了解業(yè)務(wù)活動(dòng)情況及用戶(hù)需求。座談時(shí)，參加者之間可以相互啟發(fā)。
⑶請專(zhuān)人介紹。
⑷詢(xún)問(wèn) 對某些調查中的問(wèn)題，可以找專(zhuān)人詢(xún)問(wèn)。
⑸設計調查表請用戶(hù)填寫(xiě) 如果調查表設計得合理，這種方法是很有效，也很易于為用戶(hù)接受的。
⑹查閱記錄 即查閱與原系統有關(guān)的數據記錄，包括原始單據、賬簿、報表等。 通過(guò)調查了解了用戶(hù)需求后，還需要進(jìn)一步分析和表達用戶(hù)的需求。分析和表達用戶(hù)需求的方法主要包括自頂向下和自底向上兩類(lèi)方法。
4.軟件工程中常用的需求分析的方法有哪些
一、過(guò)濾需求的方法做后端系統，要學(xué)會(huì )的第一個(gè)技能就是砍需求。
也就是過(guò)濾需求。這不是一個(gè)貶義詞，反而是體現后端產(chǎn)品價(jià)值判斷的基礎。
過(guò)濾需求的方法，就是通過(guò)一定的手段判斷需求是否是偽需求，應該被過(guò)濾掉。1. 用戶(hù)場(chǎng)景模擬法后端產(chǎn)品的出發(fā)點(diǎn)就是幫助業(yè)務(wù)用戶(hù)，因此在調研需求的時(shí)候要模擬業(yè)務(wù)的場(chǎng)景，分析業(yè)務(wù)用戶(hù)提到的需求是否能解決他的問(wèn)題。
如果不能幫助用戶(hù)，那么這個(gè)需求就可能是偽需求。以下面的案例說(shuō)明：背景：“貨到付款”類(lèi)型的訂單會(huì )因為缺貨而無(wú)法發(fā)出，如果超過(guò)一定的時(shí)間，客服就會(huì )跟顧客溝通，幫顧客取消訂單。
需求：由于這種訂單的數量還是蠻多的，逐個(gè)取消太費時(shí)間，因此業(yè)務(wù)用戶(hù)要求在“缺貨訂單”列表頁(yè)增加“批量取消訂單”按鈕。分析：調研到業(yè)務(wù)操作場(chǎng)景，是先找到該類(lèi)缺貨訂單，然后和顧客溝通，顧客同意刪除，才進(jìn)行刪除。
也就是逐個(gè)溝通確認，再逐個(gè)取消訂單的，所以“批量取消訂單”無(wú)法被有效使用。因此，該需求是個(gè)偽需求，應該被過(guò)濾掉。
2. 功能歸屬分析專(zhuān)門(mén)的系統做專(zhuān)職功能，有助于合理的產(chǎn)品體系建設。因此需求調研的時(shí)候，可以通過(guò)系統的定位，判斷需求是否應該在該系統完成。
如果不屬于該系統范疇，那么直接說(shuō)服需求方更換方案。以下面的案例說(shuō)明：背景：CRM系統（顧客關(guān)系管理系統）有一個(gè)顧客標簽生成功能，就是根據顧客的消費行為數據，自動(dòng)對應關(guān)聯(lián)上標簽，如優(yōu)質(zhì)顧客、高潛力顧客、欺詐顧客等。
需求：業(yè)務(wù)用戶(hù)提出需求，除了做上述的基礎標簽之外，還要做出英語(yǔ)版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語(yǔ)版本的系統下使用。分析：調研到翻譯之后的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。
所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。之所以這樣，首先是為了避免未來(lái)更多語(yǔ)言版本的擴展需求或更多系統提出類(lèi)似的需求；其次，CRM系統已經(jīng)完成了“接力賽”的第一棒，創(chuàng )造了基礎數據，那么其他系統要特殊化使用，完全可以自行進(jìn)行特殊化處理，無(wú)需耦合回CRM系統。
結論：案例的需求本身是真需求，并且實(shí)現上也沒(méi)難度，但是該功能的定位超出了本系統范疇，專(zhuān)門(mén)系統做專(zhuān)職功能，化衍生需求應該在下游執行。否則，耦合性過(guò)高只會(huì )增加系統的復雜程度，難以維護和擴展。
二、拆分和聚合的方法1. 拆分需求法業(yè)務(wù)用戶(hù)提出一個(gè)需求，很可能只是短短的一段話(huà)。但是不要高興太早，可能這一句話(huà)暗含了很多線(xiàn)索，因此要善于拆分：先找他要解決的核心問(wèn)題，再?lài)@核心點(diǎn)，理清前、后、左、右、上、下的旁系需求點(diǎn)。
每個(gè)需求點(diǎn)再當做一個(gè)子需求進(jìn)行調研，最后再聚合在一起。以下面的案例說(shuō)明：背景：訂單業(yè)務(wù)的類(lèi)型很多，訂單退貨之后需要創(chuàng )建售后單據，但是因為數量大，所以花費很多人力，且手動(dòng)創(chuàng )建有出錯的風(fēng)險。
需求：業(yè)務(wù)提出的需求是“增加退貨訂單自動(dòng)創(chuàng )建售后單的功能”，這是個(gè)一句話(huà)需求。該一句話(huà)需求，其實(shí)包含了多種具體的訂單類(lèi)型和場(chǎng)景，那么我們就要拆分調研，拆分的維度比如：自營(yíng)訂單、第三方訂單、貨到付款訂單、先款后貨訂單、部分退貨訂單、完全退貨訂單、服裝事業(yè)部訂單、電子事業(yè)部訂單等，其中每一個(gè)維度就相當于一個(gè)小需求。
這里不一一展開(kāi)。2. 聚合需求法拆分法是對單個(gè)需求分解成若干小需求進(jìn)行調研，聚合法相反，是找到許多個(gè)相互關(guān)聯(lián)的小需求的共性，然后統籌成一個(gè)大需求去完成。
例如：由于業(yè)務(wù)用戶(hù)分散在不同的部門(mén)，各自為政，于是張三、李四可能都對一個(gè)業(yè)務(wù)流程有相同的需求，或者對同一個(gè)功能有相同的優(yōu)化期望，結果倆人分別提了需求過(guò)來(lái)。那么產(chǎn)品經(jīng)理就要找到二者背后的相關(guān)性和交叉區。
然后統籌規劃，聚合在一起當作一個(gè)需求來(lái)調研，最終輸出一個(gè)整體的需求調研結果。三、利用輔助功能調研需求調研產(chǎn)品現有功能，可以用來(lái)確認原有功能的邏輯，或者確定新需求方案是否可行。
比如業(yè)務(wù)用戶(hù)需要更新一個(gè)功能，為了避免更新出錯或遺漏，產(chǎn)品經(jīng)理需要知道修改前和修改后是否會(huì )能正常運行。最基礎的辦法就是自己設計一個(gè)測試用例，記錄操作方式、狀態(tài)變化、數據流向等。
看看下面的例子：背景：從銷(xiāo)售網(wǎng)站獲取到OMS系統（訂單管理系統）的訂單信息中帶著(zhù)顧客的郵箱。顧客下完單，可能會(huì )在銷(xiāo)售網(wǎng)站修改郵箱，而此時(shí)已經(jīng)獲取到OMS的歷史訂單中的郵箱是不變的。
需求：顧客若在銷(xiāo)售網(wǎng)站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。分析：需求是很明白的，也有它的意義，但有風(fēng)險。
因為我們知道訂單信息貫穿于整個(gè)訂單流轉過(guò)程中，牽扯到訂單編輯、審核、取消、配貨、發(fā)貨等，而這些環(huán)節跳轉的觸發(fā)條件可能就是某個(gè)信息更新（這里面就可能包括有郵箱更新）。因此，更新郵箱是否會(huì )影響流程中的某些環(huán)節，一時(shí)間很難準確知道。
于是，我們可以采用預測試的方式，設計測試用例，在測試機運行一些訂單，觀(guān)察各個(gè)環(huán)節郵箱變更的影響，然后收集起來(lái)分析對策。測試法就像是探雷一樣，主要用來(lái)解決未知風(fēng)險點(diǎn)。
這個(gè)方式的重點(diǎn)是記錄和分析操作前狀態(tài)、操作位。
5.需求分析常用方法都有哪些,請舉例說(shuō)明
問(wèn)卷調查法，是指設計方就用戶(hù)需求中的一些個(gè)性化的、需要進(jìn)一步明確的需求或問(wèn)題，通過(guò)采用向用戶(hù)問(wèn)卷調查表的方式，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于設計方和建設方、使用方都清楚項目需求的情況。因為建設方和使用方都清楚項目的需求，需要雙方進(jìn)一步溝通的需求或問(wèn)題就比較少，通過(guò)采用這種簡(jiǎn)單的問(wèn)卷調查方法就能使問(wèn)題得到較好的解決。
顯然對于樂(lè )百氏集團這樣規模龐大的公司，簡(jiǎn)單的問(wèn)卷調查是不能夠滿(mǎn)足準確獲得需求的需要的。會(huì )議討論法，是指設計方和用戶(hù)相關(guān)人員召開(kāi)若干次需求討論會(huì )議，達到徹底弄清項目需求的一種需求獲取方法。
這種方法適合于設計方不清楚用戶(hù)的詳細業(yè)務(wù)需求，但使用方清楚項目需求的情況。因為使用方清楚項目的需求，他們能準確地表達出他們的需求，而設計方有專(zhuān)業(yè)的需求，而我們有專(zhuān)業(yè)的軟件開(kāi)發(fā)經(jīng)驗，經(jīng)過(guò)回憶討論交流之后，能夠對用戶(hù)的需求進(jìn)行準確描述和把握。
這個(gè)方法對于準確的獲得樂(lè )百氏公司的需求是一種不錯的選擇。在本案例中系統的設計人員也是這么做的，他們通過(guò)和樂(lè )百氏項目組經(jīng)理的討論，很快了解了樂(lè )百氏的運作過(guò)程的數據。
界面原型法，是指設計方根據自己所了解的用戶(hù)需求，描畫(huà)出應用系統的功能界面后與用戶(hù)進(jìn)行交流和溝通，通過(guò)“界面原型”這一載體，達到雙方逐步明確項目需求的一種需求獲取的方法。這種方法比較適合于設計方和用戶(hù)都不是非常清楚項目需求、只是大概了解用戶(hù)需求的情況。
因為設計方和用戶(hù)方都不能非常準確的描述出客戶(hù)的需求，因此此時(shí)就更需要借助于一定的“載體”來(lái)加快對需求的挖掘和雙方對需求理解。
6.需求分析的主要方法是
目前，軟件需求的分析與設計方法較多，一些大同小異，而有的則基本思路相差很大。從開(kāi)發(fā)過(guò)程及特點(diǎn)出發(fā)，軟件開(kāi)發(fā)一般采用軟件生存周期的開(kāi)發(fā)方法，有時(shí)采用開(kāi)發(fā)原型以幫助了解用戶(hù)需求。在軟件分析與設計時(shí)，自上而下由全局出發(fā)全面規劃分析，然后逐步設計實(shí)現。
從系統分析出發(fā)，可將需求分析方法大致分為功能分解方法、結構化分析方法、信息建模法和面向對象的分析方法。
(1)功能分解方法。
將新系統作為多功能模塊的組合。各功能義可分解為若干子功能及接口，子功能再繼續分解。便可得到系統的雛形，即功能分解——功能、子功能、功能接口。
(2)結構化分析方法。
結構化分析方法是一種從問(wèn)題空間到某種表示的映射方法，是結構化方法中重要且被普遍接受的表示系統，由數據流圖和數據詞典構成并表示。此分析法又稱(chēng)為數據流法。其基本策略是跟蹤數據流，即研究問(wèn)題域中數據流動(dòng)方式及在各個(gè)環(huán)節上所進(jìn)行的處理，從而發(fā)現數據流和加工。結構化分析可定義為數據流、數據處理或加工、數據存儲、端點(diǎn)、處理說(shuō)明和數據字典。
(3)信息建模方法。
它從數據角度對現實(shí)世界建立模型。大型軟件較復雜；很難直接對其分析和設計，常借助模型。模型是開(kāi)發(fā)中常用工具，系統包括數據處理、事務(wù)管理和決策支持。實(shí)質(zhì)上，也可看成由一系列有序模型構成，其有序模型通常為功能模型、信息模型、數據模型、控制模型和決策模型。有序是指這些模型是分別在系統的不同開(kāi)發(fā)階段及開(kāi)發(fā)層次一同建立的。建立系統常用的基本工具是E—R圖。經(jīng)過(guò)改進(jìn)后稱(chēng)為信息建模法，后來(lái)又發(fā)展為語(yǔ)義數據建模方法，并引入了許多面向對象的特點(diǎn)。
信息建模可定義為實(shí)體或對象、屬性、關(guān)系、父類(lèi)型/子類(lèi)型和關(guān)聯(lián)對象。此方法的核心概念是實(shí)體和關(guān)系，基本工具是E-R圖，其基本要素由實(shí)體、屬性和聯(lián)系構成。該方法的基本策略是從現實(shí)中找出實(shí)體，然后再用屬性進(jìn)行描述。
(4)面向對象的分析方法。
面向對象的分析方法的關(guān)鍵是識別問(wèn)題域內的對象，分析它們之間的關(guān)系，并建立三類(lèi)模型，即對象模型、動(dòng)態(tài)模型和功能模型。面向對象主要考慮類(lèi)或對象、結構與連接、繼承和封裝、消息通信，只表示面向對象的分析中幾項最重要特征。類(lèi)的對象是對問(wèn)題域中事物的完整映射，包括事物的數據特征（即屬性）和行為特征（即服務(wù)）
7.如何進(jìn)行軟件需求分析
1.概念 需求的定義包括從用戶(hù)角度（系統的外部行為），以及從開(kāi)發(fā)者角度（一些內部特性）來(lái)闡述需求. 關(guān)鍵的問(wèn)題是一定要編寫(xiě)需求文檔.我曾經(jīng)目睹過(guò)一個(gè)項目中途更換了所有的開(kāi)發(fā)者，客戶(hù)被迫與新的需求分析者坐到一起.系統的分析人員說(shuō)："我們想與你談?wù)勀愕男枨?"客戶(hù)的第一反應便是："我已經(jīng)將我的要求都告訴你們前任了，現在我要的就是給我編一個(gè)系統". 百事通 而實(shí)際上，UGGs，需求并未編寫(xiě)成文檔，因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會(huì )談?dòng)涗浕蛞恍┝闼榈奈凑淼膶υ?huà)，你就確信你已明白用戶(hù)的需求，那完全是自欺欺人. 需求的另外一種定義認為需求是"用戶(hù)所需要的并能觸發(fā)一個(gè)程序或系統開(kāi)發(fā)工作的說(shuō)明".有些需求分析專(zhuān)家拓展了這個(gè)概念："從系統外部能發(fā)現系統所具有的滿(mǎn)足于用戶(hù)的特點(diǎn)、功能及屬性等".這些定義強調的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設計、構造的.而下面的定義則從用戶(hù)需要進(jìn)一步轉移到了系統特性： 需求是指明必須實(shí)現什么的規格說(shuō)明.它描述了系統的行為、特性或屬性，是在開(kāi)發(fā)過(guò)程中對系統的約束. 從上面這些不同形式的定義不難發(fā)現：并沒(méi)有一個(gè)清晰、毫無(wú)二義性的"需求"術(shù)語(yǔ)存在，真正的"需求"實(shí)際上在人們的腦海中，這個(gè)人們主要是指客戶(hù)，但一般情況下，用戶(hù)并不能描述自己的需要，只就需要系統分析人員根據用戶(hù)的自己語(yǔ)言的描述整理出相關(guān)的需要再進(jìn)一步和客戶(hù)核對.系統分析員和客戶(hù)需要確保所有項目風(fēng)險承擔者在描述需求的那些名詞的理解上務(wù)必達成共識. 任何文檔形式的需求（例如如下將要描述的需求規格說(shuō)明書(shū)）僅是一個(gè)模型，一種描述. 2.需求分析的任務(wù) 開(kāi)發(fā)軟件系統最為困難的部分就是準確說(shuō)明開(kāi)發(fā)什么.最為困難的概念性工作便是編寫(xiě)出詳細技術(shù)需求，這包括所有面向用戶(hù)、面向機器和其它軟件系統的接口.同時(shí)這也是一旦做錯，將最終會(huì )給系統帶來(lái)極大損害的部分，并且以后再對它進(jìn)行修改也極為困難. 目前，國內產(chǎn)品的龐雜，一家企業(yè)可能有幾個(gè)系統并立運行，它們之間接口是系統開(kāi)發(fā)人員最頭痛的問(wèn)題. 對于商業(yè)最終用戶(hù)應用程序，企業(yè)信息系統和軟件作為一個(gè)大系統的一部分的產(chǎn)品是顯而易見(jiàn)的.但是對于我們開(kāi)發(fā)人員來(lái)說(shuō)，并沒(méi)有編寫(xiě)出客戶(hù)認可的需求文檔，我們如何知道項目于何時(shí)結束？而如果我們不知道什么對客戶(hù)來(lái)說(shuō)是重要的，那我們又如何能使客戶(hù)感到滿(mǎn)意呢？ 然而，即便并非出于商業(yè)目的的軟件需求也是必須的.例如庫、組件和工具這些供開(kāi)發(fā)小組內部使用的軟件.當然你可能偶爾勿需文檔說(shuō)明就能與其他人意見(jiàn)較為一致，但更常見(jiàn)的是出現重復返工這種不可避免的后果，而重新編制代碼的代價(jià)遠遠超過(guò)重寫(xiě)一份需求文檔的代價(jià)，這些血的教訓正在國內的軟件開(kāi)發(fā)者身上發(fā)生. 近來(lái)，我遇到一個(gè)開(kāi)發(fā)小組開(kāi)發(fā)包括代碼編輯器在內的一套內部使用的計算機輔助軟件.不幸的是，當他們開(kāi)發(fā)完這個(gè)工具后，發(fā)現這個(gè)工具不能打印出源代碼文件，使用者當然希望有這個(gè)功能.結果這個(gè)小組只好手工抄寫(xiě)源代碼文檔以供代碼檢查.這說(shuō)明那怕需求明確無(wú)誤并構思準確，如果我們沒(méi)有編寫(xiě)文檔，軟件達不到期望目標也只能是咎由自取了. 相反的情況，我曾見(jiàn)一個(gè)要集成到"錯誤跟蹤系統"中的簡(jiǎn)單界面寫(xiě)了一頁(yè)需求說(shuō)明.而操作系統系統管理員在為處理腳本時(shí)發(fā)現簡(jiǎn)單的一張需求清單竟是如此有用.他們依據需求對系統進(jìn)行測試時(shí)，此系統不僅非常清晰地實(shí)現了所有必需功能，而且未發(fā)現任何錯誤. 事實(shí)上，需求文檔在開(kāi)發(fā)過(guò)程中一直起指導作用. 3.需求分析過(guò)程 可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開(kāi)發(fā)和需求管理兩部分更合適，如圖4-1所示： 圖4-1 需求工程域的層次分解示意圖 需求開(kāi)發(fā)可進(jìn)一步分為：?jiǎn)?wèn)題獲取、分析、編寫(xiě)規格說(shuō)明和驗證四個(gè)階段.這些子項包括軟件類(lèi)產(chǎn)品中需求收集、評價(jià)、編寫(xiě)文檔等所有活動(dòng).需求開(kāi)發(fā)活動(dòng)包括以下幾個(gè)方面： 確定產(chǎn)品所期望的用戶(hù)類(lèi)別. 獲取每個(gè)用戶(hù)類(lèi)的需求. 了解實(shí)際用戶(hù)任務(wù)和目標以及這些任務(wù)所支持的業(yè)務(wù)需求. 分析源于用戶(hù)的信息以區別用戶(hù)任務(wù)需求、功能需求、業(yè)務(wù)規則、質(zhì)量屬性、建議解決方法和附加信息. 將系統級的需求分為幾個(gè)子系統，并將需求中的一部份分配給軟件組件. 了解相關(guān)質(zhì)量屬性的重要性. 商討實(shí)施優(yōu)先級的劃分. 將所收集的用戶(hù)需求編寫(xiě)成文檔和模型. 評審需求規格說(shuō)明，確保對用戶(hù)需求達到共同的理解與認識，并在整個(gè)開(kāi)發(fā)小組接受說(shuō)明之前將問(wèn)題都弄清楚. 需求管理需要"建立并維護在軟件工程中同客戶(hù)達成的合同" .這種合同都包含在編寫(xiě)的需求文檔與模型中.客戶(hù)的接受僅是需求成功的一半，開(kāi)發(fā)人員也必須能夠接受他們，并真正把需求應用到產(chǎn)品中.通常的需求管理活動(dòng)包括： 定義需求基線(xiàn)（迅速制定需求文檔的主體）. 評審提出的需求變更、評估每項變更的可能影響從而決定是否實(shí)施它. 以一種可控制的方式將需求變更融入到項目中. 使當前的項目計劃與需求一致. 估計變更需求所產(chǎn)生影響并在此基礎上協(xié)商新的承諾，這種承諾具體體現在項目解決方案上. 讓每項需求都能與其對應的設計、源代碼和測試用例聯(lián)系起來(lái)以實(shí)現跟蹤. 在整個(gè)項目過(guò)程中跟蹤需求狀態(tài)及其。
8.需求分析有哪三種方法
它首先用結構化分析（SA）對軟件進(jìn)行需求分析，然后用結構化設計（SD）方法進(jìn)行總體設計，最后是結構化編程（SP）。它給出了兩類(lèi)典型的軟件結構（變換型和事務(wù)型）使軟件開(kāi)發(fā)的成功率大大提高。
三種基本的結構形式就是順序、選擇和重復。三種數據結構可以進(jìn)行組合，形成復雜的結構體系。這一方法從目標系統的輸入、輸出數據結構入手，導出程序框架結構，再補充其它細節，就可得到完整的程序結構圖。這一方法對輸入、輸出數據結構明確的中小型系統特別有效，如商業(yè)應用中的文件表格處理。該方法也可與其它方法結合，用于模塊的詳細設計。
