SRS文档
負責人：韓朝燕
1什么是用例？
? ? ? 在介始用例方法之前，我們首先來看一下傳統的需求表述方式-"軟件需求規約"(Software Requirement Specification)。傳統的軟件需求規約基本上采用的是功能分解的方式來描述系統功能，在這種表述方式中，系統功能被分解到各個系統功能模塊中，我們通過描述細分的系統模塊的功能來達到描述整個系統功能的目的。一個典型的軟件需求規約可能具有以下形式：
?
? ? ?采用這種方法來描述系統需求，非常容易混淆需求和設計的界限，這樣的表述實際上已經包含了部分的設計在內。由此常常導致這樣的迷惑：系統需求應該詳細到何種程度？一個極端就是需求可以詳細到概要設計，因為這樣的需求表述既包含了外部需求也包含了內部設計。在有些公司的開發流程中，這種需求被稱為"內部需求"，而對應于用戶的原始要求則被稱之為"外部需求"。
? ? ? 功能分解方法的另一個缺點是這種方法分割了各項系統功能的應用環境，從各項功能項入手，你很難了解到這些功能項是如何相互關聯來實現一個完成的系統服務的。所以在傳統的SRS文檔中，我們往往需要另外一些章節來描述系統的整體結構及各部分之間的相互關聯，這些內容使得SRS需求更象是一個設計文檔。
?
1.1 參與者和用例
? ? ? 從用戶的角度來看，他們并不想了解系統的內部結構和設計，他們所關心的是系統所能提供的服務，也就是被開發出來的系統將是如何被使用的，這就用例方法的基本思想。用例模型主要由以下模型元素構成：
參與者(Actor)?
參與者是指存在于被定義系統外部并與該系統發生交互的人或其他系統，他們代表的是系統的使用者或使用環境。
針對我們的此次項目分析：
管理者：
? ? ? ? ? 輸入數據
? ? ? ? ? 管理者輸入相應的登錄名和密碼進入相應用戶界面。
? ? ? ? ? 輸出數據
? ? ? ? ? 根據用戶所要查詢的內容輸出相應信息。
? ? ? ? ? 更改數據
? ? ? ? ? 可以對教室有關信息進行查詢，修改，增加，刪除。
用戶：
? ? ? ? ?注冊
? ? ? ? ?可以通過界面進行信息注冊。
? ? ? ? ?登入
? ? ? ? ?通過界面登入并進行查看。
用例(Use Case)?
用例用于表示系統所提供的服務，它定義了系統是如何被參與者所使用的，它描述的是參與者為了使用系統所提供的某一完整功能而與系統之間發生的一段對話。
針對我們的此次項目分析：
? ? ? ?管理者對教室的管理，根據教室的課程表的情況對數據庫中的信息進行插入、刪除、更新操作。
? ? ? ?用戶可以在注冊界面進行注冊或登入界面查找某天某個時間段空閑教室的情況。
通訊關聯(Communication Association)?
通訊關聯用于表示參與者和用例之間的對應關系，它表示參與者使用了系統中的哪些服務（用例），或者說系統所提供的服務（用例）是被哪些參與者所使用的。
針對我們的此次項目分析：
? ? ? ?此項目為參與者提供查找空教室的相關信息，用戶登入輸入查找的信息管理者會通過用戶所輸入的信息把相關的數據輸出到界面
?
1.2用例方法的優點
? ? ? 用例方法完全是站在用戶的角度上（從系統的外部）來描述系統的功能的。在用例方法中，我們把被定義系統看作是一個黑箱，我們并不關心系統內部是如何完成它所提供的功能的。用例方法首先描述了被定義系統有哪些外部使用者（抽象成為Actor），這些使用者與被定義系統發生交互；針對每一參與者，用例方法又描述了系統為這些參與者提供了什么樣的服務（抽象成為Use Case），或者說系統是如何被這些參與者使用的。所以從用例圖中，我們可以得到對于被定義系統的一個總體印象。
? ? ? 與傳統的功能分解方式相比，用例方法完全是從外部來定義系統的功能，它把需求與設計完全分離開來。在面向對象的分析設計方法中，用例模型主要用于表述系統的功能性需求，系統的設計主要由對象模型來記錄表述。另外，用例定義了系統功能的使用環境與上下文，每一個用例描述的是一個完整的系統服務。用例方法比傳統的SRS更易于被用戶所理解，它可以作為開發人員和用戶之間針對系統需求進行溝通的一個有效手段。
? ? ? 在RUP中，用例被作為整個軟件開發流程的基礎，很多類型的開發活動都把用例作為一個主要的輸入工件(Artifact)，如項目管理、分析設計、測試等。根據用例來對目標系統進行測試，可以根據用例中所描述的環境和上下文來完整地測試一個系統服務，可以根據用例的各個場景(Scenario)來設計測試用例，完全地測試用例的各種場景可以保證測試的完備性。
2. 建立用例模型
使用用例的方法來描述系統的功能需求的過程就是用例建模，用例模型主要包括以下兩部分內容：
用例圖(Use Case Diagram)?
確定系統中所包含的參與者、用例和兩者之間的對應關系，用例圖描述的是關于系統功能的一個概述。
?
?
2.1 尋找參與者
所謂的參與者是指所有存在于系統外部并與系統進行交互的人或其他系統。通俗地講，參與者就是我們所要定義系統的使用者。尋找參與者可以從以下問題入手：
? ? ? ?參與者可以是教師、學生，也可以是管理員，通過界面可以可以查看教室的情況，管理者可以增刪改查的教室管理，更好的為用戶服務。
2.2 確定用例
找到參與者之后，我們就可以根據參與者來確定系統的用例，主要是看各參與者需要系統提供什么樣的服務，或者說參與者是如何使用系統的。尋找用例可以從以下問題入手（針對每一個參與者）：
? ? ? ? ?教室的管理系統可以方便用戶對它的使用，可以找到空教室進行自習也可以對感興趣的課程進行蹭課，更好的利用時間。
? ? ? ? ?管理者在系統中創建、修改、刪除、存儲數據，可以在數據庫中對各個教室的情況進行這些操作。
? ? ? ? ?系統對用戶的輸入信息進行分析查找返回用戶所需要的信息。
? ? ?在用例的抽取過程中，必須注意：用例必須是由某一個主角觸發而產生的活動，即每個用例至少應該涉及一個主角。如果存在與主角不進行交互的用例，就可以考慮將其并入其他用例；或者是檢查該用例相對應的參與者是否被遺漏，如果是，則補上該參與者。反之，每個參與者也必須至少涉及到一個用例，如果發現有不與任何用例相關聯的參與者存在，就應該考慮該參與者是如何與系統發生對話的，或者由參與者確定一個新的用例，或者該參與者是一個多余的模型元素，應該將其刪除。
? ? ?可視化建模的主要目的之一就是要增強團隊的溝通，用例模型必須是易于理解的。用例建模往往是一個團隊開發的過程，系統分析員在建模過程中必須注意參與者和用例的名稱應該符合一定的命名約定，這樣整個用例模型才能夠符合一定的風格。如參與者的名稱一般都是名詞，用例名稱一般都是動賓詞組等。
? ? ?對于同一個系統，不同的人對于參與者和用例都可能有不同的抽象結果，因而得到不同的用例模型。我們需要在多個用例模型方案中選擇一種"最佳"（或"較佳"）的結果，一個好的用例模型應該能夠容易被不同的涉眾所理解，并且不同的涉眾對于同一用例模型的理解應該是一致的
轉載于:https://www.cnblogs.com/lvcaixia/p/4541584.html
總結
- 上一篇： php内置函数
- 下一篇： li:nth-child()和 li:n