軟件工程導論——第三章——需求分析

文章目錄

• 軟件工程導論——第三章——需求分析
• • 1、需求分析的相關概念
  • • （1）定義：
    • （2）必要性：
    • （3）準則：
  • 2、需求分析的任務
  • • 1、確定系統的綜合要求
    • 2、分析系統的數據要求
    • 3、導出系統的邏輯模型
    • 4、修正系統開發計劃
  • 3、與用戶溝通獲取需求的方法
  • • （1）訪談
    • （2）面向數據流自頂向下求精
    • （3）簡易的應用規格說明技術
    • （4）快速建立軟件
  • 4、分析建模與規格說明
  • • 1、分析建模
    • 2、軟件需求規格說明
  • 5、實體-聯系圖
  • • 1、數據模型 的定義
    • 2、數據模型的構成
    • • （1）數據對象
      • （2）屬性
      • （3）聯系
    • 3、實體——聯系圖的符號
  • 6、數據規范化
  • • 1、必要性：
    • 2、范式特點：
    • 3、各范式的定義：
  • 7、狀態轉換圖
  • • 1、定義
    • 2、狀態
    • 3、事件
    • 4、狀態圖的符號
  • 8、層次方框圖
  • 9、驗證軟件需求
  • • 1、驗證軟件需求的正確性
    • 2、用于需求分析的軟件工具
  • 10、為什么要進行需求分析？通常對軟件系統有哪些需求？

1、需求分析的相關概念

（1）定義：

需求分析是軟件定義時期的最后一個階段，它的基本任務是準確地回答“系統必須做什么”這個問題，即對目標系統提出完整、準確、清晰、具體的要求。在需求分析階段結束之前，系統分析員應該寫出軟件需求規格說明書，以書面形式準確地描述軟件需求。

（2）必要性：

為了開發出真正滿足用戶需求的軟件產品，首先必須要知道用戶的需求。對軟件需求的深入理解是軟件開發工作獲得成功的前提，不了人們把設計和編碼工作做的多么出色，不能真正滿足用戶需求的程序只會令用戶失望，給開發者帶來煩惱。

（3）準則：

必須理解并描述問題的信息域，根據這條準則應該建立數據模型

必須定義軟件必須完成的功能，這條準則要求建立功能模型

必須描述外部事件結果的軟件行為，這條準則要求建立行為模型

必須對描述信息、功能和行為的模型進行分析，用層次的方式展示細節。

2、需求分析的任務

1、確定系統的綜合要求

功能需求：功能需求指定系統必須提供的服務。通過需求分析應該劃分出系統必須完成的所有功能。

性能需求：性能需求指定系統必須滿足的定時約束或容量約束，通常包括速度（響應時間）、信息量速率、主存儲量、磁盤容量、安全性等方面的需求

可靠性和可用性需求：可靠性需求定量地指定系統的可靠性；可用性欲可靠性密切相關，它量化了用戶可以使用系統的程度。

出錯處理需求：出錯處理需求說明系統對環境錯誤應該怎樣響應。在某些情況下，“出錯處理”指的是當應用系統發現他自己犯下一個錯誤時所采取的行動?？傊?#xff0c;對應用系統本身錯誤的檢測應該僅限于系統的關鍵部分，而且要你管管盡可能少。

接口需求：接口需求描述應用系統與他的環境通信的格式。常見的接口需求有：用戶接口需求，硬件接口需求，軟件接口需求，通信接口需求

約束：設計約束和實現約束描述在設計和實現應用系統時應該遵守的限制條件。常見的約束有：精度；工具和語言約束；設計約束；應該使用的標準，應該使用的硬件平臺

逆向需求：逆向需求通常說明軟件系統不應該做什么。理論上有無數個逆向需求，應該選取能澄清真實需求且可消除發生誤解的逆向需求。

將來可能提出的需求：目的是在設計過程中對系統將來可能的擴展和修改預先做好準備，以便一旦確定需要時能比較容易進行這種擴充和修改

2、分析系統的數據要求

（1）意義：任何一個軟件系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌。因此，必須分析系統的數據要求，這是軟件需求分析的一個重要任務。

（2）工具：分析系統的數據要求通常采用建立數據模型的方法。復雜的數據由許多基本的數據元素組成，數據結構表示數據元素之間的邏輯關系。利用數據字典可以全面準確的定義數據，但是數據字典的缺點是不夠直觀形象，

（3）規范：軟件系統經常使用各種長期保存的信息，為了減少數據冗余，避免出現插入異常和刪除異常，簡化修改數據的過程，通常需要把數據結構規范化。

3、導出系統的邏輯模型

4、修正系統開發計劃

3、與用戶溝通獲取需求的方法

（1）訪談

基本形式：

• 正式訪談：系統分析員將提出事先準備好的具體問題
• 非正式訪談：分析員將提出一些用戶可以自由回答的開放性問題，鼓勵被訪問任意說出自己的想法

技術方法：

• 調查表技術
• 情景分析技術：
  • 概念：
    • 情景分析是對用戶將來使用目標系統解決某個問題的方法和結果進行分析。系統分析員利用情景分析技術，往往能夠獲取用戶的具體需求
  • 作用：
    • 第一，能在某種程度上演示目標系統的行為，從而便于用戶理解，還可能進一步揭示出一些分析員目前還不知道的需求
    • 第二，使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色。

（2）面向數據流自頂向下求精

定義：
結構化分析方法是面向數據流自頂向下逐步求精進行需求分析的方法。通過可行性研究已經得出了目標系統的高層數據流圖，需求分析的目標之一就是把數據流和數據存儲定義到元素級。

（3）簡易的應用規格說明技術

（1）定義：簡易的應用規格說明技術是一種面向團隊的需求收集法。這種方法提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同解決方案并指定基本需求。是信息系統領域使用的主流技術。

（2）優點：

• 開發者與用戶不分彼此，齊心協力，密切合作
• 即時討論并求精，有能導出規格說明的具體步驟。

（4）快速建立軟件

（1）定義：快速原型是快速建立起來的旨在演示目標系統主要功能的可運行的程序。構建原型的要點是，它應該實現用戶看得見的功能，省略目標系統的隱含功能。快速建立軟件原型是最準確、最有效、最強大的需求分析技術。

（2）特性：

快速
快速原型的目的是盡快向用戶提供一個可在計算機上運行的目標系統的模型，以便使用戶和開發者在目標系統應該做什么，這個問題上盡可能快速的達成共識。因此，原型的某些缺陷是可以忽略的，只要這些缺陷不嚴重的損害原型的功能，不會使用戶對產品的行為產生誤解，就不必管他們。

容易修改：
如果原型的第一版不是用戶所需要的，就必須根據用戶的意見迅速的修改它，構建出原型的第二版，以更好地滿足用戶需求，在實際開發軟件產品時，原型的“修改試用反饋”過程可能重復多變，如果修改耗時過多，勢必會厭惡軟件開發時間

（3）使用的方法和工具

• 第四代技術
• 柯重陽的軟件構件
• 形式化規格說明和原型環境

4、分析建模與規格說明

1、分析建模

（1）模型：模型是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。模型由一組圖形符號和組織這些符號的規則組成。

（2）建模過程：
結構化分析實質上是一種創建模型的活動。為了開發出復雜的軟件系統，系統分析員應該從不同角度抽象目標系統的特性，使用精確的表示方法構造系統的模型，驗證模型是否滿足用戶對目標系統的需求，并在設計過程中逐漸把實現有關的細節加進模型中，直到最終用程序實現模型

2、軟件需求規格說明

軟件需求規格說明書是需求分析階段得出的最主要的文檔。通常用自然語言完整、準確、具體地描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。自然語言的規格說明具有很容易書寫、容易理解的優點。

5、實體-聯系圖

1、數據模型 的定義

為了把用戶的數據要求清楚、準確地描述出來，通常建立一個概念性的數據模型（信息模型）。概念性數據模型是一種面向問題的數據模型，是按照用戶的觀點對數據建立的模型。它描述了從用戶角度看到的數據，它反映了用戶的現實環境，而且與在軟件系統中的實現方法無關。

2、數據模型的構成

數據模型中包含3種相互關聯的信息：數據對象、數據對象的屬性及數據對象彼此間相互關聯的關系

（1）數據對象

定義：
數據對象是對軟件必須理解的復合信息的抽象。復合信息是指具有一系列不同性質或屬性的事物，僅有單個值的事物不是數據對象。

特點：

• 可由一組屬性來定義的實體都可以被認為是數據對象
• 數據對象彼此間是有關聯的。
• 數據對象只封裝了數據而沒有對施加于數據上的操作的引用，這也是數據對象與面向對象范型中的“類”或“對象”的顯著區別

（2）屬性

屬性定義了數據對象的性質。必須把一個或多個屬性定義為標識符，即當希望找到數據對象的一個實例時，用標識符屬性作為“關鍵字”。應該根據對所要解決的問題的理解，來確定特定數據對象的一組合適的屬性。

（3）聯系

數據對象彼此之間相互連接的方式稱為聯系，也稱為關系。聯系也可能有屬性。聯系可分為以下三種類型：

一對一聯系（1:1）

一對多聯系（1：N）

多對多聯系（M：N）

3、實體——聯系圖的符號

使用實體聯系圖來建立數據模型?？梢园褜嶓w─聯系圖簡稱為E—R圖，把用E—R圖描繪的數據模型稱為E—R模型。

E—R圖中包含了實體（數據對象)、關系和屬性3種基本成分，通常用矩形框代表實體，用連接相關實體的菱形框表示關系，用橢圓形或圓角矩形表示實體(或關系）的屬性，并用直線把實體（或關系）與其屬性連接起來。

6、數據規范化

1、必要性：

軟件系統與經常使用各種長期保存的信息，這些信息通常以一定方式組織并存儲在數據庫或文件中，為減少數據冗余，避免出現插入異常或刪除異常，簡化修改數據的過程，通常需要把數據結構規范化。

2、范式特點：

①通常用“范式”定義消除數據冗余的程度。第一范式數據冗余程度最大，第五范式數據冗余程度最小。

②范式級別越高，存儲同樣數據就要分解成更多張表，“存儲自身”的過程也就越復雜。

③隨著范式級別的提高，數據的存儲結構與基于問題域的結構間的匹配程度也隨之下降，故在需求變化時數據的穩定性較差。

④范式級別提高則需要訪問的表增多，因此性能將下降。一般選用第三范式都比較恰當

3、各范式的定義：

①第一范式每個屬性值都必須是原子值，即僅僅是一個簡單值而不含內部結構。

②第二范式滿足第一范式條件，而且每個非關鍵字屬性都由整個關鍵字決定。

③第三范式符合第二范式的條件，每個非關鍵字屬性都僅由關鍵字決定，而且一個非關鍵字屬性不能僅僅是對另一個非關鍵字屬性的進一步描述，即一個非關鍵字屬性值不依賴于另一個非關鍵字屬性值。

7、狀態轉換圖

1、定義

狀態轉換圖（狀態圖）通過描繪系統的狀態及引起系統狀態轉換的時間，來表示系統的行為，狀態圖還提供了行為建模機制，指明了作為特定事件的結果系統將做哪些動作。

2、狀態

（1）定義:

? 狀態是任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式。狀態規定了系統對事件的響應方式。系統對事件的響應，既可以是做一個（或做一系列）動作，也可以是僅僅改變系統本身的狀態，還可以是既改變狀態又做動作。

（2）分類：

狀態主要有：初態（初始狀態）、終態（最終狀態）和中間狀態。在一張狀態圖中只能有一個初態，而終態可以有0個或多個。

（3）表示：

狀態圖既可以表示系統循環運行過程，也可以表示系統單程生命周期。

• 描繪循環運行過程：通常并不關心循環是怎么啟動的
• 描繪單程生命周期：需要標明初始狀態和最終狀態。

3、事件

事件是在某個特定時刻發生的事情，它是對引起系統做動作或(和)從一個狀態轉換到另一個狀態的外界事件的抽象。簡而言之，事件就是引起系統做動作或轉換狀態的控制信息。

4、狀態圖的符號

（1）符號的表示方法

• 初態：用實心圓表示
• 終態：用一對同心圓（內圓為實心圓）表示
• 中間狀態：用圓角矩形表示，可以用兩條水平橫線把它分為上中下三個部分。上面部分為狀態的名稱，這部分是必須有的；中間部分阿偉狀態變量的名字和值，下面部分是活動表。

8、層次方框圖

（1）定義：

層次方框圖用樹形結構的一系列多層次的矩形描繪數據的層次結構，樹形結構的頂層是一個單獨的矩形框，它代表完整的數據結構，下面的各層矩形框代表這個數據的子集，最底層的各個框代表組成這個數據的實際數據元素。

（2）特點：

隨著結構的精細化，層次方框圖對數據結構也描繪得越來越詳細，這種模式非常適合需求分析階段的需要。系統分析員從頂層信息的分類開始，沿圖中每條路徑反復細化，直到確定了數據結構的全部細節為止。

9、驗證軟件需求

1、驗證軟件需求的正確性

（1）驗證需求正確性的目的

需求分析階段的工作結果是開發軟件系統的重要基礎。為了提高軟件質量，確保軟件開發成功，降低軟件開發成本，一旦對目標系統提出一組要求之后，必須嚴格驗證這些需求的正確性。

（2）進行驗證的四個方面

一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。

完整性：需求必須是完整的，規格說明書應該包含用戶需要的每一個功能或性能。

現實性：指定的需求應該是現有的硬件技術和軟件技術基本上可以實現的

有效性：必須證明需求是正確有效的，確實能解決用戶面對的問題。

2、用于需求分析的軟件工具

(1）要求
為了更有效地保證軟件需求的正確性，特別是為了保證需求的一致性，需要有適當的軟件工具支持需求分析工作。這類軟件工具應該滿足下列要求。
①必須有形式化的語法（或表)，因此可以用計算機自動處理使用這種語法說明的內容。

②使用這個軟件工具能夠導出詳細的文檔。

③必須提供分析（測試）規格說明書的不一致性和冗余性的手段，并且應該能夠產生一組報告指明對完整性分析的結果。

④使用這個軟件工具之后，應該能夠改進通信狀況。

10、為什么要進行需求分析？通常對軟件系統有哪些需求？

需求分析的原因：

為了開發真正滿足用戶需求的軟件產品，需求分析是軟件開發工作獲得成功的前提條件，不能滿足用戶需求的程序只會令用戶失望，給開發者帶來煩惱。

對軟件系統的需求：

功能需求、性能需求、可靠性和可用性需求、出錯處理、接口需求、約束、逆向需求、將來可能提出的要求。

總結

以上是生活随笔為你收集整理的软件工程导论——第三章——需求分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。