軟件需求分析主要方法問題(軟件需求的分析方法)

1.軟件需求的分析方法

軟件需求分析方法大體分為如下四類：結(jié)構(gòu)化方法、面向?qū)ο蠓椒ā⒚嫦蚩刂品椒ê兔嫦驍?shù)據(jù)方法。限于篇幅，將主要從結(jié)構(gòu)化方法和面向?qū)ο蠓椒ㄒ约癛UP三個(gè)方面進(jìn)行簡(jiǎn)要的探討。 面向?qū)ο螅∣bject Oriented, OO）的方法把分析建立在系統(tǒng)對(duì)象以及對(duì)象間交互的基礎(chǔ)之上，使得我們能以3個(gè)最基本的方法框架——對(duì)象及其屬性、分類結(jié)構(gòu)和集合結(jié)構(gòu)來定義和溝通需求。面向?qū)ο蟮膯栴}分析模型從3個(gè)側(cè)面進(jìn)行描述，即對(duì)象模型（對(duì)象的靜態(tài)結(jié)構(gòu)）、動(dòng)態(tài)模型（對(duì)象相互作用的順序）和功能模型（數(shù)據(jù)變換及功能依存關(guān)系）。需求工程的抽象原則、層次原則和分割原則同樣適用于面向?qū)ο蠓椒?，即?duì)象抽象與功能抽象原則是一樣的，也是從高級(jí)到低級(jí)、從邏輯到物理，逐級(jí)細(xì)分.每一級(jí)抽象都重復(fù)對(duì)象建模（對(duì)象識(shí)別）一動(dòng)態(tài)建模（事件識(shí)別）一功能建模（操作識(shí)別）的過程，直到每一個(gè)對(duì)象實(shí)例在物理（程序編碼）上全部實(shí)現(xiàn)為止。

面向?qū)ο笮枨蠓治觯∣ORA）利用一些基本概念來建立相應(yīng)模型，以表達(dá)目標(biāo)系統(tǒng)的不同側(cè)面。盡管不同的方法所采用的具體模型不盡相同，但都無外乎用如下五個(gè)基本模型來描述軟件需求：

整體—部分模型：該模型描述對(duì)象（類）是如何由簡(jiǎn)單的對(duì)象（類）構(gòu)成的。將一個(gè)復(fù)雜對(duì)象（類）描述成一個(gè)由交互作用的若干對(duì)象（類）構(gòu)成的結(jié)構(gòu)的能力是OO途徑的突出優(yōu)點(diǎn)。該模型亦稱聚合模型。

分類模型：分類模型描述類之間的繼承關(guān)系。與聚合關(guān)系不同，它說明的是一個(gè)類可以繼承另一個(gè)或另一些類的成分，以實(shí)現(xiàn)類中成分的復(fù)用。

類—對(duì)象模型：分析過程必須描述屬于每個(gè)類的對(duì)象所具有的行為，這種行為描述的詳細(xì)程度可以根據(jù)具體情況而定。既可以只說明行為的輸入、輸出和功能，也可以采用比較形式的途徑來精確地描述其輸入、輸出及其相應(yīng)的類型甚至使用偽碼或小說明的形式來詳細(xì)刻畫。

對(duì)象交互模型：一個(gè)面向?qū)ο蟮南到y(tǒng)模型必須描述其中對(duì)象的交互方法。如前所述，對(duì)象交互是通過消息傳遞來實(shí)現(xiàn)的。事實(shí)人對(duì)象交互也可看作是對(duì)象行為之間的引用關(guān)系。因此，對(duì)象交互模型就要刻畫對(duì)象之間的消息流。對(duì)應(yīng)于不同的詳細(xì)程度，有不同的消息流描述分析，分析人員應(yīng)根據(jù)具體館況而選擇。一般地，一個(gè)詳細(xì)的對(duì)象交互模型能夠說明對(duì)象之間的消息及其流向，并且同時(shí)說明該消息將激活的對(duì)象及行為。一個(gè)不太詳細(xì)的對(duì)象交互模型可以只說明對(duì)象之間有消息，并指明其流向即可。還有一種狀況就是介于此兩者之間。

狀態(tài)模型：在狀態(tài)模型中，把一個(gè)對(duì)象看作是一個(gè)有限狀態(tài)機(jī)，由一個(gè)狀態(tài)到另一狀態(tài)的轉(zhuǎn)變稱作狀態(tài)轉(zhuǎn)換。狀態(tài)模型將對(duì)象的行為描述成其不同狀態(tài)之間的通路。它也可以刻畫動(dòng)態(tài)系統(tǒng)中對(duì)象的創(chuàng)建和廢除，并稱由對(duì)象的創(chuàng)建到對(duì)象的廢除狀態(tài)之間的退路為對(duì)象的生存期。

狀態(tài)模型既可以用狀態(tài)轉(zhuǎn)換因的圖形化手段，又可用決策表或稱決策矩陣的形式來表。 RUP(Rational Unified Process)是Rational公司開發(fā)和維護(hù)的過程產(chǎn)品。RUP是工程化的軟件開發(fā)過程，它提供了在開發(fā)機(jī)構(gòu)中分派任務(wù)和責(zé)任的紀(jì)律化方法。RUP不僅僅是一個(gè)簡(jiǎn)單的過程，而是一個(gè)通用的過程框架，可用于各種不同類型的軟件系統(tǒng)、各種不同的應(yīng)用領(lǐng)域、各種不同類型的組織、各種不同的功能級(jí)別以及各種不同的項(xiàng)目規(guī)模。RUP的突出特點(diǎn)可以由以下三個(gè)關(guān)鍵詞來體現(xiàn)——用例驅(qū)動(dòng)、以構(gòu)架為中心、迭代和增量的。這些是RUP所特有的，也是同等重要的。構(gòu)架提供了一種結(jié)構(gòu)來指導(dǎo)迭代過程中的工作，而用例則確定了目標(biāo)井驅(qū)動(dòng)每次迭代的工作。

進(jìn)行需求分析的基礎(chǔ)是要獲得用戶的需要，為了完成這一工作，必須建立業(yè)務(wù)模型，通過描述業(yè)務(wù)規(guī)則、業(yè)務(wù)邏輯，明確業(yè)務(wù)過程并對(duì)其進(jìn)行規(guī)范、優(yōu)化。對(duì)于一個(gè)系統(tǒng)，在建立業(yè)務(wù)模型時(shí)，應(yīng)從3個(gè)方面來描述其特性：功能、行為、數(shù)據(jù)，對(duì)應(yīng)于這些特性。 基于上述分析可知，結(jié)構(gòu)化分析方法與面向?qū)ο蠓治龇椒ǖ膮^(qū)別主要體現(xiàn)在兩個(gè)方面：

* 將系統(tǒng)分解成于系統(tǒng)的方式不同。前者將系統(tǒng)描述成一組交互作用的處理，后者則描述成一組交互作用的對(duì)象。

* 子系統(tǒng)之間的交互關(guān)系的描述方式不一樣。前者加工之間的交互是通過不太精確的數(shù)據(jù)流來表示的，而后者對(duì)象之間通過消息傳遞交互關(guān)系。

因此，面向?qū)ο筌浖枨蠓治龅慕Y(jié)果能更好地刻畫現(xiàn)實(shí)世界，處理復(fù)雜問題，對(duì)象比過程更具有穩(wěn)定性，便于維護(hù)與復(fù)用。

2.需求分析有哪些方法

三種需求分析的方法：結(jié)構(gòu)化分析方法、面向?qū)ο蟮姆治龇椒?、面向問題域的分析方法。

結(jié)構(gòu)化的分析方法是傳統(tǒng)的分析法，它的好處是在需求階段可以不需要精確地定義系統(tǒng)，只需要根據(jù)業(yè)務(wù)框架確定系統(tǒng)的功能范圍，以及每個(gè)功能的處理邏輯和業(yè)務(wù)規(guī)則，功能需求規(guī)格書等。因?yàn)椴恍枰_描述，因此描述系統(tǒng)的方式比較靈活多樣，可以采用圖表、示例圖、文字等等方式來描述系統(tǒng)。在系統(tǒng)開發(fā)以前，一般還可以采用更為直觀的原型系統(tǒng)方式和最終用戶進(jìn)行交流和確認(rèn)，因此對(duì)業(yè)務(wù)需求的要求會(huì)低一些，業(yè)務(wù)需求階段的周期相對(duì)容易控制；通過業(yè)務(wù)全景圖，最終用戶也能了解系統(tǒng)的功能；通過功能活動(dòng)圖和業(yè)務(wù)規(guī)則的描述，也可以相對(duì)精確地描述業(yè)務(wù)系統(tǒng)；因?yàn)闆]有嚴(yán)格的標(biāo)記語言，可以采用適當(dāng)?shù)钠枋鲞m當(dāng)?shù)南到y(tǒng)。當(dāng)然，這種方法的缺點(diǎn)也是明顯的，分析人員和業(yè)務(wù)人員之間可能缺乏共同語言，機(jī)器不能識(shí)別業(yè)務(wù)需求書，在設(shè)計(jì)階段還需要繼續(xù)和用戶確認(rèn)一部分功能。

面向?qū)ο蟮姆治龇椒ǖ淖畲蠛锰幨窃谛枨箅A段，就能夠非常精確地描述一個(gè)系統(tǒng)，采用程序語言的方式和最終用戶交流（最終用戶必須要熟悉這種語言），能夠在項(xiàng)目一開始就發(fā)現(xiàn)很多問題，避免在開發(fā)的過程中出現(xiàn)需求的反復(fù)，而且在系統(tǒng)設(shè)計(jì)和開發(fā)階段不需要最終用戶參與。在實(shí)施上，一般可以采用場(chǎng)景、業(yè)務(wù)功能等方式來描述，比較適合于業(yè)務(wù)流程環(huán)節(jié)多的系統(tǒng)，或者軟件產(chǎn)品的開發(fā)。但是，我們也要看到，在現(xiàn)實(shí)中，絕大多數(shù)的應(yīng)用系統(tǒng)都很難在需求階段就可以被精確地抽象化定義，所以這種方法的缺點(diǎn)和困難也是顯而易見的：首先，用戶要非常清楚地知道最終的業(yè)務(wù)系統(tǒng)應(yīng)該是什么樣，或者采用一種抽象的方式能夠確定最終的應(yīng)用系統(tǒng)；其次，因?yàn)樽罱K用戶不需要參與設(shè)計(jì)和開發(fā)階段的工作，所以雙方確定業(yè)務(wù)需求的過程也會(huì)比較長(zhǎng)；同時(shí)，因?yàn)槭蔷_描述，因此描述系統(tǒng)的語言是非常邏輯化的，一般通過某種方式可以使機(jī)器識(shí)別業(yè)務(wù)需求，采用這種方式寫的業(yè)務(wù)需求是非常格式化的，一方面描述一個(gè)系統(tǒng)需要的信息非常多，可能使需求說明的篇幅非常長(zhǎng)，不便于理解和閱讀；另外由于通過抽象的方式來推演最終系統(tǒng)的運(yùn)行方式，對(duì)業(yè)務(wù)人員的要求非常高。

3.軟件需求分析在軟件工程中的作用,有哪些軟件需求分析的方法

軟件工程中包含需求、設(shè)計(jì)、編碼和測(cè)試四個(gè)階段，其中需求工程是軟件工程第一個(gè)也是很重要的一個(gè)階段，需求分析是要決定“做什么，不做什么”。

在一個(gè)軟件項(xiàng)目中，軟件需求包括三個(gè)不同的層次-業(yè)務(wù)需求、用戶需求和功能需求-也包括非功能需求：業(yè)務(wù)需說明了提供給客戶和產(chǎn)品開發(fā)商的新系統(tǒng)的最初利益，反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。

軟件開發(fā)，能否獲得成功，最重要的是需求分析的工作。因此，軟件需求分析能力和水平，對(duì)軟件項(xiàng)目至關(guān)重要。

一般的分析方法和步驟如下：

⑴首先調(diào)查組織機(jī)構(gòu)情況 包括了解該組織的部門組成情況，各部門的職能等，為分析信息流程作準(zhǔn)備。

⑵然后調(diào)查各部門的業(yè)務(wù)活動(dòng)情況 包括了解各個(gè)部門輸入和使用什么數(shù)據(jù)，如何加工處理這些數(shù)據(jù)，輸出什么信息，輸出到什么部門，輸出結(jié)果的格式是什么。

⑶協(xié)助用戶明確對(duì)新系統(tǒng)的各種要求 包括信息要求、處理要求、完全性與完整性要求。

⑷確定新系統(tǒng)的邊界 確定哪些功能由計(jì)算機(jī)完成或?qū)頊?zhǔn)備讓計(jì)算機(jī)完成，哪些活動(dòng)由人工完成。由計(jì)算機(jī)完成的功能就是新系統(tǒng)應(yīng)該實(shí)現(xiàn)的功能。

常用的調(diào)查方法有：

⑴跟班作業(yè) 通過親身參加業(yè)務(wù)工作來了解業(yè)務(wù)活動(dòng)的情況。這種方法可以比較準(zhǔn)確地理解用戶的需求，但比較耗費(fèi)時(shí)間。

⑵開調(diào)查會(huì) 通過與用戶座談來了解業(yè)務(wù)活動(dòng)情況及用戶需求。座談時(shí)，參加者之間可以相互啟發(fā)。

⑶請(qǐng)專人介紹。

⑷詢問 對(duì)某些調(diào)查中的問題，可以找專人詢問。

⑸設(shè)計(jì)調(diào)查表請(qǐng)用戶填寫 如果調(diào)查表設(shè)計(jì)得合理，這種方法是很有效，也很易于為用戶接受的。

⑹查閱記錄 即查閱與原系統(tǒng)有關(guān)的數(shù)據(jù)記錄，包括原始單據(jù)、賬簿、報(bào)表等。 通過調(diào)查了解了用戶需求后，還需要進(jìn)一步分析和表達(dá)用戶的需求。分析和表達(dá)用戶需求的方法主要包括自頂向下和自底向上兩類方法。

4.軟件工程中常用的需求分析的方法有哪些

一、過濾需求的方法做后端系統(tǒng)，要學(xué)會(huì)的第一個(gè)技能就是砍需求。

也就是過濾需求。這不是一個(gè)貶義詞，反而是體現(xiàn)后端產(chǎn)品價(jià)值判斷的基礎(chǔ)。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應(yīng)該被過濾掉。1. 用戶場(chǎng)景模擬法后端產(chǎn)品的出發(fā)點(diǎn)就是幫助業(yè)務(wù)用戶，因此在調(diào)研需求的時(shí)候要模擬業(yè)務(wù)的場(chǎng)景，分析業(yè)務(wù)用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那么這個(gè)需求就可能是偽需求。以下面的案例說明：背景：“貨到付款”類型的訂單會(huì)因?yàn)槿必浂鵁o法發(fā)出，如果超過一定的時(shí)間，客服就會(huì)跟顧客溝通，幫顧客取消訂單。

需求：由于這種訂單的數(shù)量還是蠻多的，逐個(gè)取消太費(fèi)時(shí)間，因此業(yè)務(wù)用戶要求在“缺貨訂單”列表頁增加“批量取消訂單”按鈕。分析：調(diào)研到業(yè)務(wù)操作場(chǎng)景，是先找到該類缺貨訂單，然后和顧客溝通，顧客同意刪除，才進(jìn)行刪除。

也就是逐個(gè)溝通確認(rèn)，再逐個(gè)取消訂單的，所以“批量取消訂單”無法被有效使用。因此，該需求是個(gè)偽需求，應(yīng)該被過濾掉。

2. 功能歸屬分析專門的系統(tǒng)做專職功能，有助于合理的產(chǎn)品體系建設(shè)。因此需求調(diào)研的時(shí)候，可以通過系統(tǒng)的定位，判斷需求是否應(yīng)該在該系統(tǒng)完成。

如果不屬于該系統(tǒng)范疇，那么直接說服需求方更換方案。以下面的案例說明：背景：CRM系統(tǒng)（顧客關(guān)系管理系統(tǒng)）有一個(gè)顧客標(biāo)簽生成功能，就是根據(jù)顧客的消費(fèi)行為數(shù)據(jù)，自動(dòng)對(duì)應(yīng)關(guān)聯(lián)上標(biāo)簽，如優(yōu)質(zhì)顧客、高潛力顧客、欺詐顧客等。

需求：業(yè)務(wù)用戶提出需求，除了做上述的基礎(chǔ)標(biāo)簽之外，還要做出英語版本的標(biāo)簽（就是把標(biāo)簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統(tǒng)下使用。分析：調(diào)研到翻譯之后的標(biāo)簽不是在CRM系統(tǒng)使用的，而是給到SMS（客服系統(tǒng)）使用的。

所以應(yīng)該由SMS根據(jù)CMS提供的基礎(chǔ)標(biāo)簽數(shù)據(jù)，自己做二次的衍生。之所以這樣，首先是為了避免未來更多語言版本的擴(kuò)展需求或更多系統(tǒng)提出類似的需求；其次，CRM系統(tǒng)已經(jīng)完成了“接力賽”的第一棒，創(chuàng)造了基礎(chǔ)數(shù)據(jù)，那么其他系統(tǒng)要特殊化使用，完全可以自行進(jìn)行特殊化處理，無需耦合回CRM系統(tǒng)。

結(jié)論：案例的需求本身是真需求，并且實(shí)現(xiàn)上也沒難度，但是該功能的定位超出了本系統(tǒng)范疇，專門系統(tǒng)做專職功能，化衍生需求應(yīng)該在下游執(zhí)行。否則，耦合性過高只會(huì)增加系統(tǒng)的復(fù)雜程度，難以維護(hù)和擴(kuò)展。

二、拆分和聚合的方法1. 拆分需求法業(yè)務(wù)用戶提出一個(gè)需求，很可能只是短短的一段話。但是不要高興太早，可能這一句話暗含了很多線索，因此要善于拆分：先找他要解決的核心問題，再圍繞核心點(diǎn)，理清前、后、左、右、上、下的旁系需求點(diǎn)。

每個(gè)需求點(diǎn)再當(dāng)做一個(gè)子需求進(jìn)行調(diào)研，最后再聚合在一起。以下面的案例說明：背景：訂單業(yè)務(wù)的類型很多，訂單退貨之后需要?jiǎng)?chuàng)建售后單據(jù)，但是因?yàn)閿?shù)量大，所以花費(fèi)很多人力，且手動(dòng)創(chuàng)建有出錯(cuò)的風(fēng)險(xiǎn)。

需求：業(yè)務(wù)提出的需求是“增加退貨訂單自動(dòng)創(chuàng)建售后單的功能”，這是個(gè)一句話需求。該一句話需求，其實(shí)包含了多種具體的訂單類型和場(chǎng)景，那么我們就要拆分調(diào)研，拆分的維度比如：自營(yíng)訂單、第三方訂單、貨到付款訂單、先款后貨訂單、部分退貨訂單、完全退貨訂單、服裝事業(yè)部訂單、電子事業(yè)部訂單等，其中每一個(gè)維度就相當(dāng)于一個(gè)小需求。

這里不一一展開。2. 聚合需求法拆分法是對(duì)單個(gè)需求分解成若干小需求進(jìn)行調(diào)研，聚合法相反，是找到許多個(gè)相互關(guān)聯(lián)的小需求的共性，然后統(tǒng)籌成一個(gè)大需求去完成。

例如：由于業(yè)務(wù)用戶分散在不同的部門，各自為政，于是張三、李四可能都對(duì)一個(gè)業(yè)務(wù)流程有相同的需求，或者對(duì)同一個(gè)功能有相同的優(yōu)化期望，結(jié)果倆人分別提了需求過來。那么產(chǎn)品經(jīng)理就要找到二者背后的相關(guān)性和交叉區(qū)。

然后統(tǒng)籌規(guī)劃，聚合在一起當(dāng)作一個(gè)需求來調(diào)研，最終輸出一個(gè)整體的需求調(diào)研結(jié)果。三、利用輔助功能調(diào)研需求調(diào)研產(chǎn)品現(xiàn)有功能，可以用來確認(rèn)原有功能的邏輯，或者確定新需求方案是否可行。

比如業(yè)務(wù)用戶需要更新一個(gè)功能，為了避免更新出錯(cuò)或遺漏，產(chǎn)品經(jīng)理需要知道修改前和修改后是否會(huì)能正常運(yùn)行。最基礎(chǔ)的辦法就是自己設(shè)計(jì)一個(gè)測(cè)試用例，記錄操作方式、狀態(tài)變化、數(shù)據(jù)流向等。

看看下面的例子：背景：從銷售網(wǎng)站獲取到OMS系統(tǒng)（訂單管理系統(tǒng)）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會(huì)在銷售網(wǎng)站修改郵箱，而此時(shí)已經(jīng)獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網(wǎng)站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。分析：需求是很明白的，也有它的意義，但有風(fēng)險(xiǎn)。

因?yàn)槲覀冎烙唵涡畔⒇灤┯谡麄€(gè)訂單流轉(zhuǎn)過程中，牽扯到訂單編輯、審核、取消、配貨、發(fā)貨等，而這些環(huán)節(jié)跳轉(zhuǎn)的觸發(fā)條件可能就是某個(gè)信息更新（這里面就可能包括有郵箱更新）。因此，更新郵箱是否會(huì)影響流程中的某些環(huán)節(jié)，一時(shí)間很難準(zhǔn)確知道。

于是，我們可以采用預(yù)測(cè)試的方式，設(shè)計(jì)測(cè)試用例，在測(cè)試機(jī)運(yùn)行一些訂單，觀察各個(gè)環(huán)節(jié)郵箱變更的影響，然后收集起來分析對(duì)策。測(cè)試法就像是探雷一樣，主要用來解決未知風(fēng)險(xiǎn)點(diǎn)。

這個(gè)方式的重點(diǎn)是記錄和分析操作前狀態(tài)、操作位。

5.需求分析常用方法都有哪些,請(qǐng)舉例說明

問卷調(diào)查法，是指設(shè)計(jì)方就用戶需求中的一些個(gè)性化的、需要進(jìn)一步明確的需求或問題，通過采用向用戶問卷調(diào)查表的方式，達(dá)到徹底弄清項(xiàng)目需求的一種需求獲取方法。

這種方法適合于設(shè)計(jì)方和建設(shè)方、使用方都清楚項(xiàng)目需求的情況。因?yàn)榻ㄔO(shè)方和使用方都清楚項(xiàng)目的需求，需要雙方進(jìn)一步溝通的需求或問題就比較少，通過采用這種簡(jiǎn)單的問卷調(diào)查方法就能使問題得到較好的解決。

顯然對(duì)于樂百氏集團(tuán)這樣規(guī)模龐大的公司，簡(jiǎn)單的問卷調(diào)查是不能夠滿足準(zhǔn)確獲得需求的需要的。會(huì)議討論法，是指設(shè)計(jì)方和用戶相關(guān)人員召開若干次需求討論會(huì)議，達(dá)到徹底弄清項(xiàng)目需求的一種需求獲取方法。

這種方法適合于設(shè)計(jì)方不清楚用戶的詳細(xì)業(yè)務(wù)需求，但使用方清楚項(xiàng)目需求的情況。因?yàn)槭褂梅角宄?xiàng)目的需求，他們能準(zhǔn)確地表達(dá)出他們的需求，而設(shè)計(jì)方有專業(yè)的需求，而我們有專業(yè)的軟件開發(fā)經(jīng)驗(yàn)，經(jīng)過回憶討論交流之后，能夠?qū)τ脩舻男枨筮M(jìn)行準(zhǔn)確描述和把握。

這個(gè)方法對(duì)于準(zhǔn)確的獲得樂百氏公司的需求是一種不錯(cuò)的選擇。在本案例中系統(tǒng)的設(shè)計(jì)人員也是這么做的，他們通過和樂百氏項(xiàng)目組經(jīng)理的討論，很快了解了樂百氏的運(yùn)作過程的數(shù)據(jù)。

界面原型法，是指設(shè)計(jì)方根據(jù)自己所了解的用戶需求，描畫出應(yīng)用系統(tǒng)的功能界面后與用戶進(jìn)行交流和溝通，通過“界面原型”這一載體，達(dá)到雙方逐步明確項(xiàng)目需求的一種需求獲取的方法。這種方法比較適合于設(shè)計(jì)方和用戶都不是非常清楚項(xiàng)目需求、只是大概了解用戶需求的情況。

因?yàn)樵O(shè)計(jì)方和用戶方都不能非常準(zhǔn)確的描述出客戶的需求，因此此時(shí)就更需要借助于一定的“載體”來加快對(duì)需求的挖掘和雙方對(duì)需求理解。

6.需求分析的主要方法是

目前，軟件需求的分析與設(shè)計(jì)方法較多，一些大同小異，而有的則基本思路相差很大。從開發(fā)過程及特點(diǎn)出發(fā)，軟件開發(fā)一般采用軟件生存周期的開發(fā)方法，有時(shí)采用開發(fā)原型以幫助了解用戶需求。在軟件分析與設(shè)計(jì)時(shí)，自上而下由全局出發(fā)全面規(guī)劃分析，然后逐步設(shè)計(jì)實(shí)現(xiàn)。

從系統(tǒng)分析出發(fā)，可將需求分析方法大致分為功能分解方法、結(jié)構(gòu)化分析方法、信息建模法和面向?qū)ο蟮姆治龇椒ā?/p>

(1)功能分解方法。

將新系統(tǒng)作為多功能模塊的組合。各功能義可分解為若干子功能及接口，子功能再繼續(xù)分解。便可得到系統(tǒng)的雛形，即功能分解——功能、子功能、功能接口。

(2)結(jié)構(gòu)化分析方法。

結(jié)構(gòu)化分析方法是一種從問題空間到某種表示的映射方法，是結(jié)構(gòu)化方法中重要且被普遍接受的表示系統(tǒng)，由數(shù)據(jù)流圖和數(shù)據(jù)詞典構(gòu)成并表示。此分析法又稱為數(shù)據(jù)流法。其基本策略是跟蹤數(shù)據(jù)流，即研究問題域中數(shù)據(jù)流動(dòng)方式及在各個(gè)環(huán)節(jié)上所進(jìn)行的處理，從而發(fā)現(xiàn)數(shù)據(jù)流和加工。結(jié)構(gòu)化分析可定義為數(shù)據(jù)流、數(shù)據(jù)處理或加工、數(shù)據(jù)存儲(chǔ)、端點(diǎn)、處理說明和數(shù)據(jù)字典。

(3)信息建模方法。

它從數(shù)據(jù)角度對(duì)現(xiàn)實(shí)世界建立模型。大型軟件較復(fù)雜；很難直接對(duì)其分析和設(shè)計(jì)，常借助模型。模型是開發(fā)中常用工具，系統(tǒng)包括數(shù)據(jù)處理、事務(wù)管理和決策支持。實(shí)質(zhì)上，也可看成由一系列有序模型構(gòu)成，其有序模型通常為功能模型、信息模型、數(shù)據(jù)模型、控制模型和決策模型。有序是指這些模型是分別在系統(tǒng)的不同開發(fā)階段及開發(fā)層次一同建立的。建立系統(tǒng)常用的基本工具是E—R圖。經(jīng)過改進(jìn)后稱為信息建模法，后來又發(fā)展為語義數(shù)據(jù)建模方法，并引入了許多面向?qū)ο蟮奶攸c(diǎn)。

信息建模可定義為實(shí)體或?qū)ο?、屬性、關(guān)系、父類型/子類型和關(guān)聯(lián)對(duì)象。此方法的核心概念是實(shí)體和關(guān)系，基本工具是E-R圖，其基本要素由實(shí)體、屬性和聯(lián)系構(gòu)成。該方法的基本策略是從現(xiàn)實(shí)中找出實(shí)體，然后再用屬性進(jìn)行描述。

(4)面向?qū)ο蟮姆治龇椒ā?/p>

面向?qū)ο蟮姆治龇椒ǖ年P(guān)鍵是識(shí)別問題域內(nèi)的對(duì)象，分析它們之間的關(guān)系，并建立三類模型，即對(duì)象模型、動(dòng)態(tài)模型和功能模型。面向?qū)ο笾饕紤]類或?qū)ο?、結(jié)構(gòu)與連接、繼承和封裝、消息通信，只表示面向?qū)ο蟮姆治鲋袔醉?xiàng)最重要特征。類的對(duì)象是對(duì)問題域中事物的完整映射，包括事物的數(shù)據(jù)特征（即屬性）和行為特征（即服務(wù)）

7.如何進(jìn)行軟件需求分析

1.概念 需求的定義包括從用戶角度（系統(tǒng)的外部行為），以及從開發(fā)者角度（一些內(nèi)部特性）來闡述需求. 關(guān)鍵的問題是一定要編寫需求文檔.我曾經(jīng)目睹過一個(gè)項(xiàng)目中途更換了所有的開發(fā)者，客戶被迫與新的需求分析者坐到一起.系統(tǒng)的分析人員說："我們想與你談?wù)勀愕男枨?"客戶的第一反應(yīng)便是："我已經(jīng)將我的要求都告訴你們前任了，現(xiàn)在我要的就是給我編一個(gè)系統(tǒng)". 百事通 而實(shí)際上，UGGs，需求并未編寫成文檔，因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會(huì)談?dòng)涗浕蛞恍┝闼榈奈凑淼膶?duì)話，你就確信你已明白用戶的需求，那完全是自欺欺人. 需求的另外一種定義認(rèn)為需求是"用戶所需要的并能觸發(fā)一個(gè)程序或系統(tǒng)開發(fā)工作的說明".有些需求分析專家拓展了這個(gè)概念："從系統(tǒng)外部能發(fā)現(xiàn)系統(tǒng)所具有的滿足于用戶的特點(diǎn)、功能及屬性等".這些定義強(qiáng)調(diào)的是產(chǎn)品是什么樣的，而并非產(chǎn)品是怎樣設(shè)計(jì)、構(gòu)造的.而下面的定義則從用戶需要進(jìn)一步轉(zhuǎn)移到了系統(tǒng)特性： 需求是指明必須實(shí)現(xiàn)什么的規(guī)格說明.它描述了系統(tǒng)的行為、特性或?qū)傩?，是在開發(fā)過程中對(duì)系統(tǒng)的約束. 從上面這些不同形式的定義不難發(fā)現(xiàn)：并沒有一個(gè)清晰、毫無二義性的"需求"術(shù)語存在，真正的"需求"實(shí)際上在人們的腦海中，這個(gè)人們主要是指客戶，但一般情況下，用戶并不能描述自己的需要，只就需要系統(tǒng)分析人員根據(jù)用戶的自己語言的描述整理出相關(guān)的需要再進(jìn)一步和客戶核對(duì).系統(tǒng)分析員和客戶需要確保所有項(xiàng)目風(fēng)險(xiǎn)承擔(dān)者在描述需求的那些名詞的理解上務(wù)必達(dá)成共識(shí). 任何文檔形式的需求（例如如下將要描述的需求規(guī)格說明書）僅是一個(gè)模型，一種描述. 2.需求分析的任務(wù) 開發(fā)軟件系統(tǒng)最為困難的部分就是準(zhǔn)確說明開發(fā)什么.最為困難的概念性工作便是編寫出詳細(xì)技術(shù)需求，這包括所有面向用戶、面向機(jī)器和其它軟件系統(tǒng)的接口.同時(shí)這也是一旦做錯(cuò)，將最終會(huì)給系統(tǒng)帶來極大損害的部分，并且以后再對(duì)它進(jìn)行修改也極為困難. 目前，國(guó)內(nèi)產(chǎn)品的龐雜，一家企業(yè)可能有幾個(gè)系統(tǒng)并立運(yùn)行，它們之間接口是系統(tǒng)開發(fā)人員最頭痛的問題. 對(duì)于商業(yè)最終用戶應(yīng)用程序，企業(yè)信息系統(tǒng)和軟件作為一個(gè)大系統(tǒng)的一部分的產(chǎn)品是顯而易見的.但是對(duì)于我們開發(fā)人員來說，并沒有編寫出客戶認(rèn)可的需求文檔，我們?nèi)绾沃理?xiàng)目于何時(shí)結(jié)束？而如果我們不知道什么對(duì)客戶來說是重要的，那我們又如何能使客戶感到滿意呢？ 然而，即便并非出于商業(yè)目的的軟件需求也是必須的.例如庫、組件和工具這些供開發(fā)小組內(nèi)部使用的軟件.當(dāng)然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現(xiàn)重復(fù)返工這種不可避免的后果，而重新編制代碼的代價(jià)遠(yuǎn)遠(yuǎn)超過重寫一份需求文檔的代價(jià)，這些血的教訓(xùn)正在國(guó)內(nèi)的軟件開發(fā)者身上發(fā)生. 近來，我遇到一個(gè)開發(fā)小組開發(fā)包括代碼編輯器在內(nèi)的一套內(nèi)部使用的計(jì)算機(jī)輔助軟件.不幸的是，當(dāng)他們開發(fā)完這個(gè)工具后，發(fā)現(xiàn)這個(gè)工具不能打印出源代碼文件，使用者當(dāng)然希望有這個(gè)功能.結(jié)果這個(gè)小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤并構(gòu)思準(zhǔn)確，如果我們沒有編寫文檔，軟件達(dá)不到期望目標(biāo)也只能是咎由自取了. 相反的情況，我曾見一個(gè)要集成到"錯(cuò)誤跟蹤系統(tǒng)"中的簡(jiǎn)單界面寫了一頁需求說明.而操作系統(tǒng)系統(tǒng)管理員在為處理腳本時(shí)發(fā)現(xiàn)簡(jiǎn)單的一張需求清單竟是如此有用.他們依據(jù)需求對(duì)系統(tǒng)進(jìn)行測(cè)試時(shí)，此系統(tǒng)不僅非常清晰地實(shí)現(xiàn)了所有必需功能，而且未發(fā)現(xiàn)任何錯(cuò)誤. 事實(shí)上，需求文檔在開發(fā)過程中一直起指導(dǎo)作用. 3.需求分析過程 可把整個(gè)軟件需求工程研究領(lǐng)域劃分為需求開發(fā)和需求管理兩部分更合適，如圖4-1所示： 圖4-1 需求工程域的層次分解示意圖 需求開發(fā)可進(jìn)一步分為：?jiǎn)栴}獲取、分析、編寫規(guī)格說明和驗(yàn)證四個(gè)階段.這些子項(xiàng)包括軟件類產(chǎn)品中需求收集、評(píng)價(jià)、編寫文檔等所有活動(dòng).需求開發(fā)活動(dòng)包括以下幾個(gè)方面： 確定產(chǎn)品所期望的用戶類別. 獲取每個(gè)用戶類的需求. 了解實(shí)際用戶任務(wù)和目標(biāo)以及這些任務(wù)所支持的業(yè)務(wù)需求. 分析源于用戶的信息以區(qū)別用戶任務(wù)需求、功能需求、業(yè)務(wù)規(guī)則、質(zhì)量屬性、建議解決方法和附加信息. 將系統(tǒng)級(jí)的需求分為幾個(gè)子系統(tǒng)，并將需求中的一部份分配給軟件組件. 了解相關(guān)質(zhì)量屬性的重要性. 商討實(shí)施優(yōu)先級(jí)的劃分. 將所收集的用戶需求編寫成文檔和模型. 評(píng)審需求規(guī)格說明，確保對(duì)用戶需求達(dá)到共同的理解與認(rèn)識(shí)，并在整個(gè)開發(fā)小組接受說明之前將問題都弄清楚. 需求管理需要"建立并維護(hù)在軟件工程中同客戶達(dá)成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半，開發(fā)人員也必須能夠接受他們，并真正把需求應(yīng)用到產(chǎn)品中.通常的需求管理活動(dòng)包括： 定義需求基線（迅速制定需求文檔的主體）. 評(píng)審提出的需求變更、評(píng)估每項(xiàng)變更的可能影響從而決定是否實(shí)施它. 以一種可控制的方式將需求變更融入到項(xiàng)目中. 使當(dāng)前的項(xiàng)目計(jì)劃與需求一致. 估計(jì)變更需求所產(chǎn)生影響并在此基礎(chǔ)上協(xié)商新的承諾，這種承諾具體體現(xiàn)在項(xiàng)目解決方案上. 讓每項(xiàng)需求都能與其對(duì)應(yīng)的設(shè)計(jì)、源代碼和測(cè)試用例聯(lián)系起來以實(shí)現(xiàn)跟蹤. 在整個(gè)項(xiàng)目過程中跟蹤需求狀態(tài)及其。

8.需求分析有哪三種方法

它首先用結(jié)構(gòu)化分析（SA）對(duì)軟件進(jìn)行需求分析，然后用結(jié)構(gòu)化設(shè)計(jì)（SD）方法進(jìn)行總體設(shè)計(jì)，最后是結(jié)構(gòu)化編程（SP）。它給出了兩類典型的軟件結(jié)構(gòu)（變換型和事務(wù)型）使軟件開發(fā)的成功率大大提高。

三種基本的結(jié)構(gòu)形式就是順序、選擇和重復(fù)。三種數(shù)據(jù)結(jié)構(gòu)可以進(jìn)行組合，形成復(fù)雜的結(jié)構(gòu)體系。這一方法從目標(biāo)系統(tǒng)的輸入、輸出數(shù)據(jù)結(jié)構(gòu)入手，導(dǎo)出程序框架結(jié)構(gòu)，再補(bǔ)充其它細(xì)節(jié)，就可得到完整的程序結(jié)構(gòu)圖。這一方法對(duì)輸入、輸出數(shù)據(jù)結(jié)構(gòu)明確的中小型系統(tǒng)特別有效，如商業(yè)應(yīng)用中的文件表格處理。該方法也可與其它方法結(jié)合，用于模塊的詳細(xì)設(shè)計(jì)。