2.2 軟件需求分析的目標和過程

在規定軟件需求時，軟件人員與用戶同樣起著至關重要的作用。用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而軟件人員則要認真了解用戶的要求，細致地進行調查分析，把用戶“需要”什么軟件認識清楚，最終轉換成一個完全、準確、清楚的軟件邏輯模型，并寫出軟件的需求規格說明，準確地表達用戶的需求。

2.2.1 軟件需求

IEEE軟件工程標準詞匯表（1997年）中將需求定義為：①用戶解決問題或達到目標所需的條件或能力；②系統或系統部件要滿足合同、標準、規范或其他正式規定文檔所需具有的條件或能力。

其中，①是從用戶的角度定義的，②是從軟件系統的角度定義的。雖然目前對什么是軟件需求的定義有不同的看法，但我們認為軟件需求是指軟件系統必須滿足的所有功能、性質和限制。需求分析需要實現的是將用戶對軟件的一系列要求、想法轉變為軟件開發人員所需要的有關軟件的技術規格說明，它涉及面向用戶的用戶需求和面向開發者的系統需求兩個方面的工作內容。

軟件需求包括3個不同的層次：業務需求、用戶需求和系統需求（包括功能需求、非功能需求和數據需求）。

1.業務需求

業務需求反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。

2.用戶需求

用戶需求是關于軟件的一系列想法的集中體現，涉及軟件的功能、操作方式、界面風格、用戶機構的業務范圍、工作流程、用戶對軟件應用的展望等。因此，用戶需求也就是關于軟件的外界特征的規格表述。用戶需求具有以下特點：

（1）用戶需求直接來源于用戶。需求可以由用戶主動提出，也可以通過與用戶進行溝通、交流或者通過問卷調查等方式獲得。由于用戶對計算機系統認識上的不足，分析人員有義務幫助用戶挖掘需求，如可以用啟發的方式激發用戶的需求想法。

（2）用戶需求需要以文檔的形式提供給用戶審查，因此，需要使用流暢的自然語言和簡潔清晰的直觀圖表來表述，以方便用戶的理解和確認。

（3）可以把用戶需求理解為用戶對軟件的合理請求。這意味著，必須全面理解用戶的各項要求，但又不能全盤接受其要求。因為并非所有用戶提出的全部要求都是合理的，對其中模糊的要求還需要澄清，然后才能決定是否可以采納。對于那些無法實現的要求應向用戶充分解釋，以求得到理解。

（4）用戶需求主要是為用戶方管理層撰寫的，但是用戶方的技術代表、軟件系統今后的操作者及開發方的高層技術人員，也有必要認真閱讀用戶需求文檔。

3.系統需求

系統需求是比用戶需求更具有技術特性的需求陳述，它是提供給開發方或用戶方技術人員閱讀的，并將作為軟件開發人員設計系統的起點與基本依據。系統需求需要對系統的功能、性能、數據等方面進行規格定義。系統需求往往要求用更加嚴格的形式化語言進行表述，以保證系統需求表述具有一致性。系統需求是綜合的、多方面的，下面重點介紹功能、非功能、數據3個方面的需求特征。

（1）功能需求。功能需求是軟件系統的最基本的需求表述，包括對系統應該提供的服務，如何對輸入作出反應，以及系統在特定條件下的行為描述。在某些情況下，功能需求還必須明確系統不應該做什么，這取決于開發的軟件類型、軟件未來的用戶及開發的系統類型。所以，功能性的系統需求，需要詳細地描述系統功能特征、輸入和輸出接口、異常處理方法等。

軟件系統的功能需求可以有許多不同的描述方式。軟件工程中的許多問題都源自對需求描述的不嚴格，自然語言對需求分析最大的弊端就是它的二義性，所以我們不得不對需求分析中采用的語言做某些限制。例如，盡量采用主語+動詞的表達方式。

理論上，系統的功能需求描述應該具有全面性和一致性。全面性意味著對用戶所需的所有功能都應該給出描述；一致性意味著需求描述不能前后矛盾。在實際過程中，對于大型復雜的系統而言，要完全滿足這兩個方面的要求幾乎是不可能的，因此，需要由質量保證小組進行評審。

（2）非功能需求。非功能需求包括對系統提出的性能需求、可靠性和可用性需求、系統安全，以及系統對開發過程、時間、資源等方面的約束、標準等。性能需求指系統必須滿足的定時約束或容量約束，一般包括速度（響應時間）、信息量速率（吞吐量、處理時間）、存儲容量等方面的需求。例如，“匯總統計分析必須在一分鐘之內生成”就是一項性能需求。可靠性需求定量地指定系統的可靠程度，如“系統應支持7×24小時提供服務的業務需要”。可用性與可靠性密切相關，它量化了用戶可以使用系統的程度。例如，在任何情況下，主機或備份系統應該至少有一個可用，而且在一年內，該系統的不可用時間不能超過總時間的1%。

非功能需求一般關心系統的整體特性，而不是個別的系統特性。因此，對于系統來說非功能需求比功能需求更關鍵。一個功能需求沒有滿足，可能降低系統的能力；而一個非功能需求沒有滿足，則可能使整個系統無法使用。

非功能需求不僅與軟件系統本身有關，還與系統的開發過程有關。例如，質量標準的描述、使用開發工具的描述，以及必須遵守的原則等。非功能需求還源于一些用戶的限制，包括預算約束、機構政策、硬件平臺、隱私權的保護等。

（3）數據需求。大多數軟件系統本質上都是信息處理系統。系統處理的信息和系統產生的信息在很大程度上決定了系統的面貌，對軟件設計具有深遠的影響。因此，必須分析系統的數據需求，這也是軟件需求分析的一個任務。數據需求包括輸入數據、輸出數據、加工中的數據、保存在存儲設備上的數據等。在結構化方法中，可以使用數據字典對數據進行全面準確的定義，如數據的名稱、組成元素、出現的位置、出現的頻率、存儲的周期等。當所要開發的軟件系統涉及對數據庫的操作時，可以使用數據關系模型圖，對數據庫中的數據實體、數據實體之間的關系進行描述。

2.2.2 軟件需求分析的目標

軟件需求分析的目標是準確理解用戶的要求，進行細致的調查分析，將用戶的非形式要求轉化為完整的需求定義，再將需求定義轉換為相應形式的規格說明。

軟件需求分析工作是軟件生存周期中重要的一步，也是決定性的一步。只有通過軟件需求分析，才能把軟件功能和性能的總體概念描述為具體的軟件需求規格說明，從而奠定軟件開發的基礎。軟件需求分析工作也是一個不斷認識和逐步細化的過程。該過程將軟件計劃階段所確定的軟件范圍逐步細化到可詳細定義的程度，并分析出各種不同的軟件元素，然后為這些元素找到可行的解決方法。

正如任何一項工作在著手以前，首先必須明確目標一樣，軟件在進入開發階段時，也需要弄清楚，要開發的軟件應該具有哪些功能，應達到什么性能。明確了需求，就得到了軟件設計的依據。軟件開發的實踐表明，做好需求分析工作并不是一件輕而易舉的事情。軟件危機發生的原因之一就是忽視了需求分析這一重要的步驟，往往是軟件開發人員和用戶未能全面準確地理解需求，或是未能恰當地表達這些需求，以致把需求分析階段的問題遺留到開發工作的后續階段，最終釀成不良后果。

需求分析階段研究的對象是軟件項目的用戶要求。一方面，必須全面理解用戶的各項要求，但又不能全盤接受所有的要求，因為并非所有的用戶要求都是合理的，對其中模糊的要求還需要澄清，然后才能決定是否可以采納。對于那些無法實現的要求，應向用戶充分解釋，以求得理解。另一方面，要準確地表達被接受的用戶要求。只有經過確切描述的軟件需求才能成為軟件設計的基礎。

制定軟件的需求規格說明不只是軟件開發人員的事，用戶也起著至關重要的作用。用戶必須對軟件功能和性能提出初步要求，并澄清一些模糊概念。而軟件分析人員則要認真了解用戶的要求，細致地進行調查分析，把用戶“做什么”的要求最終轉換成一個完全、精細的軟件邏輯模型，并寫出軟件的需求規格說明，準確地表達用戶的要求。

通常軟件開發項目是要實現目標系統的物理模型。作為目標系統的參考，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統“做什么”的問題。其實現步驟如圖2.1所示。

1.獲得當前系統的物理模型

所謂當前系統可能是需要改進的某個已在計算機上運行的數據處理系統，也可能是一個人工的數據處理過程。在這一步首先分析現實世界，理解當前系統是如何運行的，了解當前系統的組織機構、輸入輸出、資源利用情況和日常數據處理過程，并用一個具體模型來反映自己對當前系統的理解。這一模型應客觀地反映現實世界的實際情況。

2.抽象出當前系統的邏輯模型

在理解當前系統“怎么做”的基礎上，抽取其“做什么”的本質，從當前系統的物理模型抽象出當前系統的邏輯模型。

在物理模型中有許多物理因素，隨著分析工作的深入，有些非本質的物理因素就會成為不必要的負擔，因而需要對物理模型進行分析，區分出本質的和非本質的因素，去掉那些非本質的因素即可獲得反映系統本質的邏輯模型。

3.建立目標系統的邏輯模型

分析目標系統與當前系統邏輯上的差別，明確目標系統到底要“做什么”，從而從當前系統的邏輯模型導出目標系統的邏輯模型。

具體做法：①確定變更范圍，即確定目標系統與當前系統在邏輯上的差別；②將變化的部分看成新的處理步驟，對數據流程圖進行調整；③由外向里對變更部分進行分析，憑經驗推斷其結構，獲得目標系統的邏輯模型。

4.補充目標系統的邏輯模型

補充內容包括：①說明目標系統的用戶界面。根據目標系統所處的應用環境及其與外界環境的相互關系，研究所有可能與它發生聯系和作用的部分，從而決定人機界面。②說明至今尚未詳細考慮的細節。這些細節包括系統的啟動和結束、出錯處理、系統的輸入輸出和系統性能方面的需求。③其他。例如，系統的其他必須滿足的性能和限制等。

2.2.3 需求分析的過程

需求分析階段的工作，可以分成問題識別、分析與綜合、編制需求文檔、需求分析評審4個過程。

1.問題識別

首先系統分析人員要研究系統的可行性分析報告（如果有的話）和軟件項目實施計劃，主要從系統的角度來理解軟件并評審用于產生計劃估算的軟件范圍是否恰當；確定對目標系統的綜合要求，即軟件的需求；并提出這些需求的實現條件及需求應達到的標準，解決要求被開發軟件做什么、做到什么程度的問題。

這些要求包括功能要求、性能要求、環境要求、可靠性要求、安全保密要求、用戶界面要求、資源使用要求、軟件成本消耗與開發進度要求，并預先估計以后系統可能達到的目標。此外，還需要注意其他非功能需求，如針對采用某種開發模式，確定質量控制標準、里程碑和評審、驗收標準、各種質量要求的優先級等，以及可維護性方面的要求。

另外，需要建立分析所需要的通信途徑，以保證能順利地對問題進行分析。分析所需的通信途徑，如圖2.2所示。

2.分析與綜合

分析人員對獲取的有關軟件的各項需求，進行如下工作：

（1）各項需求的一致性分析檢查。

（2）從數據流和數據結構出發，逐步細化所有軟件功能，劃分出各種子功能。

（3）對數據域進行分解，并分配到子功能上，以確定系統的構成和各主要成分。

（4）找出系統各成分之間的聯系、接口特性和設計上的限制。

（5）判斷是否存在因片面性或短期行為而導致的不合理的用戶需求，是否有用戶尚未提出的真正有價值的潛在需求，剔除不合理的部分，增加其需要的部分。

（6）綜合成系統的解決方案，給出目標系統的詳細邏輯模型。

在這個步驟中，分析和綜合工作會反復進行。在對現行問題和期望的信息（輸入和輸出）進行分析的基礎上，分析人員開始綜合出一個或幾個解決方案，然后檢查它的工作是否符合軟件計劃中規定的范圍等，再進行修改。總之，對問題進行分析和綜合的過程將一直持續到分析人員與用戶雙方都感到有把握正確地制定該軟件的規格說明為止。

3.編制需求文檔

已經確定下來的需求應當得到清晰準確的描述，需求文檔包括以下幾項內容：

（1）軟件需求說明書：把分析人員和用戶雙方共同的理解和分析結果用規范的方式描述出來，作為今后各項工作的基礎。

（2）初步的用戶手冊：著重反映目標軟件的用戶功能界面和用戶使用的具體要求。用戶手冊能強制分析人員從用戶使用的觀點來思考問題。

（3）編寫確認測試計劃：作為今后確認測試的依據。

（4）修改和完善軟件開發計劃：在需求分析階段軟件開發方對目標系統有了更進一步的了解，因此能夠更準確地估算開發成本、進度和資源需求，需要對軟件開發計劃做適當的修改。

可以把描述需求的文檔稱為軟件需求規格說明書。軟件需求規格說明書（Software Requirement Specification，SRS）是需求工程最終產生的結果，必須用一種統一的方式將它們編寫成可視文檔，包含軟件的功能需求和非功能需求。需求規格說明書是項目相關人員對要開發的軟件系統達成的共識，是進行系統設計、實現、測試和驗收的基本依據，也是整個軟件開發過程中最重要的文件。需求規格說明書要求滿足完整性、一致性、可修改性、可跟蹤性等要求。同時，為了確切表達用戶對軟件的輸入輸出要求，還需要制定數據要求說明書。

4.需求分析評審

作為需求分析階段工作的復查手段，應該對功能的正確性、文檔的一致性、完備性、準確性和清晰性及其他需求給予評價。

為保證軟件需求定義的質量，評審應有指定人員負責，并按規程嚴格進行。評審結束應有評審負責人的結論意見及簽字。除分析人員之外，用戶/需求者，開發部門的管理者，軟件設計、實現、測試等人員都應當參加評審工作。

2.2.4 需求獲取

需求獲取是需求分析的主體。對待開發的軟件系統，需求獲取是一個確定和理解不同用戶需求和限制的過程。業務需求決定用戶需求，它描述了用戶需要利用系統完成的任務。

獲取用戶需求的主要方法是調查研究。

1.了解系統的需求

軟件開發常常是系統開發的一部分。仔細分析研究系統的需求規格說明，對軟件的需求獲取是很有必要的。

2.市場調查

了解市場對待開發軟件有什么樣的要求；了解市場上有無與待開發軟件類似的系統，如果有，在功能上、性能上、價格上情況如何。

3.訪問用戶和用戶領域的專家

把從用戶那里得到的信息作為重要的原始資料進行分析；訪問用戶領域的專家所得到的信息將有助于對用戶需求的理解。

4.考察現場

了解用戶實際的操作環境、操作過程和操作要求。對照用戶提交的問題陳述，對用戶需求可以有更全面、更細致的認識。

在做調查研究時，可以采取如下調查方式：

（1）制定調查提綱，向不同層次的用戶進行問卷調查。

（2）按用戶的不同層次，分別召開調查會，了解用戶對開發系統的想法和建議。

（3）向用戶領域專家或關鍵崗位上的工作人員進行個別咨詢。

（4）實地考察，跟蹤現場業務流程。

（5）查閱與待開發系統有關的資料。

（6）使用各種調查工具，如數據流程圖、任務分解圖、程序網絡圖等。

為了能夠有效地獲取和厘清用戶需求，應當打破用戶（需方）和開發者（供方）的界限，共同組成一個聯合小組，發揮各自的長處，協同工作。

需求獲取技術包括以下兩個方面的工作：

（1）建立用戶要求獲取方法的框架。

（2）支持和監控需求獲取過程的機制。

2.2.5 軟件需求分析的原則

近年來軟件開發人員已提出了許多軟件分析與說明的方法。雖然各種分析方法都有其獨特的描述方法，但總的看來，所有分析方法還是有它們共同適用的基本原則。

1.需要能夠表達和理解問題的信息域和功能域

所有軟件定義與開發工作最終是為了解決好數據處理問題，就是將一種形式的數據轉換成另一種形式的數據。其轉換過程必定經歷輸入、加工數據和產生結果數據等步驟。

對于計算機程序處理的數據，其信息域應包括信息流、信息內容和信息結構。

信息流即數據和控制通過一個系統時的變化方式，如圖2.3所示。輸入對象首先轉換成中間數據/控制，然后轉換成輸出對象。在此期間可以從已有的存儲（如磁盤文件或內存緩沖區）中引入追加數據/控制。對數據進行轉換是程序中應有的功能或子功能，兩個功能之間中間數據/控制的傳遞可確定功能間的接口。

信息內容即單個數據或控制對象，它們構成了某個更大的由軟件變換生成信息的集合。例如，學生名冊包含班級、人數、學號、姓名、性別、各科成績等，學生名冊的內容由它所包含的項定義。為了理解對學生名冊的處理，必須理解它的數據內容。類似地，控制對系統狀態的內容可以由一個位串定義，每位表示一個單獨的信息項，它會指明某個特殊設備是在線還是離線。

信息結構即各種數據和控制項的內部組織。在結構中數據項與其他哪些數據項相關？所有數據是在一個信息結構中，還是在幾個信息結構中？一個結構中的數據與其他結構中的數據如何聯系？這些問題都由信息結構的分析來解決。

2.以層次化的方式對問題進行分解和不斷細化

通常將軟件要處理的問題作為一個整體來看，顯得太大、太復雜，很難理解，因此需要把問題以某種方式分解為幾個較易理解的部分，并確定各部分間的接口，從而實現整體功能。在需求分析階段，軟件的功能域和信息域都能進行進一步分解。這種分解可以是同一層次的，稱為橫向分解；也可以是多層次的，稱為縱向分解，如圖2.4所示。

如果把一個功能分解成幾個子功能，并確定這些子功能與父功能的接口，就屬于橫向分解。但如果繼續分解，又把某些子功能分解為小的子功能，某個小的子功能又分解為更小的子功能，這就屬于縱向分解了。

3.要給出系統的邏輯視圖和物理視圖

給出系統的邏輯視圖（邏輯表示）和物理視圖（物理表示），這對系統滿足處理需求所提出的邏輯限制條件和系統中其他成分提出的物理限制條件來說是必不可少的。

軟件需求的邏輯視圖給出的是軟件要達到的功能和要處理的數據之間的關系，而不是實現的細節。例如，一個商場的銷售處理系統要從顧客那里獲取訂單，系統讀取訂單的功能并不關心訂單數據本身的物理形式和讀入設備，也就是說無須關心輸入的機制，只是讀取顧客的訂單而已。類似地，系統中檢查庫存的功能只關心庫存文件的信息結構，而不關心它在計算機中的具體存儲方式。

軟件需求的邏輯描述是軟件設計的基礎。軟件需求的物理視圖給出的是處理功能和數據結構的實際表現形式，這往往是由設備本身決定的。例如，一些軟件靠終端鍵盤輸入數據，另一些數據處理軟件靠 A/D 轉換設備提供數據。軟件分析人員必須弄清系統對軟件的限制，并考慮功能和數據結構的物理表示。分析人員在需求分析過程中，并不需要考慮“如何實現”，僅需要考慮“做什么”。

2.2.6 需求分析的方法

需求分析方法由對軟件的信息域和功能域的系統分析過程及其表示方法組成。它提供了分解問題的方法，定義了表示系統邏輯視圖和物理視圖的方式。大多數的需求分析方法是由數據驅動的，就是說，這些方法提供了一種表示信息域的機制，分析人員根據這種表示，確定軟件功能及其他特性，最終建立一個待開發軟件的抽象模型，即目標系統的邏輯模型。信息域具有數據流、數據內容和數據結構3種屬性。通常，一種需求分析方法總要利用其中的一種或幾種屬性。

目前存在許多需求分析方法，每種分析方法都引入了不同的記號和分析策略，但是它們仍具有以下共性。

1.支持信息域分析的機制

所有的方法都直接或間接地涉及數據流、數據內容或數據結構等信息域屬性。

在多數情況下，數據流特征是用將輸入轉換成輸出的變換（功能）過程來描述的，數據內容可以用數據詞典機制明確表示，或者通過描述數據的層次結構隱含地表示。

2.功能表示的方法

功能一般用數據變換或加工來表示，每項功能可用規定的記號（圓圈或方框）標識。功能的說明可以用自然語言文本來表達，也可以用形式化的規格說明語言來表達，還可以用上述兩種方式的混合方式——結構化語言來描述。

3.接口

接口的說明通常是數據表示和功能表示的直接產物，某個具體功能的流進和流出數據流應是其他相關功能的流出或流入數據流。因此，通過數據流分析可以確定功能間的接口。

4.問題分解的機制及對抽象的支持

問題分解和抽象主要依靠分析人員在不同抽象層次上表示數據域和功能域，以逐層細化的手段建立分層結構來實現。例如，不論使用何種分析方法，分析人員都能表示諸如“計算員工9月份工資”之類的功能，可以在這個抽象層次上操縱這個功能。另外，所有的分析方法都提供一種逐層分解的機制，把“計算員工9月份工資”功能劃分成一些子功能，如計算房租、計算電費、計算水費、計算工會費、計算有線電視費、計算養老保險費，等等。其中，每項子功能還可以利用功能說明表示法在更低的一級抽象層次上表示。

5.邏輯視圖和物理視圖

大多數方法允許分析人員在著手問題的邏輯解決方案之前先分析物理視圖。通常，同一種表示法既可用來表示邏輯視圖，也可用來表示物理視圖。

6.系統抽象模型

為了能夠比較精確地定義軟件需求，可以建立待開發軟件的一個抽象模型，用基于抽象模型的術語來描述軟件系統的功能和性能，形成軟件需求規格說明。這種抽象的模型是從外部現實世界的問題領域抽象而來的，是在高級層次上描述和定義系統的服務。

對于比較簡單的問題，不必建立抽象系統模型。或者說，系統模型已經在分析人員頭腦中形成，直接由分析人員寫成規格說明。但對于比較復雜的問題，問題領域中各種關系比較復雜，僅有在頭腦中想象的模型是不夠的，必須建立適當的比較形式化的抽象系統模型，才能準確而全面地反映問題領域中各種復雜的要求。

不同類型的問題有不同的需要解決的中心問題，因而要建立不同類型的系統模型。對于數學軟件，設計的中心問題是算法，軟件人員的主要力量要花在對數學模型算法的考慮上。對于數據通信軟件，設計的中心問題是數據傳送和過程控制，實現算法簡單，采用數據流模型比較合適。對于涉及大量數據的數據處理軟件，設計的中心問題是數據處理，包括數據的采集、傳送、存儲、變換、輸出等，一旦數據結構明確，與它相關的算法就很簡單了，因此可以采用實體—關系模型。如果系統要求有數據庫支持（通過數據庫獲取和存放信息），還需要考慮數據在數據庫中的組織方式和存取方法，建立數據庫模型。因此，在分析過程中，數據模型是首先要集中精力考慮的問題。

系統模型的建立是對現實世界中存在的有關實體和活動的抽象和細化，其建立過程包括觀察分析、模型表示和模型檢查3個階段，如圖2.5所示。

首先，分析人員和用戶合作，從各方面觀察現實世界中的有關實體和活動，建立理解的共同基準，分清哪些概念與系統相關，必須納入系統模型，哪些是系統模型不必關心的。分析人員和用戶在共同理解的基礎上，建立系統模型，包括系統提供的各種系統服務，模型表示的細節應有系統輸入、系統輸出、系統數據處理、系統控制等。

系統模型建立起來以后，還要進行檢查。除靜態檢查之外，系統描述可以部分地模擬執行，將執行情況與對外部現實世界系統觀察得到的系統跟蹤信息進行對照，檢查模型是否符合要求。