系統(tǒng)需求分析文檔主要內容

1、系統(tǒng)需求分析文檔主要內容：1. 文檔概述該部分主要是對軟件需求規(guī)格說明書文檔進行基本的描述，包括該文檔的目的、范圍、術語定義、參考資料以及概要。軟件需求規(guī)格說明書用來系統(tǒng)、完整地記錄系統(tǒng)的軟件需求。該軟件需求說明書的基礎是用例分析技術。因此該文檔中應包括用例模型、補充規(guī)約等內容。1.1 目的在此小節(jié)中，主要對軟件需求規(guī)格說明書的目的做一概要性說明，通常軟件需求規(guī)格說明書應詳細地說明應用程序、子系統(tǒng)的外部行為，還要說明非功能性需求、設計約束，以及其它的相關因素。1.2 范圍系統(tǒng)是有范圍的，而不是無限擴展的，對于無限擴展的需求是無法進行描述的。因此，在本小節(jié)應該對該說明書所涉及的項目范圍進行清晰的

2、界定。指定該規(guī)格說明書適用的軟件應用程序、特性或者其它子系統(tǒng)分組、其相關的用例模型。當然在此也需要列出會受到該文檔影響的其它文檔。1.3 定義、首字母縮寫詞和縮略語與其它文檔一樣，該文檔也需要將本文檔中所涉及的所有術語、縮略語進行詳細的定義。還有一種可簡明的做法，就是維護在一個項目詞匯表中，這樣就可以避免在每個文檔中都重復很多內容。1.4 參考資料在這一小節(jié)中，應完整地列出該文檔引用的所有文檔。對于每個引用的文檔都應該給出標題、標識號、日期以及來源，為閱讀者查找這些文檔提供足夠詳細的信息。1.5 概述在本小節(jié)中，主要是說明軟件需求規(guī)格說明書各個部分所包含的主要內容，就像一個文章摘要一樣。同時也

3、應該對文檔的組織方式進行解釋。2. 整體說明在本節(jié)中，將對整個軟件需求進行總體性的描述，以期讓讀者對整個軟件系統(tǒng)的需求有一個框架性的認識。也就是說，該節(jié)中主要包括影響產品及其需求的一般因素，而不列舉具體的需求。主要包括產品總體效果、產品功能、用戶特征、約束、假設與依賴關系、需求子集等方面的內容。2.1 用例模型在本小節(jié)中，將列出該軟件需求的用例模型，該模型處于系統(tǒng)級，對系統(tǒng)的特性進行宏觀的描述。在此應該列出所有的用例和Actor 的名稱列表，并且對其做出簡要的說明，以及在圖中的各種關系。2.2 假設與依賴關系在軟件系統(tǒng)的開發(fā)過程中，存在許多假設和依賴關系。在本小節(jié)中應列舉出所有的重要的技術可行

4、性假設、子系統(tǒng)或構件可用性假設，以及一些可行性的假設。3. 具體需求如果說第二章節(jié)是框架，那么本節(jié)就是血肉。在本節(jié)中，應該詳細列出所有的軟件需求， 其詳細程序應使設計人員能夠充分理解并且進行設計的要求，同時也應該給予測試人員足夠的信息，以幫助他們來驗證系統(tǒng)是否滿足了這些需求。整個需求的組織可以采用用例描述進行。3.1 用例描述如果你使用用例建模技術，那么你已經(jīng)通過用例定義了系統(tǒng)的大部分功能性需求和一些非功能性需求。因此，在軟件需求規(guī)格說明書只需將這些具體的用例描述，整理在一起，全部放在該小節(jié)之中。當然也可以將用例描述做為附件，在此列出引用，只是這樣做并不利于閱讀。建議在組織形式上采用以“軟件需

5、求”為線索，在每個需求中，填入對應的1 個或幾個用例描述。3.2 補充需求由于用例畢竟主要針對功能性需求，因此還會有一些其它的補充需求遺漏，因此在本小節(jié)中就是將這些東西補充出來。這些補充需求大部分集中在非功能需求之上，包括以下幾個方面的內容：1） ） 易用性： 例如指出普通用戶和高級用戶要高效地執(zhí)行某個特定操作所需的培訓時間； 指出典型任務的可評測任務次數(shù)；或者指出需要滿足的可用性標準（如IBM 的 CUA 標準、 Microsoft 的 GUI 標準。2） 可靠性：包括系統(tǒng)可用性（可用時間百分比、使用小時數(shù)、維護訪問權、降紙模式操作等）；平均故障間隔時間（MTBF ，通常表示為小時數(shù)，但也可

6、表示為天數(shù)、月數(shù)或年數(shù)）；平均修復時間（MTTR ，系統(tǒng)在發(fā)生故障后可以暫停運行的時間）；精確度（指出系統(tǒng)輸出要求具備的精密度、分辨率和精確度）；最高錯誤或缺陷率（通常表示為bugs/KLOC ，即每千行代碼的錯誤數(shù)目或bugs/function-point ，即每個功能點的錯誤數(shù)目）；錯誤或缺陷率（按照小錯誤、大錯誤和嚴重錯誤來分類：需求中必須對“嚴重”錯誤進行界定，例如：數(shù)據(jù)完全丟失或完全不能使用系統(tǒng)的某部分功能）。3） 性能：包括對事務的響應時間（平均、最長）；吞吐量（例如每秒處理的事務數(shù)） ； 容量（例如系統(tǒng)可以容納的客戶或事務數(shù)）；降級模式（當系統(tǒng)以某種形式降級時可接受的運行模式）；

7、資源利用情況：內存、磁盤、通信等。4） 其它：包括用戶界面要求、聯(lián)機幫助系統(tǒng)要求、法律許可、外購構件，以及操作系統(tǒng)、開發(fā)工具、數(shù)據(jù)庫系統(tǒng)等設計約束。4. 支持信息支持信息用于使軟件需求規(guī)格說明書更易于使用。它包括：目錄、索引、附錄等。附錄：用例說明模板1（ 經(jīng)典模板 ）編者說明：隨著UML的日益普及，用例（Use case）分析技術也在需求實踐中廣泛被采用。但是也有許多團隊在使用該技術時，只畫出了用例圖，而缺少了用例說明，其實這是一個嚴重的誤區(qū)。而本模板就將指導你編寫該說明。1 .用例名稱1.1 簡要說明簡要說明用例的作用和目的。該小節(jié)的篇幅不要太長。2 .上下文圖在此小節(jié)中，有一個只包括本用

8、例和所有與該用例相關的Actor 和其它用例組成的，一個用例圖的局部。3 . 事件流3.1 基本流當 Actor 采取行動時，用例也就隨即開始。用例總是由Actor 啟動的， 用例應說明Actor的行為及系統(tǒng)的響應，可按照Actor與系統(tǒng)進行對話的形式來逐步引入用例。要注意的是，用例描述應該說明系統(tǒng)內發(fā)生的事情，而不是事件發(fā)生的方式與原因。如果進行了信息交換， 則需指出來回傳遞的具體信息。 例如，只表述主角輸入了客戶信息就 不夠明確。最好明確地說主角輸入了客戶姓名和地址。 當然你也可以通過項目詞匯表來定義 這些信息，使得用例中的內容被簡化，從而不致于讓用例描述陷入過多的細節(jié)內容。如果存在一些相

9、對比較簡單的備選流，只需少數(shù)幾句話就可以說明清楚，那么也可以直接在這一部分中描述。但是如果比較復雜，還是應該單獨放在備選流小節(jié)中描述。一幅圖勝過千言萬語，因此建議在這一小節(jié)中，除了敘述性文字之外，你還可以引用UML中的活動圖、順序圖、協(xié)作圖、狀態(tài)圖等手段，對其進行補充說明。3.2 備選流3.2.1 第一備選流正如前面所述，對于較復雜的備選流應單獨地說明。3.2.1.1 備選支流如果能使表達更明確，備選流又可再分為多個支流。3.2.2 第二備選流在一個用例中很可能會有多個備選流。為了使表達更清晰，應將各個備選流 分開說明。使用備選流可以提高用例的可讀性，并防止將用例分解為過多的層次。 應切記，用

10、例只是文本說明，其主要目的是以清晰、簡潔、易于理解的方式記錄 系統(tǒng)的行為。4 .非功能需求在這個小節(jié)中，主要對該用例所涉及的非功能性需求進行描述。由于其通常很難以在 事件流中進行表述，因此單列為一小節(jié)進行闡述。這些需求通過包括法律法規(guī)、應用程序標 準、質量屬性（可用性、可靠性、性能、支持性等） 、兼容性、可移植性，以及設計約束等 方面的需求。在這些需求的描述方面，一定要注意使其可度量、可驗證，否則就容易流于形 式，形同擺設。5 .前置條件用例的前置條件是執(zhí)行用例之前必須存在的系統(tǒng)狀態(tài)。6 .后置條件用例的后置條件是用例一執(zhí)行完畢系統(tǒng)可能處于的一組狀態(tài)。7 .擴展點此用例的擴展點，通常是用例圖中

11、的extent關系。用例說明模板2（單列表格式）編者說明：如果你覺得文本描述不夠清晰，也可以采用如本文檔模板所示的表格式的描述方式。用例#用例名應是一個動詞短語，應讓讀者一目了然地從名字中就可以 知道該用例的目標。使用語境用例目標，是一個較長的描述，甚至包括觸發(fā)條件。范圍用例的設計范圍，在設計時將系統(tǒng)作升-個黑盒來考慮。級別概要、用戶目標、子功能三者之一。主執(zhí)彳,者也就是該用例的主 Actor,在此應列出其名稱，并簡要描述。項目相關人 員利益項目相關人員利益項目相關人員名稱項目相關人員取得的利益前置條件也就是激發(fā)該用例，所應該滿足的條件。后置條件也就是該用例完成之后，將執(zhí)行什么動作。成功保證描

12、述當目標完成后，環(huán)境的變化情況。觸發(fā)事件什么引發(fā)用例，例如時間事件。描述步驟活動1在這里寫出觸發(fā)事件到目標完成以及清除的步驟。23擴展步驟分支動作1a引起分支的條件活動或子用例名稱技術和數(shù)據(jù) 變化1變化列表用例說明模板3（雙列表格式）編者說明：本模板是對上一模板的補充，如果你想更好地捕捉系統(tǒng)的響應，那么就可以采用本表 格所示的格式。有時，為了更好地捕獲系統(tǒng)的響應，對于場景描述（主成功場景、擴展場景）在上表 的基礎上變成如下表所示的雙列：步驟用戶系統(tǒng)用例說明模板4（文本式）編者說明：相信用過用例分析技術的，對用例應該多少細有很大的疑問，而 Alistair Cockburn率先 將其進行分級：概

13、要、用戶目標、子功能，如果你對他的思想有認同，則該模板就適合于你。1 .用例名：用例名應是一個動詞短語，應讓讀者一目了然地從名字中就可以知道該用例的目標。2 .使用語境：用例目標，是一個較長的描述，甚至包括觸發(fā)條件。3 .范圍：用例的設計范圍，在設計時將系統(tǒng)作為一個黑盒來考慮。4 .級別：用來表示該用例是在描述哪個級別上的功能，通常包括概要、用戶目標、 子功能三種。 這三種級別的劃分是 Alistair Cockburn在編寫有效用例一書是提出的。5 .主執(zhí)行者：也就是該用例的主 Actor,在此應列出其名稱，并給予簡要描述。1. 項目相關人員利益說明該用例對項目相關人員能夠帶來什么好處。2.

14、 前置條件：也就是激發(fā)該用例，所應該滿足的條件。3. 后置條件：也就是該用例完成之后，將執(zhí)行什么動作。4. 成功保證：描述當目標完成后，環(huán)境的變化情況。5. 觸發(fā)事件：什么引發(fā)用例，例如時間事件。6. 主成功場景在這里寫出觸發(fā)事件到目標完成以及清除的步驟。步驟編號：動作描述步驟編號：動作描述7. 擴展：在這里寫出擴展情況，每次寫一個擴展，每個擴展都應指向主場景的特定步驟。被改變步驟條件：動作或子用例被改變步驟條件：動作或子用例8. 技術和數(shù)據(jù)變化列表在這里寫出場景中因技術或數(shù)據(jù)變化而引起的可能分支。步驟或變化編號：變化列表步驟或變化編號：變化列表9. 相關信息 項目所需要的所有附加信息。數(shù)據(jù)要

15、求說明書（ISO 標準 ）編者說明：如果在你的項目中有大量要求數(shù)據(jù)存儲、數(shù)據(jù)采集等方面的需求，那么你就應該專門將這些需求進行整理，以數(shù)據(jù)要求說明書的形式表現(xiàn)出來。1 引言1.1 編寫目的說明編寫這份數(shù)據(jù)要求說明書的目的，指出預期的讀者。1.2 背景a.待開發(fā)軟件系統(tǒng)的名稱；b.列出本項目的任務提出者、開發(fā)者、用戶以及將運行該項軟件的計算站或計算機 網(wǎng)絡系統(tǒng)。1.3 定義列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。1.4 參考資料列出有關的參考資料。2數(shù)據(jù)的邏輯描述對數(shù)據(jù)進行邏輯描述時可把數(shù)據(jù)分為動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)。2.1 靜態(tài)數(shù)據(jù)列出所有作為控制或參考用的靜態(tài)數(shù)據(jù)元素。2.2 動態(tài)輸入數(shù)據(jù)列出動態(tài)輸入數(shù)據(jù)元素。2.3 動態(tài)輸出數(shù)據(jù)列出動態(tài)輸出數(shù)據(jù)元素。2.4 內部生成數(shù)據(jù)列出向用戶或開發(fā)單位中的維護調試人員提供的內部生成數(shù)據(jù)。2.5 數(shù)據(jù)約定說明對數(shù)據(jù)要求的制約。逐條列出對進一步擴充或使用方面的考慮而提出的對數(shù)據(jù)要求的限制。對于在設計和開發(fā)中確定是臨界性的限制更要明確指出。3數(shù)據(jù)的采集3.1 要求和范圍按數(shù)據(jù)元的邏輯分組來說明數(shù)