正文

需求分析的基本任務(wù)（需求分析的基本任務(wù)是準(zhǔn)確定義）

發(fā)布時間：2023-07-02 03:36:43 稿源：創(chuàng)意嶺閱讀： 1534

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于需求分析的基本任務(wù)的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

本文目錄:

1、需求分析的目的和主要任務(wù)是什么
2、什么是需求分析?結(jié)構(gòu)化分析的基本任務(wù)是什么?結(jié)構(gòu)化分析的步驟有哪些?
3、在建立系統(tǒng)的目標(biāo)之前，為什么必須分析問題的原因和結(jié)果
4、如何進(jìn)行軟件需求分析

一、需求分析的目的和主要任務(wù)是什么

用合適的方式跟用戶溝通，將用戶的需求用合適的方式進(jìn)行傳遞，幫助實現(xiàn)人員理解需求，并完成最終的用戶目標(biāo)。

二、什么是需求分析?結(jié)構(gòu)化分析的基本任務(wù)是什么?結(jié)構(gòu)化分析的步驟有哪些?

結(jié)構(gòu)化分析方法（Structured Method，結(jié)構(gòu)化方法）是強調(diào)開發(fā)方法的結(jié)構(gòu)合理性以及所開發(fā)軟件的結(jié)構(gòu)合理性的軟件開發(fā)方法。

結(jié)構(gòu)化分析方法給出一組幫助系統(tǒng)分析人員產(chǎn)生功能規(guī)約的原理與技術(shù)。它一般利用圖形表達(dá)用戶需求，使用的手段主要有數(shù)據(jù)流圖、數(shù)據(jù)字典、結(jié)構(gòu)化語言、判定表以及判定樹等。

它的設(shè)計原則包括：

使每個模塊執(zhí)行一個功能（堅持功能性內(nèi)聚）

每個模塊用過程語句（或函數(shù)方式等）調(diào)用其他模塊

模塊間傳送的參數(shù)作數(shù)據(jù)用

模塊間共用的信息（如參數(shù)等）盡量少

三、在建立系統(tǒng)的目標(biāo)之前，為什么必須分析問題的原因和結(jié)果

需求分析奠定了軟件工程和項目管理的基礎(chǔ)。我們在建造軟件系統(tǒng)這座大廈的時候，如果需求分析的基礎(chǔ)不夠堅實和牢固，那么往往會導(dǎo)致軟件系統(tǒng)問題百出，甚至被馬上丟棄。在建造軟件系統(tǒng)的過程中，如果我們經(jīng)常習(xí)慣地沿用一些不規(guī)范的方法，其后果便是產(chǎn)生一條鴻溝──開發(fā)者開發(fā)的與用戶所想得到的軟件存在著巨大的“期望差異”。因此“需求”這個名詞的定義不僅僅是從用戶角度對系統(tǒng)外部行為的描述，以及從開發(fā)人員角度對系統(tǒng)內(nèi)部特性的描述，其關(guān)鍵的一點是“需求”必須文檔化。

需求的類型

軟件需求包括三個不同的層次──業(yè)務(wù)需求、用戶需求和功能需求。除此之外，每個系統(tǒng)還有各種非功能需求。

業(yè)務(wù)需求（BusinessRequirement）表示組織或客戶高層次的目標(biāo)。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達(dá)到的目標(biāo)。使用前景和范圍（vision and scope）文檔來記錄業(yè)務(wù)需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。用戶需求（UserRequirement）描述的是用戶的目標(biāo)，或用戶要求系統(tǒng)必須能完成的任務(wù)。用例、場景描述和事件響應(yīng)表都是表達(dá)用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統(tǒng)來做些什么。

功能需求（Functional Requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習(xí)慣上總是用“應(yīng)該”對其進(jìn)行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來通知用戶已接受其預(yù)定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。

非功能需求（Non-functional Requirement）定義了軟件產(chǎn)品為滿足用戶業(yè)務(wù)需求而必須具有的除功能需求以外的特性。包括系統(tǒng)的完整性（聯(lián)機幫助、數(shù)據(jù)管理、用戶管理、軟件發(fā)布管理、在線升級等）、性能、可靠性、可維護(hù)性、可擴充性、對技術(shù)和業(yè)務(wù)的適應(yīng)性等。

需求分析的任務(wù)

1 解決的問題

1) 齊全、準(zhǔn)確地找出目標(biāo)系統(tǒng)全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；

4) 產(chǎn)生完整的分層的DFD、數(shù)據(jù)字典、加工的描述； 5) 補充的意見。

2 綜合要求

確定對系統(tǒng)的綜合要求，系統(tǒng)功能要求，系統(tǒng)性能要求，運行要求，將來可能提出的要求。

3 任務(wù)

圖1為需求分析任務(wù)圖，需求分析階段要完成的具體明確的最終任務(wù)就是形成一份經(jīng)開發(fā)方和用戶認(rèn)可或達(dá)成共識的軟件需求分析文檔（需求規(guī)格說明書、修改后的項目開發(fā)計劃、初步的用戶手冊、確認(rèn)測試計劃、數(shù)據(jù)要求說明書）。這個文檔能清晰準(zhǔn)確地說明系統(tǒng)將要開發(fā)什么，能夠規(guī)定出詳細(xì)的技術(shù)需求，包括所有面向用戶、面向機器和其它軟件系統(tǒng)的接口?？梢哉f需求文檔在開發(fā)過程中一直起指導(dǎo)作用。

為了更好地完成軟件開發(fā)第一階段的需求分析任務(wù)，提高質(zhì)量，需求管理是必不可少的。

需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其他工作成果的一致性，并控制需求的變更，主要體現(xiàn)在跟蹤和控制需求變更管理。需求管理是開發(fā)工作有效進(jìn)行的保證，是一種很高層次的系統(tǒng)行為，涉及整個開發(fā)過程和產(chǎn)品本身。

需求分析的方法

需求分析方法由對軟件問題的信息域和功能域的系統(tǒng)分析過程及其表示方法組成，大多數(shù)的需求分析方法是由信息驅(qū)動的。信息域具有三種屬性：信息流、信息內(nèi)容和信息結(jié)構(gòu)。

常用的需求分析方法有：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA），面向數(shù)據(jù)結(jié)構(gòu)的Jackson方法（JSD），面向數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)化數(shù)據(jù)系統(tǒng)開發(fā)方法（DSSD），面向?qū)ο蟮姆治龇椒ǎ∣OA）等。選擇那種方法要根據(jù)哪些資源在什么時間對開發(fā)人員有效，不能盲目套用。這里著重闡述面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（SA）。

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法

面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法（Structured Analysis，簡稱SA），是面向數(shù)據(jù)流進(jìn)行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建?；顒?，該方法使用簡單易讀符號，根據(jù)軟件內(nèi)部數(shù)據(jù)傳遞、變換的關(guān)系，自頂向下逐層分解，描繪出滿足功能要求的軟件模型。適用于數(shù)據(jù)處理類型軟件的需求分析，這一方法除了簡單，容易掌握之外，還能和設(shè)計階段的結(jié)構(gòu)化設(shè)計（SD）銜接，從而取得良好的設(shè)計結(jié)果。

自頂向下逐層分解的分析策略

SA方法的基本手段：“分解”和“抽象”。這是系統(tǒng)開發(fā)技術(shù)中控制復(fù)雜性的兩種手段。它先將系統(tǒng)“抽象”成一個模型，此模型是有輸入和輸出并有系統(tǒng)名稱的盒子，然后打開這個盒子，對它進(jìn)行逐層分解，直到能被理解，可以實現(xiàn)為止。因此分析的策略是自頂向下，逐層加細(xì)，由抽象到具體的過程。如圖2。

結(jié)構(gòu)化分析方法使用工具

SA方法利用圖形等半形式化的描述方式表達(dá)需求，簡明易懂，用它們形成需求規(guī)格說明書中的主要部分。描述工具是

1) 數(shù)據(jù)流圖：描述系統(tǒng)由哪幾部分組成，各部分之間有什么聯(lián)系等等。 2) 數(shù)據(jù)字典：定義了數(shù)據(jù)流圖中每一個圖形元素。

3) 描述加工邏輯的結(jié)構(gòu)化語言、判定表、判定樹：詳細(xì)描述數(shù)據(jù)流圖中不能被再分解的每一個加工。

由于分析中的主要依據(jù)是數(shù)據(jù)傳遞及數(shù)據(jù)變換所形成的數(shù)據(jù)流，所以結(jié)構(gòu)化分析一般采用的方法是使用數(shù)據(jù)流圖的分析方法，最終結(jié)果是產(chǎn)生需求規(guī)格說明書，該文檔包括一套數(shù)據(jù)流圖，對數(shù)據(jù)流圖中的成分進(jìn)行定義的一本數(shù)據(jù)字典及對加工邏輯的描述。

結(jié)構(gòu)化分析步驟

用結(jié)構(gòu)化分析方法進(jìn)行系統(tǒng)需求分析的具體步驟是： 1) 了解當(dāng)前系統(tǒng)的工作流程，獲得當(dāng)前系統(tǒng)的物理模型。通過對當(dāng)前系統(tǒng)的詳細(xì)調(diào)查，了解當(dāng)前系統(tǒng)的工作過程，同時收集資料、文件、數(shù)據(jù)、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當(dāng)前系統(tǒng)的理解，如畫系統(tǒng)流程圖。

2) 抽象出當(dāng)前系統(tǒng)的邏輯模型。物理模型反映了系統(tǒng)“怎么做”的具體實現(xiàn)，去掉物理模型中非本質(zhì)的因素，抽取出本質(zhì)的因素，構(gòu)造出當(dāng)前系統(tǒng)的邏輯模型，反映了當(dāng)前系統(tǒng)“做什么”的功能。

3) 建立目標(biāo)系統(tǒng)的邏輯模型。分析、比較目標(biāo)系統(tǒng)與當(dāng)前系統(tǒng)邏輯上的差別，明確目標(biāo)系統(tǒng)到底要“做什么”，從而從當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型。

4) 作進(jìn)一步補充和優(yōu)化。為了對目標(biāo)系統(tǒng)做完整的描述，還需要對得到的邏輯模型做一些補充。

說明目標(biāo)系統(tǒng)的人機界面。

說明至今尚未詳細(xì)考慮的細(xì)節(jié)（包括出錯處理、系統(tǒng)的啟動與結(jié)束、系統(tǒng)的輸入/輸出和系統(tǒng)性能方面的需求等）。

其他（系統(tǒng)特有的其他必須滿足的性能和限制，也需要用適當(dāng)?shù)男问阶龀鰰嬗涗洝?分析階段結(jié)束時，系統(tǒng)分析員必須和用戶再次認(rèn)真地審查系統(tǒng)文件，爭取在系統(tǒng)開始設(shè)計之前，盡可能地發(fā)現(xiàn)其中存在的一些錯誤并及時糾正，直至用戶確認(rèn)這個模型表達(dá)了他們的要求后，系統(tǒng)文件（軟件需求規(guī)格說明書等）才作為用戶和軟件開發(fā)人員之間的“合同”而最后得到確定。

結(jié)構(gòu)化分析方法的優(yōu)缺點

1) 優(yōu)點：結(jié)構(gòu)化分析方法是軟件需求分析中公認(rèn)的、有成效的、技術(shù)成熟的、使用廣泛的一種方法，它較適合于開發(fā)數(shù)據(jù)處理類型軟件的需求分析，該方法利用圖形等半形式化工具表達(dá)需求，簡明易讀，也易于使用，為后一階段的設(shè)計、測試、評價提供了有利條件。 2) 缺點：① 傳統(tǒng)的SA方法主要用于數(shù)據(jù)處理方面的問題，主要工具DFD體現(xiàn)了系統(tǒng)“做什么”的功能，但它僅是一個靜態(tài)模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統(tǒng)。② 上世紀(jì)60年代末出現(xiàn)的數(shù)據(jù)庫技術(shù)，使許多大型數(shù)據(jù)處理系統(tǒng)中的數(shù)據(jù)都組織成數(shù)據(jù)庫的形式，SA方法使用DFD在分析與描述“數(shù)據(jù)要求”方面是有局限的，DFD應(yīng)與數(shù)據(jù)庫技術(shù)中的實體聯(lián)系圖(ER圖)結(jié)合起來(如同IDEF0功能模型與IDEF1信息模型相結(jié)合一樣)。ER圖能增加對數(shù)據(jù)存儲的細(xì)節(jié)以及數(shù)據(jù)與數(shù)據(jù)之間，數(shù)據(jù)與處理過程之間關(guān)系的理解，還解決了在DD中所包含的數(shù)據(jù)內(nèi)容表示問題，這樣才能較完整的描述用戶對系統(tǒng)的需求。③ 對于一些頻繁的人機交互的軟件系統(tǒng)，如飛機訂票、銀行管理等系統(tǒng)，用戶最關(guān)系的是如何使用它，輸入命令、操作方式、系統(tǒng)響應(yīng)方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統(tǒng)的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟件需求的精確性有待提高。 5 需求的變更

在開發(fā)項目過程中，用戶隨時會提出一些新的需求，要求開發(fā)方解決，這些需求的提出，有時在開發(fā)階段中有時在開發(fā)階段后。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，后一段或周期的需求分析結(jié)果與前一次不一致，我們把這種不一致稱為需求變更。產(chǎn)生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發(fā)方與用戶的溝通不夠。在需求分析階段，開發(fā)方與用戶沒有很好的交流，開發(fā)方就根據(jù)用戶提供的大概信息，自己推導(dǎo)出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠(yuǎn)，導(dǎo)致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統(tǒng)的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術(shù)更新過快。由于技術(shù)的快速更新，企業(yè)可能引進(jìn)一些新的設(shè)備，而這些設(shè)備可能就會與我們的目標(biāo)系統(tǒng)有直接的關(guān)系，由于這一變化可能發(fā)生在解決用戶原先問題之前或者之中，那么開發(fā)方不得不加入這一新的需求。[3]

為了盡可能地避免發(fā)生需求變更，以及保證需求分析的高穩(wěn)定性，可以采用以下方法：1) 分工明確，系統(tǒng)分析員和程序員各有不同的職責(zé)。系統(tǒng)分析員處在用戶和程序員之間，溝通用戶和開發(fā)人員的認(rèn)識和見解。系統(tǒng)分析員一方面要協(xié)助用戶對所開發(fā)的軟件提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現(xiàn)的可能性。如圖3所示，系統(tǒng)分析員在需求分析階段起著重要的作用。

2) 開發(fā)方與用戶進(jìn)行協(xié)作和交流。在用戶提出需求變更時系統(tǒng)分析員應(yīng)該認(rèn)真聽取用戶的要求并加以整理和分析。分析需求變更的原因并提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發(fā)帶來的不良后果。3) 合同約束。由于需求變更可能會對整個項目產(chǎn)生影響，所以，開發(fā)方和用戶在簽定項目合同時，可以對需求變更增加一些相關(guān)的合同條款。4) 建立需求文檔并進(jìn)行版本控制。需求分析的最終成果是一份客戶和開發(fā)方對所開發(fā)的產(chǎn)品達(dá)成共識的系統(tǒng)文檔。有了這份文檔，即使開發(fā)方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標(biāo)識。5) 需求評審和設(shè)立需求基線。為了讓開發(fā)方詳細(xì)了解用戶的需求，讓不同人員從不同的角度對需求進(jìn)行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進(jìn)行最后確認(rèn)的機會，可以有效減少需求變更的發(fā)生。需求在通過正式評審和批準(zhǔn)之后，應(yīng)該確定需求基線，進(jìn)一步的需求變更將在此基線的基礎(chǔ)上，依照項目定義的變更過程進(jìn)行。設(shè)置需求基線可以將變更引起的麻煩減至最小。

軟件架構(gòu)（software

architecture）是一系列相關(guān)的抽象模式，用于指導(dǎo)大型軟件系統(tǒng)各個方面的設(shè)計。軟件架構(gòu)是一個系統(tǒng)的草圖。軟件架構(gòu)描述的對象是直接構(gòu)成系

統(tǒng)的抽象組件。各個組件之間的連接則明確和相對細(xì)致地描述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細(xì)化為實際的組件，比如具體某個類或者對象。在面向

對象領(lǐng)域中，組件之間的連接通常用接口_(計算機科學(xué))來實現(xiàn)。

軟件體系結(jié)構(gòu)是構(gòu)建計算機軟件實踐的基礎(chǔ)。與建筑師設(shè)定建筑項目的設(shè)計原則和目標(biāo)，作為繪圖員畫圖的基礎(chǔ)一樣，一個軟件架構(gòu)師或者系統(tǒng)架構(gòu)師陳述軟件構(gòu)架以作為滿足不同客戶需求的實際系統(tǒng)設(shè)計方案的基礎(chǔ)。

軟件構(gòu)架是一個容易理解的概念，多數(shù)工程師（尤其是經(jīng)驗不多的工程師）會從直覺上來認(rèn)識它，但要給出精確的定義很困難。特別是，很難明確地區(qū)分設(shè)計和構(gòu)架：構(gòu)架屬于設(shè)計的一方面，它集中于某些具體的特征。

在“軟件構(gòu)架簡介”中，David Garlan 和 Mary Shaw

認(rèn)為軟件構(gòu)架是有關(guān)如下問題的設(shè)計層次：“在計算的算法和數(shù)據(jù)結(jié)構(gòu)之外，設(shè)計并確定系統(tǒng)整體結(jié)構(gòu)成為了新的問題。結(jié)構(gòu)問題包括總體組織結(jié)構(gòu)和全局控制結(jié)

構(gòu)；通信、同步和數(shù)據(jù)訪問的協(xié)議；設(shè)計元素的功能分配；物理分布；設(shè)計元素的組成；定標(biāo)與性能；備選設(shè)計的選擇。

但構(gòu)架不僅是結(jié)構(gòu)；IEEE Working Group

on Architecture 把其定義為“系統(tǒng)在其環(huán)境中的最高層概念”。構(gòu)架還包括“符合”系統(tǒng)完整性、經(jīng)濟(jì)約束條件、審美需求和樣式。它并不僅注

重對內(nèi)部的考慮，而且還在系統(tǒng)的用戶環(huán)境和開發(fā)環(huán)境中對系統(tǒng)進(jìn)行整體考慮，即同時注重對外部的考慮。

在Rational Unified Process 中，軟件系統(tǒng)的構(gòu)架（在某一給定點）是指系統(tǒng)重要構(gòu)件的組織或結(jié)構(gòu)，這些重要構(gòu)件通過接口與不斷減小的構(gòu)件與接口所組成的構(gòu)件進(jìn)行交互。

從和目的、主題、材料和結(jié)構(gòu)的聯(lián)系上來說，軟件架構(gòu)可以和建筑物的架構(gòu)相比擬。一個軟件架構(gòu)師需要有廣泛的軟件理論知識和相應(yīng)的經(jīng)驗來事實和管

理軟件產(chǎn)品的高級設(shè)計。軟件架構(gòu)師定義和設(shè)計軟件的模塊化，模塊之間的交互，用戶界面風(fēng)格，對外接口方法，創(chuàng)新的設(shè)計特性，以及高層事物的對象操作、邏輯

和流程。

一般而言，軟件系統(tǒng)的架構(gòu)（Architecture）有兩個要素：

它是一個軟件系統(tǒng)從整體到部分的最高層次的劃分。

一個系統(tǒng)通常是由元件組成的，而這些元件如何形成、相互之間如何發(fā)生作用，則是關(guān)于這個系統(tǒng)本身結(jié)構(gòu)的重要信息。

詳細(xì)地說，就是要包括架構(gòu)元件（Architecture Component）、聯(lián)結(jié)器（Connector）、任務(wù)流（Task-flow）。

所謂架構(gòu)元素，也就是組成系統(tǒng)的核心"磚瓦"，而聯(lián)結(jié)器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預(yù)期結(jié)果，任務(wù)流則描述系統(tǒng)如何使用這些元件和

聯(lián)結(jié)器完成某一項需求。

建造一個系統(tǒng)所作出的最高層次的、以后難以更改的，商業(yè)的和技術(shù)的決定。

建造一個系統(tǒng)之前會有很多的重要決定需要事先作出，而一旦系統(tǒng)開始進(jìn)行詳細(xì)設(shè)計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關(guān)系統(tǒng)設(shè)計成敗的最重要決定，必須經(jīng)過非常慎重的研究和考察。

對于較大的通常應(yīng)用應(yīng)該使用框架，可能節(jié)省不少時間.。能使你很輕松的開發(fā)出一款軟件來。

四、如何進(jìn)行軟件需求分析

軟件需求分析免費下載

鏈接:https://pan.baidu.com/s/1qNBwqvbRS5ziBSIeanLQAQ

提取碼:qoyw

需求分析也稱為軟件需求分析、系統(tǒng)需求分析或需求分析工程等，是開發(fā)人員經(jīng)過深入細(xì)致的調(diào)研和分析，準(zhǔn)確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉(zhuǎn)化為完整的需求定義，從而確定系統(tǒng)必須做什么的過程。

以上就是關(guān)于需求分析的基本任務(wù)相關(guān)問題的回答。希望能幫到你，如有更多相關(guān)問題，您也可以聯(lián)系我們的客服進(jìn)行咨詢，客服也會為您講解更多精彩的知識和內(nèi)容。