天天看點

[軟體工程導論(第六版)]第3章 需求分析(複習筆記)

文章目錄

    • 3.1 需求分析的任務
    • 3.2 與使用者溝通擷取需求的方法
    • 3.3 分析模組化與規格說明
    • 3.4 實體-聯系圖(E-R圖)
    • 3.5 資料規範化
    • 3.6 狀态轉換圖
    • 3.7 其他圖形工具
    • 3.8 驗證軟體需求
  • 需求分析是軟體定義時期的最後一個階段,需求分析的基本任務是準确的回答“系統必須做什麼”這個問題
  • 需求分析階段系統分析員需要寫出軟體需求規格說明書
  • 在需求分析階段通常建立資料模型(實體 -聯系圖( E-R 圖))、功能模型(資料流圖)、行為模型(狀态轉換圖是行為模型的基礎),資料字典成為把3種分析模型粘合在一起的“粘合劑”,是分析模型的核心。

3.1 需求分析的任務

  • 需求分析的定義
    • 需求分析是發現、求精、模組化、規格說明和複審的過程。
  • 需求分析的必要性
    • 為了開發出真正滿足使用者需求的成功的軟體産品,必須知道使用者的需求。
  • 需求分析的任務
    • (1)确定對系統的綜合要求;
      • (1)功能需求
      • (2)性能需求
      • (3)可靠性和可用性需求
      • (4)出錯處理需求
      • (5)接口需求
      • (6)限制
      • (7)逆向需求
      • (8)将來可能提出的要求
    • (2)分析系統的資料要求;
      • 資料結構表示資料元素之間的邏輯關系
      • 利用資料字典可以全面準确的定義資料(不夠形象直覺)
      • 在描繪系統中的資料結構,使用層次方框圖或Warnier圖等圖形工具。(提高可了解性)
    • (3)導出系統的邏輯模型;
      • 通常使用資料流圖、實體-聯系圖、狀态轉換圖、資料字典、主要的處理算法描述邏輯模型
    • (4)修正系統開發計劃。

3.2 與使用者溝通擷取需求的方法

  • 訪談
    • 正式訪談,系統分析員提出事先準備好的具體問題
    • 非正式訪談,分析員提出使用者可以自由回答的開放性問題
  • 面向資料流自頂向下求精
    • 先建立一個初步的系統功能模型,然後按照基本思想,自頂向下,逐漸對頂層資料流圖進行細分
    • 結構化分析方法就是面向資料流自頂向下逐漸求精進行需求分析的方法
  • 簡易的應用規格說明技術
    • 進行初步訪談;
    • 開發者和使用者分别寫出“産品需求”;
    • 標明會議的時間和地點,選舉協調人;
    • 邀請開發者和使用者雙方組織的代表出席會議;
    • 列出系統環境組成部分的對象、系統将産生的對象、系統為完成自己的功能将使用的對象,列出操作這些對象或與這些對象互動的服務,列出限制條件和性能标準;
    • 共同起草完整的軟體需求規格說明書
  • 快速建立軟體原型
    • 首先通過初步需求,快速建立一個系統原型;然後運作給使用者看,使用者根據原型提出自己的修改意見,最後程式開發者根據使用者的建議,對原型進行修改和完善。如此反複的疊代進行,知道最終建立一個滿足使用者需求的軟體系統為止
    • 特性:快速、容易修改
    • 快速建構和修改原型的方法和工具
      • 第四代技術
      • 可重用的軟體構件
      • 形式化規格說明和原型環境

3.3 分析模組化與規格說明

  • 分析模組化
    • (1)模型
      • 模型由一組圖形符号群組織這些符号的規則組成。
      • 為了了解事物而對事物作出的抽象
      • 對事物的一種無歧義的書面描述
    • (2)模組化過程
      • 結構化分析實質上是一種建立模型的活動,應從不同的角度抽象目标系統的特性。
    • 實體-聯系圖:描繪資料對象和資料對象之間的關系,用于建立資料模型的圖形
    • 資料流圖:描繪當資料在軟體系統中移動時被交換的邏輯過程,指明系統具有的變換資料的功能,資料流圖是建立功能模型的基礎
    • 狀态轉換圖:描繪了系統的各種行為模式(稱為狀态)和在不同狀态間轉換的方式,狀态轉換圖是行為模組化的基礎
  • 軟體需求規格說明
    • 軟體需求規格說明書是需求分析階段得出的最主要的文檔。

3.4 實體-聯系圖(E-R圖)

  • 資料模型的定義
    • 概念性資料模型(資訊模型)是一種面向問題的資料模型,是按照使用者的觀點對資料建立的模型。
  • 資料模型的構成
  • (1)資料對象
    • ① 定義
      • 資料對象是對軟體必須了解的複合資訊的抽象。
    • ② 特點
      • a.可以由一組屬性來定義的實體都可以被認為是資料對象。
      • b.資料對象彼此間是有關聯的。
      • c.資料對象隻封裝了資料而沒有對施加于資料上的操作的引用。
  • (2)資料對象的屬性(屬性)
    • 屬性定義了資料對象的性質。
  • (3)資料對象彼此間互相連接配接的關系(聯系)
    • 資料對象彼此之間互相連接配接的方式稱為聯系,也稱為關系。
    • 聯系也可能有屬性。
    • 聯系可分為以下3種類型
      • ① 一對一聯系(1:1)
      • ② 一對多聯系(1:N)
      • ③ 多對多聯系(M:N)
  • 實體-聯系圖(E-R圖)
    • 實體-聯系圖用于建立資料模型
    • ER圖描繪的資料模型稱為ER模型
    • ER圖的基本成分
      • E-R圖中包含了實體(資料對象)、關系和屬性3種基本成分
      • 通常用矩形框代表實體
      • 用連接配接相關實體的菱形框表示關系
      • 用橢圓形或圓角矩形表示實體(或關系)的屬性,并用直線把實體(或關系)與其屬性連接配接起來。
    • 優點
      • ① E-R模型比較接近人的習慣思維方式;
      • ② E-R模型使用簡單的圖形符号來描述問題,便于使用者了解。
    • ER模型可以作為使用者與分析員之間的交流工具
    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)

3.5 資料規範化

  • 資料規範化減少資料備援,避免出現插入異常或删除異常,簡化修改資料的過程
  • 使用範式消除資料備援的程度

3.6 狀态轉換圖

  • 定義
    • 狀态轉換圖(狀态圖)通過描繪系統的狀态及引起系統狀态轉換的事件,來表示系統的行為。
  • 狀态
    • (1)定義
      • 狀态是任何可以被觀察到的系統行為模式,一個狀态代表系統的一種行為模式。
    • (2)分類
      • 狀态主要有:初态(初始狀态)、終态(最終狀态)和中間狀态。
      • 【注意】在一張狀态圖中隻能有一個初态,而終态則可以有0至多個。描繪單程生命周期時需要标明初始狀态和最終狀态
  • 事件
    • 事件是在某個特定時刻發生的事情,是對引起系統做動作或從一個狀态轉換到另一個狀态的外界事件的抽象,是引起系統做動作或(和)轉換狀态的控制資訊。
  • 狀态圖的符号
    • (1)符号的表示方法
      • ① 初态:用實心圓表示。
      • ② 終态:用一對同心圓(内圓為實心圓)表示。
      • ③ 中間狀态:用圓角矩形表示。可以用兩條水準橫線把它分成上、中、下3個部分。上面部分為狀态的名稱,這部分是必須有的;中間部分為狀态變量的名字和值,下面部分是活動表。
    • (2)組成部分
      • 圖給出了狀态圖中使用的主要組成部分和符号表示。
        • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)
      • ① 活動表
        • 活動表的文法格式為:事件名(參數表)/動作表達式
        • 在活動表中經常使用下述3種标準事件:entry,exit和do。entry事件指定進入該狀态的動作;exit事件指定退出該狀态的動作;do事件則指定在該狀态下的動作。
      • ② 狀态轉換
        • 狀态圖中兩個狀态之間帶箭頭的連線稱為狀态轉換,箭頭指明了轉換方向。
        • 狀态如果由事件觸發,需要在狀态轉換的箭頭上标出觸發轉換的事件表達式,如果不是由事件觸發(執行完内部活動後自動觸發)則不用标明。
      • ③ 事件表達式
        • 事件表達式的文法為:事件說明[守衛條件]/動作表達式,其中,事件說明的文法為:事件名(參數表)。
        • 守衛條件是一個布爾表達式
  • 例子
    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)

3.7 其他圖形工具

  • 層次方框圖
    • 層次方框圖用樹形結構的一系列多層次的矩形框描繪資料的層次結構。
    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)
  • Warnier 圖
    • Warnier圖有以下三種基本符号:
      • ① 花括号:用來區分資料結構的層次,在一個花括号内的所有名字都屬于同一類資訊。
      • ② 異或符号:表明一類資訊或一個資料元素在一定條件下才出現。
      • ③ 圓括号中的數字:指明了這個名字代表的資訊類在這個資料結構中重複出現的次數。
    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)
  • IPO圖
  • (1)定義
    • IPO圖是輸入、處理、輸出圖的簡稱,能夠友善地描繪輸入資料、對資料的處理和輸出資料之間的關系。
  • (2)基本形式和用法
    • ① 左邊的框中列出有關的輸入資料;
    • ② 中間的框内列出主要的處理;
    • ③ 右邊的框内列出産生的輸出資料;
    • ④ 粗大箭頭指出資料通信的情況。
    • 處理框中列出處理的次序暗示了執行的順序。
    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)
  • (3)改進的IPO圖
    • 改進的IPO圖(IPO表)中包含某些附加的資訊。如圖3-2所示,改進的

      IPO圖中包含的附加資訊主要有系統名稱、圖的作者,完成的日期,本圖描述的子產品的名字,子產品在層次圖中的編号,調用本子產品的子產品清 單,本子產品調用的子產品的清單,注釋,以及本子產品使用的局部資料元素等。

    • [軟體工程導論(第六版)]第3章 需求分析(複習筆記)
  • 【注意】要區分并牢記給定圖形工具可用于軟體生命周期的哪一階段,此為常考題。本節三種圖形工具均可用于需求分析階段。

3.8 驗證軟體需求

  • 驗證軟體需求的正确性
    • (1)驗證需求正确性的目的
      • 為了提高軟體品質,確定軟體開發成功,降低軟體開發成本。
    • (2)進行驗證的四個方面
      • ① 一緻性,需求之間不能互相沖突;
      • ② 完整性,要實作每一個需求;
      • ③ 現實性,指定的需求是在現有的硬體技術和軟體技術的基礎上可以實作;
      • ④ 有效性,需求可以解決使用者面對的問題。
  • 驗證軟體需求的方法
    • (1)驗證需求的一緻性;
    • (2)驗證需求的現實性;
    • (3)驗證需求的完整性和有效性。
  • 用于需求分析的軟體工具——PSL/PSA系統
    • ① 定義
      • PSL是用來描述系統的形式語言,PSA是處理PSL描述的分析程式。
    • ② 功能
      • a.描述任何應用領域的資訊系統;
      • b.建立一個資料庫儲存對該資訊系統的描述符;
      • c.對描述符施加增加、删除和更改等操作;
      • d.産生格式化的文檔和關于規格說明書的各種分析報告。
    • ③ 優點
      • a.改進了文檔品質,能保證文檔具有完整性、一緻性和無二義性,進而可以- 減少管理和維護的費用;
      • b.資料存放在資料庫中,便于增加、删除和更改。

繼續閱讀