第3章可行性研究及需求分析本章目標

了解可行性研究的目的、意義和內容掌握可行性研究的主要步驟了解需求分析的任務熟悉進行需求分析的步驟和方法了解需求管理掌握需求分析的原則熟悉需求分析的常用方法學習編寫軟件開發計劃書學習編寫需求規格說明書3.1可行性研究

3.1.1項目立項概述任何一個完整的軟件工程項目都是從項目立項開始的。項目立項包括項目發起、項目論證、項目審核和項目立項四個過程。在發起一個項目時，項目發起人或單位為尋求他人的支持，要以書面材料的形式遞交給項目的支持者和領導，使其明白項目的必要性和可行性。項目論證過程，也就是可行性研究過程?？尚行匝芯烤褪侵冈陧椖窟M行開發之前，根據項目發起文件和實際情況，對該項目是否能在特定的資源、時間等制約條件下完成做出評估，并且確定它是否值得去開發。項目經過可行性研究并且認為可行后，還需要報告主管領導或單位，以獲得項目的進一步審核，并得到他們的支持。項目通過可行性研究和主管部門的批準后，將其列入項目計劃的過程，叫做項目立項。經過項目發起、項目論證、項目審核和項目立項四個過程后，一個軟件工程項目就正式啟動了。3.1可行性研究

3.1.2可行性研究的內容

可行性研究需要從多個方面進行評估，主要包括：戰略可行性操作可行性計劃可行性技術可行性社會可行性市場可行性經濟可行性風險可行性3.1可行性研究

3.1.3可行性研究的步驟進行可行性研究的步驟不是固化的，而是根據項目的性質、特點以及開發團隊的能力有所區別。一個典型的可行性研究的步驟可以歸結為以下幾步，其示意圖如圖所示。3.2需求分析

3.2.1需求分析的任務

為什么需要需求分析

為了開發出真正滿足用戶需要的軟件產品，明確地了解用戶需求是關鍵。雖然在可行性研究中，已經對用戶需求有了初步的了解，但是很多細節還沒有考慮到?？尚行匝芯康哪康氖窃u估系統是否值得去開發，問題是否能夠解決，而不是對需求進行定義。如果說可行性分析是要決定“做還是不做”，那么需求分析就是要回答“系統必須做什么”這個問題。需求分析是一個非常重要的過程，它完成的好壞直接影響了后續軟件開發的質量。3.2需求分析

1.確定系統的運行環境要求

系統運行時的硬件環境要求，如對計算機的CPU、內存、存儲器、輸入/輸出方式、通信接口和外圍設備等的要求；軟件環境要求，如操作系統、數據庫管理系統和編程語言等的要求。3.2需求分析

2.確定系統的功能性需求和非功能性需求需求可以分為兩大類，功能性需求和非功能性需求，前者定義了系統做什么，后者定義了系統工作時的特性。功能需求是軟件系統的最基本的需求表述，包括對系統應該提供的服務，如何對輸入做出反應，以及系統在特定條件下的行為描述。在某些情況下，功能需求還必須明確系統不應該做什么，這取決于開發的軟件類型、軟件未來的用戶、以及開發的系統類型。所以，功能性的系統需求，需要詳細地描述系統功能特征、輸入和輸出接口、異常處理方法等。非功能性需求包括對系統提出的性能需求、可靠性和可用性需求、系統安全以及系統對開發過程、時間、資源等方面的約束和標準等。性能需求指定系統必須滿足的定時約束或容量約束，一般包括速度（響應時間）、信息量速率（吞吐量、處理時間）和存儲容量等方面的需求。3.2需求分析

3.進行有效的需求分析一般情況下，用戶并不熟悉計算機的相關知識，而軟件開發人員對相關的業務領域也不甚了解，用戶與開發人員之間對同一問題理解的差異和習慣用語的不同往往會為需求分析帶來很大的困難。所以，開發人員和用戶之間充分和有效的溝通在需求分析的過程中至關重要。有效的需求分析通常都具有一定的難度，這一方面是由于交流障礙所引起的，另一方面是由于用戶通常對需求的陳述不完備、不準確和不全面，并且還可能在不斷的變化。所以開發人員不僅需要在用戶的幫助下抽象現有的需求，還需要挖掘隱藏的需求。此外，把各項需求抽象為目標系統的高層邏輯模型對日后的開發工作也至關重要。合理的高層邏輯模型是系統設計的前提。3.2需求分析

4.在需求分析的過程中應該遵守一些原則首先，需求分析是一個過程，它應該貫穿于系統的整個生命周期中，而不是僅僅屬于軟件生命周期早期的一項工作。其次，需求分析應該是一個迭代的過程。由于市場環境的易變性以及用戶本身對于新系統要求的模糊性，需求往往很難一步到位。通常情況下，需求是隨著項目的深入而不斷變化的。所以需求分析的過程還應該是一個迭代的過程。此外，為了方便評審和后續的設計，需求的表述應該具體、清晰，并且是可測量的、可實現的。最好能夠對需求進行適當的量化。比如：系統的響應時間應該低于0.5秒；系統在同一時刻最多能支持30000個用戶。3.2需求分析

5.需求分析的兩個任務。

首先，是需求分析的建模階段，即在充分了解需求的基礎上，要建立起系統的分析模型。

其次，是需求分析的描述階段，就是把需求文檔化，用軟件需求規格說明書的方式把需求表達出來。3.2需求分析

6.軟件需求規格說明書

軟件需求規格說明書是需求分析階段的輸出，它全面、清晰地描述了用戶需求，因此是開發人員進行后續軟件設計的重要依據。軟件需求規格說明書應該具有清晰性、無二義性、一致性和準確性等特點。同時，它還需通過嚴格的需求驗證、反復修改的過程才能最終確定。3.2需求分析

3.2.2

需求分析的步驟為了準確獲取需求，需求分析必須遵循一系列的步驟。只有采取了合理的需求分析的步驟，開發人員才能更有效地獲取需求。一般來說，需求分析分為需求獲取、分析建模、需求描述和需求驗證4步。以下將分步進行介紹。3.2需求分析

1) 需求獲取需求獲取就是收集并明確用戶需求的過程。系統開發方人員通過調查研究，要理解當前系統的工作模型、用戶對新系統的設想與要求。在需求獲取的初期，用戶提出的需求一般模糊而且凌亂，這就需要開發人員能夠選取較好的需求分析的方法，提煉出邏輯性強的需求。而且不同用戶的需求有可能發生沖突，對于發生沖突的需求必須仔細考慮并做出選擇。獲取需求的方法有多種，比如問卷調查、訪談、實地操作、建立原型等。3.2需求分析

2) 分析建模獲取到需求后，下一步就應該對開發的系統建立分析模型了。模型就是為了理解事物而對事物做出的一種抽象，通常由一組符號和組織這些符號的規則組成。對待開發系統建立各種角度的模型有助于人們更好地理解問題。通常，從不同角度描述或理解軟件系統，就需要不同的模型。常用的建模方法有數據流圖、實體關系圖、狀態轉換圖、控制流圖、用例圖、類圖、對象圖等。3.2需求分析

3) 需求描述需求描述就是指編制需求分析階段的文檔。一般情況下，對于復雜的軟件系統，需求階段會產生3個文檔:系統定義文檔（用戶需求報告）、系統需求文檔（系統需求規格說明書）、軟件需求文檔（軟件需求規格說明書）。而對于簡單的軟件系統而言，需求階段只需要輸出軟件需求文檔就可以了。軟件需求規格說明書主要描述軟件部分的需求，簡稱SRS（SoftwareRequirementSpecification），它站在開發者的角度，對開發系統的業務模型、功能模型、數據模型、行為模型等內容進行描述。經過嚴格的評審后，它將作為概要設計和詳細設計的基線。3.2需求分析

文檔與軟件規模的對應關系3.2需求分析

4) 需求驗證

需求分析的第四步是驗證以上需求分析的成果。需求分析階段的工作成果是后續軟件開發的重要基礎，為了提高軟件開發的質量，降低軟件開發的成本，必須對需求的正確性進行嚴格的驗證，確保需求的一致性、完整性、現實性、有效性。確保設計與實現過程中的需求可回溯性，并進行需求變更管理。3.2需求分析

3.2.3需求管理為了更好的進行需求分析并記錄需求結果，需要進行需求管理。需求管理是一種用于查找、記錄、組織和跟蹤系統需求變更的系統化方法?？捎糜冢韩@取、組織和記錄系統需求使客戶和項目團隊在系統變更需求上達成并保持一致

有效需求管理的關鍵在于維護需求的明確闡述、每種需求類型所適用的屬性，以及與其他需求和其他項目工件之間的可追蹤性。3.2需求分析

3.2.4需求分析的常用方法需求分析的方法有多種，下面只簡單介紹功能分解方法、結構化分析方法、信息建模方法和面向對象的分析方法。（1）功能分解方法功能分解方法是將一個系統看成是由若干功能模塊組成的，每個功能又可分解為若干子功能及接口，子功能再繼續分解，即功能、子功能和功能接口成為了功能分解方法的3個要素。功能分解方法采用的是自頂向下、逐步求精的理念。3.2需求分析

（2）結構化分析方法結構化分析方法是一種從問題空間到某種表示的映射方法，其邏輯模型由數據流圖和數據詞典構成并表示。它是一種面向數據流的需求分析方法。它主要適用于數據處理領域問題。第4章將詳細介紹這種方法。3.2需求分析

（3）信息建模方法模型是用某種媒介對相同媒介或其他媒介里的一些事物的表現形式。從一個建模角度出發，模型就是要抓住事物的最重要方面而簡化或忽略其他方面。簡而言之，模型就是對現實的簡化。建立模型的過程，稱為建模。建?？梢詭椭斫庹陂_發的系統，這是需要建模的一個基本理由。并且，人對復雜問題的理解能力是有限的。建模可以幫助開發者縮小問題的范圍，每次著重研究一個方面，進而對整個系統產生更加深刻的理解?？梢悦鞔_地說，越大、越復雜的系統，建模的重要性也越大。信息建模方法常用的基本工具是E-R圖，其基本要素由實體、屬性和關系構成。它的核心概念是實體和關系，它的基本策略是從現實中找出實體，然后再用屬性對其進行描述。3.2需求分析

（4）面向對