《軟件工程導論》第3章-需求分析-重點總結

這一章節非常重要！！！
尤其是裏面的E-R圖、數據流圖，狀態裝換圖的畫法，非常的重要！！！

第3章 需求分析

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

需求分析是軟件定義時期的最後一個階段，它的基本任務是準確地回答“系統必須做什麼” 這個問題。

需求分析的任務是還不是決定系統怎樣完成它的工作，僅僅是確定系統必須完成哪些工作。

需求分析的四個準則：

1. 必須理解並描述問題的信息域，根據這條準則應該建立數據模型。
2. 必須定義軟件應完成的功能，這條準則要求建立功能模型。
3. 必須描述作爲外部事件結果的軟件行爲，這條準則要求建立行爲模型。
4. 必須對描述信息、功能和行爲的模型進行分解，用層次的方式展示細節。

3.1 需求分析的任務

3.1.1 確定對系統的綜合要求

雖然功能需求是對軟件系統的一項基本需求，但卻並不是唯一的需求。通常對軟件系統有下述幾方面的綜合要求。

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

① 功能需求

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

② 性能需求

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

③ 可靠性和可用性需求

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

④ 出錯處理需求

這類需求說明系統對環境錯誤應該怎樣響應。
例如，如果它接收到從另一個系統發來的違反協議格式的消息，應該做什麼？

⑤ 接口需求

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

⑥ 約束

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

⑦ 逆向需求

逆向需求說明軟件系統不應該做什麼。 理論上有無限多個逆向需求，人們應該僅選取能澄清真實需求且可消除可能發生的誤解的那些逆向需求。

⑧ 將來可能提出的要求

應該明確地列出那些雖然不屬於當前系統開發範疇，但是據分析將來很可能會提出來的要求。
這樣做的目的是，在設計過程中對系統將來可能的擴充和修改預做準備， 以便一旦確實需要時能比較容易地進行這種擴充和修改。

3.1.2 分析系統的數據要求

任何一個軟件系統本質上都是信息處理系統，系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌，對軟件設計有深遠影響。
因此，必須分析系統的數據要求，這是軟件需求分析的一個重要任務。
利用數據字典可以全面準確地定義數據，但是數據字典的缺點是不夠形象直觀。
爲了提高可理解性，常常利用圖形工具輔助描繪數據結構。
常用的圖形工具有層次方框圖、Warnier圖。

3.1.3 導出系統的邏輯模型

綜合上述兩項分析的結果可以導出系統的詳細的邏輯模型。
通常用數據流圖、實體-聯繫圖、狀態轉換圖、數據字典和主要的處理算法描述這個邏輯模型。

3.1.4 修正系統開發計劃

根據在分析過程中獲得的對系統的更深入更具體的瞭解，可以比較準確地估計系統的成本和進度，修正以前制定的開發計劃。

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

3.2.1 訪談

訪談是最早開始使用的獲取用戶需求的技術，也是迄今爲止仍然廣泛使用的需求分析技術。
訪談有兩種基本形式，分別是正式的和非正式的訪談。

• 正式訪談時，系統分析員將提出一些事先準備好的具體問題。
  例如，詢問客戶公司銷售的商品種類、僱用的銷售人員數目以及信息反饋時間應該多快等。
• 在非正式訪談中，分析員將提出一些用戶可以自由回答的開放性問題， 以鼓勵被訪問人員說出自己的想法。
  例如，詢問用戶對目前正在使用的系統有哪些不滿意的地方。

當需要調查大量人員的意見時，向被調查人分發調查表是一個十分有效的做法。

在訪問用戶的過程中使用情景分析技術往往非常有效。所謂情景分析就是對用戶將來使用目標系統解決某個具體問題的方法和結果進行分析。

情景分析技術的用處主要體現在下述兩個方面。

• （1）它能在某種程度上演示目標系統的行爲，從而便於用戶理解，而且還可能進一步揭示出一些分析員目前還不知道的需求。
• （2）由於情景分析較易爲用戶所理解，使用這種技術能保證用戶在需求分析過程中始終扮演一個積極主動的角色。

3.2.2 面向數據流自頂向下求精

結構化分析方法的實質：
面向數據流自頂向下逐步求精進行需求分析的方法。
通過可行性研究已經得出了目標系統的高層數據流圖。

數據流圖是幫助複查的極好工具，從輸入端開始，分析員藉助數據流圖、數據字典和IPO圖向用戶解釋輸入數據是怎樣一步一步地轉變成輸出數據的。
這些解釋集中反映了通過前面的分析工作分析員所獲得的對目標系統的認識。

隨着分析過程的進展，經過提問和解答的反覆循環，分析員越來越深入具體地定義了目標系統，最終得到對系統數據和功能要求的滿意瞭解。

面向數據流自頂向下求精過程：

3.2.3 簡易的應用規格說明技術

簡易的應用規格說明技術是爲了解決使用傳統的訪談或面向數據流自頂向下求精方法定義需求時，用戶處於被動地位而且往往有意無意地與開發者區分“彼此”。
由於不能像同一個團隊的人那樣齊心協力地識別和精化需求，這兩種方法的效果有時並不理想，經常發生誤解、還可能遺漏重要信息。
爲解決上述問題，提出面向團隊的需求收集發；
面向團隊的需求收集法，稱爲簡易的應用規格說明技術。
提倡用戶與開發者密切合作，共同標識問題，提出解決方案要素，商討不同方案並指定基本需求。

簡易的應用規格說明技術分析需求的典型過程如下：

1. 進行初步的訪談
2. 開發者和用戶分別寫出“產品需求”。
3. 開會討論，各自展示需求列表
4. 得出了意見一致，爲需求列表制定小型規格說明
5. 根據會議結果，起草完整的軟件需求規格說明

3.2.4 快速建立軟件原型

快速原型就是快速建立起來的旨在演示目標系統主要功能的可運行的程序，快速原型應該具備的特性：

• 快速原型應該具備的第一個特性是“快速”。
• 快速原型應該具備的第二個特性是“容易修改”。

爲了快速地構建和修改原型，通常使用下述3種方法和工具。

1. 第四代技術
   包括衆多數據庫查詢和報表語言、程序和應用系統生成器以及其他非常高級的非過程語言。
2. 可重用的軟件構件
   使用一組已有的軟件構件來裝配原型。
3. 形式化規格說明和原型環境
   人們已經研究出許多形式化規格說明語言和工具（第4章），用於替代自然語言規格說明技術。用戶能夠使用可執行的原型代碼去進一步精化形式化的規格說明。

3.3 分析建模與規格說明

3.3.1 分析建模

模型，就是爲了理解事物而對事物作出的一種抽象，是對事物的一種無歧義的書面描述。

爲了開發複雜的系統，應從不同角度（模型）抽象出目標系統的特性（數據模型、功能模型、行爲模型）

儘管目前有許多不同的用於需求分析的結構化分析方法，但是，所有這些分析方法都遵守4條準則。

1. 必須理解並描述問題的信息域，根據這條準則應該建立數據模型。
2. 必須定義軟件應完成的功能，這條準則要求建立功能模型。
3. 必須描述作爲外部事件結果的軟件行爲，這條準則要求建立行爲模型
4. 必須對描述信息、功能和行爲的模型進行分解，用層次的方式展示細節。

3種建模的圖形工具：

• 實體-聯繫圖，描繪數據對象及數據對象之間的關係，是用於建立數據模型的圖形。
• 數據流圖是建立功能模型的基礎。描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功能
• 狀態轉換圖（狀態圖）描繪了系統的各種行爲模式和在不同狀態間轉換的方式。狀態轉換圖是行爲建模的基礎。
  

3.3.2 軟件需求規格說明

通過需求分析，除了創建分析模型之外，還應該寫出軟件需求規格說明書，它是需求分析階段得出的最主要的文檔。

通常用自然語言完整、準確、具體地描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。
自然語言的規格說明具有容易書寫、容易理解的優點，爲大多數人歡迎和採用。

3.4 實體聯繫圖（☆☆☆☆☆）

使用實體-聯繫圖建立數據模型；
實體-聯繫圖簡稱E-R圖(Entity Relationship Diagram)，
ER圖描繪的數據模型稱爲ER模型。

數據模型中包含3種相互關聯的信息：

• 實體（數據對象）
• 數據對象的屬性
• 數據對象彼此間相互連接的關係。

3.4.1 數據對象

數據對象是對軟件必須理解的複合信息的抽象。

數據對象可以是外部實體（例如產生或使用信息的任何事物）、事物（例如報表）、行爲（例如打電話）、事件（例如響警報）、角色（例如教師、學生）、單位（例如會計科）、地點（例如倉庫）或結構（例如文件）等。

總之，可以由一組屬性來定義的實體都可以被認爲是數據對象。

3.4.2 屬性

屬性定義了數據對象的性質。
必須把一個或多個屬性定義爲“標識符”，也就是說，當人們希望找到數據對象的一個實例時，用標識符屬性作爲“關鍵字”(通常簡稱爲“鍵”)。

3.4.3 聯繫

客觀世界中的事物彼此間往往是有聯繫的。
數據對象彼此之間相互連接的方式稱爲聯繫，也稱爲關係。聯繫可分爲以下3種類型。

1. 一對一聯繫(1∶1)
   例如，一個部門有一個經理，而每個經理只在一個部門任職，則部門與經理的聯繫是一對一的。
2. 一對多聯繫(1∶N)
   例如，某校教師與課程之間存在一對多的聯繫“教”，即每位教師可以教多門課程，但是每門課程只能由一位教師來教。
3. 多對多聯繫(M∶N)
   例如，學生與課程間的聯繫(“學”)是多對多的，即一個學生可以學多門課程，而每門課程可以有多個學生來學。

3.4.4 實體-聯繫圖的符號

• 實體：用矩形框代表實體
  
• 屬性：用橢圓形或圓角矩形表示實體(或關係)的屬性
  
• 菱形：用連接相關實體的菱形框表示關係
  

ER模型可以作爲用戶與分析員之間有效的交流工具。

例如，某學校教學管理E-R圖：

3.4.5 實例1

請爲某倉庫的管理設計一個ER模型，該倉庫主要管理零件的訂購和供應等事項。倉庫向工程項目供應零件，並且根據需要向供應商訂購零件。“零件”的主要屬性是:零件編號，零件名稱，顏色，重量。“工程項目” 的屬性主要是:項目編號，項目名稱，開工日期。“供應商” 的屬性主要有:供應商編號，供應商名稱，地址。

3.4.6 實例2

某圖書借閱管理系統，數據庫中有三個實體集。
一是“書籍”實體集，屬性有書號、類型、數量等；
二是“出版社”實體集，屬性有出版社名、電話、Email、郵編等；
三是“借書人”實體集，屬性有借書證號、姓名、單位等。
出版社與書籍間存在“出版”聯繫，一個出版社可出版多種書籍，同一本書僅爲一個出版社出版；
書籍和借書人間存在“借還”聯繫，每個借書人可以借閱多種書籍，每種書籍可以被多個借閱人借閱；每一個借書人借閱書籍都有對應的借書日期、還書日期。
試畫出E-R圖，並在圖上註明屬性、聯繫的類型。

3.5 數據流圖（☆☆☆☆☆）

數據流圖(DFD)是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。
數據流圖建立軟件系統的功能模型。
在數據流圖中沒有任何具體的物理部件，它只是描繪數據在軟件中流動和被處理的邏輯過程，即使不是專業的計算機技術人員也容易理解它，因此是分析員與用戶之間極好的通信工具。

3.5.1 符號

數據流圖的4種基本符號：

• 正方形表示數據的源點或終點：人員、部門、計算機外部設備或傳感器裝置
• 圓角矩形代表變換數據的處理：.系列程序、單個程序或程序-一個模塊;人工處理過程。
• 開口矩形代表數據存儲：文件、文件一部分、數據庫元素或記錄一部分，可存在磁盤、磁帶、磁鼓、主存、微縮膠片任何介質上。
• 箭頭表示數據流，即特定數據的流動方向：在處理之間有向流動的數據項或數據集合。

一個簡單的數據流圖：

附加符號：

3.5.2 實例

工廠採購部採購員每天需要一張訂貨報表，報表按零件編號排序，表中列出所有需要再次訂貨的零件。
對訂貨零件列出下述數據：零件編號，零件名稱，訂貨數量，目前價格，主要供應者，次要供應者。
零件入庫或出庫稱爲事務，通過倉庫CRT終端把事務報告給訂貨系統。
當某種零件的庫存數量少於庫存量臨界值時就應該再次訂貨。

1.首先考慮數據的源點和終點
2.再考慮處理
3.最後考慮數據流和數據存儲

1. 從問題描述中提取數據流圖的4種成分
   從上面對系統的描述可以知道“採購部每天需要一張訂貨報表”。
   “通過放在倉庫中的CRT終端把事務報告給訂貨系統”，所以採購員是數據終點，而倉庫管理員是數據源點。

2. 再一次閱讀問題描述，“採購部需要報表”
   因此必須有一個用於產生報表的處理。
   事務的後果是改變零件庫存量，然而任何改變數據的操作都是處理，因此對事務進行的加工是另一個處理。
   注意，在問題描述中並沒有明顯地提到需要對事務進行處理，但是通過分析可以看出這種需要。

3. 第三步：考慮數據流和數據存儲
   系統把訂貨報表送給採購部，因此訂貨報表是一個數據流，事務需要從倉庫送到系統中，顯然事務是另一個數據流。
   產生報表和處理事務這兩個處理在時間上明顯不匹配——每當有一個事務發生時立即處理它，然而每天只產生一次訂貨報表。
   因此，用來產生訂貨報表的數據必須存放一段時間，也就是應該有一個數據存儲。

步驟一：從問題描述中提取數據流圖的4種成分

分析結果：
源點：倉庫管理員
終點：採購員
處理：處理事務、產生報表等
數據流：事務、訂貨信息、訂貨報表等
數據存儲：訂貨信息、庫存信息

步驟二：着手畫數據流圖的基本系統模型

步驟三：把基本系統模型細化，描繪系統主要功能

步驟四：主要功能進一步細化

3.5.3 命名

數據流圖中每個成分的命名是否恰當，直接影響數據流圖的可理解性。
因此，給這些成分起名字時應該仔細推敲。

數據流命名時應注意的問題

1. 名字應代表整個數據流的內容，而不是僅僅反映它的某些成分
2. 不要使用空洞的、缺乏具體含義的名字
3. 在爲某個數據流(或數據存儲)起名字時遇到了困難，則很可能是因爲對數據流圖分解不恰當造成的，應該試試重新分解

爲“處理”命名時應注意的問題

1. 通常先爲數據流命名，然後再爲與之相關聯的處理命名。
2. 名字應該反映整個處理的功能，而不是它的一部分功能。
3. 名字最好由一個具體的及物動詞加上一個具體的賓語組成。
4. 通常名字中僅包括一個動詞，如果必須用兩個動詞才能描述整個處理的功能，則把這個處理再分解成兩個處理可能更恰當些。
5. 如果在爲某個處理命名時遇到困難，則很可能是發現了分解不當的跡象，應考慮重新分解。

3.6 狀態轉換圖（☆☆☆☆☆）

狀態轉換圖(簡稱爲狀態圖)通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行爲。
此外，狀態圖還指明瞭作爲特定事件的結果系統將做哪些動作。
因此，狀態圖建立軟件系統的行爲模型。

軟件行爲模型：狀態、事件、行爲。

3.6.1 狀態

狀態是任何可以被觀察到的系統行爲模式。

在狀態圖中定義的狀態主要有：

• 初態(即初始狀態)
• 終態(即最終狀態)
• 中間狀態。

在一張狀態圖中只能有一個初態，而終態則可以有0至多個。

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

3.6.2 事件和行爲

事件是在某個特定時刻發生的事情，它是對引起系統做動作或(和)從一個狀態轉換到另一個狀態的外界事件的抽象。
例： 用戶移動鼠標或單擊鼠標等都是事件。

事件就是引起系統做動作或(和)轉換狀態的控制信息。

行爲：進入某狀態後所作動作

3.6.3 符號

在狀態圖中，

• 初態用實心圓表示，
• 終態用一對同心圓(內圓爲實心圓)表示。
• 中間狀態用圓角矩形表示，可以用兩條水平橫線把它分成上、中、下3個部分。
  上面部分爲狀態的名稱，這部分是必須有的；
  中間部分爲狀態變量的名字和值，這部分是可選的；
  下面部分是活動表，這部分也是可選的。

活動表的語法格式如下：
事件名(參數表)/動作表達式
“事件名”可以是任何事件的名稱。
在活動表中經常使用下述3種標準事件：entry，exit和do。

• entry事件：指定進入該狀態的動作，
• exit事件：指定退出該狀態的動作，
• do事件：指定在該狀態下的動作。需要時可以爲事件指定參數表。

活動表中的動作表達式描述應做的具體動作。

狀態圖中兩個狀態之間帶箭頭的連線稱爲狀態轉換，箭頭指明瞭轉換方向。
狀態變遷通常是由事件觸發的，在這種情況下應在表示狀態轉換的箭頭線上標出觸發轉換的事件表達式；
如果在箭頭線上未標明事件，則表示在源狀態的內部活動執行完之後自動觸發轉換。
事件表達式的語法如下：
事件說明[守衛條件]/動作表達式
事件說明的語法爲：事件名(參數表)。

3.6.4 例子

爲了具體說明怎樣用狀態圖建立系統的行爲模型，下面舉一個例子。

下圖是人們非常熟悉的電話系統的狀態圖。

3.7 數據字典（☆☆☆☆☆）

概念：
數據字典是關於數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合，半形式化方法表達。

數據字典的作用是在軟件分析和設計的過程中給人提供關於數據的描述信息。

3.7.1 數據字典的內容

數據字典由以下4類元素的定義組成：

典型的情況下，在數據字典中記錄數據元素的下列信息：

數據元素的別名就是該元素的其他等價的名字。出現別名的原因主要有下述三個原因：
（1）對於同樣的數據，不同的用戶使用了不同的名字。
（2）一個分析員在不同時期對同一個數據使用了不同的名字。
（3）兩個分析員分別分析同一個數據流時，使用了不同的名字。
應該儘量減少出現別名,但是不可能完全消除別名。

① 數據流的描述

② 數據元素的描述

③ 數據存儲的描述

④ 處理的描述

3.7.2 數據字典的定義方法

定義數據字典的方法：對數據自頂向下分解。

4種由數據元素組成的數據的方式：

1. 順序：即以確定次序連接兩個或多個分量。
2. 選擇：即從兩個或多個可能的元素中選取一個。
3. 重複：即把指定的分量重複零次或多次。
4. 可選：一個分量是可有可無的（重複零次或一次）

數據字典定義符號：

舉例1：
航班信息文件={航空公司名稱+航班號+起點+終點+日期+起飛時間+降落時間}
航空公司名稱=2{字母}8
航班號=3{十進制數字}3
字母 =“a”.. “z”
十進制數字=“0”.. “9”
起點=終點=1{漢字}5
起飛時間=降落時間=時+分
時=“00”..“23”
分=“00”..“59”
日期=年+月+日
年=[2017|2018|2019|2020]
月=“01”..“12”
日=“01”..“31”

舉例2：
某程序設計語言規定，用戶說明的標識符是長度不超過8個字符的字符串，其中，第一個字符必須是字母字符，最後的字符既可以是字母字符也可以是數字字符。
標識符=字母字符+字母數字串
字母數字串=0{字母或數字}7
字母或數字=[字母字符|數字字符]

3.7.3 數據字典的用途

數據字典最重要的用途是作爲分析階段的工具。
數據字典中包含的每個數據元素的控制信息是很有價值的。
數據字典是開發數據庫的第一步，而且是很有價值的一步。

3.7.4 數據字典的實現

在開發大型軟件系統的過程中，數據字典的規模和複雜程度迅速增加，人工維護數據字典幾乎是不可能的。

在開發小型軟件系統時暫時沒有數據字典處理程序，建議採用卡片形式書寫數據字典，每張卡片上保存描述一個數據的信息。
下面給出第2.4節的例子中幾個數據元素的數據字典卡片，以具體說明數據字典卡片中上述幾項內容的含義。

3.8 其他圖形工具

描述複雜的事物時，圖形遠比文字敘述優越得多，它形象直觀容易理解。
（1）用於建立功能模型的數據流圖；
（2）用於建立數據模型的實體-聯繫圖；
（3）用於建立行爲模型的狀態圖。
本節再簡要地介紹在需求分析階段可能用到的另外3種圖形工具。

3.8.1 層次方框圖

層次方框圖用樹形結構的一系列多層次的矩形框描繪數據的層次結構。
例如，描繪一家計算機公司全部產品的數據結構可以用下圖表示。

這家公司的產品由硬件、軟件和服務3類產品組成，軟件產品又分爲系統軟件和應用軟件，系統軟件又進一步分爲操作系統、編譯程序和軟件工具等。

3.8.2 Warnier圖

和層次方框圖類似，Warnier圖也用樹形結構描繪信息，但是這種圖形工具比層次方框圖提供了更豐富的描繪手段。
用Warnier圖可以表明信息的邏輯組織，它可以指出一類信息或一個信息元素是重複出現的，也可以表示特定信息在某一類信息中是有條件地出現的。

3.8.3 IPO圖

IPO圖是輸入、處理、輸出圖的簡稱，它是由美國IBM公司發展完善起來的一種圖形工具，能夠方便地描繪輸入數據、對數據的處理和輸出數據之間的關係。

它的基本形式是在左邊的框中列出有關的輸入數據，在中間的框內列出主要的處理，在右邊的框內列出產生的輸出數據。用粗大箭頭清楚地指出數據通信的情況。

IPO圖的一個例子：

改進的IPO圖的形式：

3.9 驗證軟件需求

3.9.1 從哪些方面驗證軟件需求的正確性

需求分析階段的工作結果是開發軟件系統的重要基礎，大量統計數字表明，軟件系統中15%的錯誤起源於錯誤的需求。
爲了提高軟件質量，確保軟件開發成功，降低軟件開發成本，一旦對目標系統提出一組要求之後，必須嚴格驗證這些需求的正確性。
一般說來，應該從下述4個方面進行驗證。
（1）一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。
（2）完整性：需求必須是完整的，規格說明書應該包括用戶需要的每一個功能或性能。
（3）現實性：指定的需求應該是用現有的硬件技術和軟件技術基本上可以實現的。
（4）有效性：必須證明需求是正確有效的，確實能解決用戶面對的問題。

3.9.2 驗證軟件需求的方法

至少必須從一致性、完整性、現實性和有效性這4個不同角度驗證軟件需求的正確性。
那麼，怎樣驗證軟件需求的正確性呢?驗證的角度不同，驗證的方法也不同。

1. 驗證需求的一致性
   當需求分析的結果是用自然語言書寫的時候，除了靠人工技術審查驗證軟件系統規格說明書的正確性之外，目前還沒有其他更好的“測試”方法。
   但是，這種非形式化的規格說明書是難於驗證的，特別在目標系統規模龐大、規格說明書篇幅很長的時候，人工審查的效果是沒有保證的，冗餘、遺漏和不一致等問題可能沒被發現而繼續保留下來，以致軟件開發工作不能在正確的基礎上順利進行。
   爲了克服上述困難，人們提出了形式化的描述軟件需求的方法。

2. 驗證需求的現實性
   爲了驗證需求的現實性，分析員應該參照以往開發類似系統的經驗，分析用現有的軟、硬件技術實現目標系統的可能性。
   必要的時候應該採用仿真或性能模擬技術，輔助分析軟件需求規格說明書的現實性。

3. 驗證需求的完整性和有效性
   只有目標系統的用戶才真正知道軟件需求規格說明書是否完整、準確地描述了他們的需求。因此，檢驗需求的完整性，特別是證明系統確實滿足用戶的實際需要，只有在用戶的密切合作下才能完成。然而許多用戶並不能清楚地認識到他們的需要，不能有效地比較陳述需求的語句和實際需要的功能。只有當他們有某種工作着的軟件系統可以實際使用和評價時，才能完整確切地提出他們的需要。
   使用原型系統是一個比較現實的方法，用戶通過試用原型系統，能獲得許多寶貴的經驗，從而可以提出更符合實際的要求。

3.9.3 用於需求分析的軟件工具

爲了更有效地保證軟件需求的正確性，特別是爲了保證需求的一致性，需要有適當的軟件工具支持需求分析工作。

（1）必須有形式化的語法(或表)，因此可以用計算機自動處理使用這種語法說明的內容。
（2）使用這個軟件工具能夠導出詳細的文檔。
（3）必須提供分析(測試)規格說明書的不一致性和冗餘性的手段，並且應該能夠產生一組報告指明對完整性分析的結果。
（4）使用這個軟件工具之後，應該能夠改進通信狀況。

1977年美國密執安大學開發了PSL/PSA（問題陳述語言/問題陳述分析程序）系統。
這個系統是CADSAT（計算機輔助設計和規格說明分析工具）的一部分。其中PSL是用來描述系統的形式語言，PSA是處理PSL描述的分析程序。

PSL/PSA系統的功能主要有下述4種。
（1）描述任何應用領域的信息系統。
（2）創建一個數據庫保存對該信息系統的描述符。
（3）對描述符施加增加、刪除和更改等操作。
（4）產生格式化的文檔和關於規格說明書的各種分析報告。