軟件工程需求工程12需求工程需求的定義及分類需求工程需求獲取需求分析需求驗證需求管理需求分析案例結構化需求分析面向對象需求分析1.需求定義IEEE定義：用戶為解決某個問題或達到某個目標而需具備的條件或能力。系統或系統組件為符合合同、標準、規范或其他正式文檔而必須滿足的條件或必須具備的能力。上述第一項或第二項中定義的條件和能力的文檔表達。寬泛地講，需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品要做什么。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束。3軟件需求重要性“好的開始就等于成功的一半”“Garbagein,garbageout！”FrederickBrooks在他1987年經典文章“NoSilverBullet”中闡述了需求的重要性：開發軟件系統最困難的部分就是準確說明開發什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其它軟件系統的接口。此工作一旦做錯，將會給系統帶來極大的損害，并且以后對它修改也極為困難。需求是產品的根源，需求工作的優劣對產品影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。4軟件需求重要性5需求層次6需求層次業務需求系統建立的戰略出發點，表現為高層次的目標（Objective），它描述了組織為什么要開發系統。參與各方必須要對高層次的解決方案達成一致，以建立一個共同的前景（Vision）。用戶需求執行實際工作的用戶對系統所能完成的具體任務的期望，描述了系統能夠幫助用戶做些什么。系統需求用戶對系統行為的期望，一系列的系統行為聯系在一起可以幫助用戶完成任務，滿足業務需求系統需求可以直接映射為系統行為，定義了系統中需要實現的功能，描述了開發人員需要實現什么78業務需求網站上提供酒店促銷價格的預訂，以吸取對一部分對價格敏感的用戶。用戶需求總結出幾種可以在我們網站上銷售的促銷方式（和酒店訂協議）系統能夠錄入這些促銷價格網站可以顯示并預訂系統需求促銷價格錄入促銷價格查詢預訂推薦訂單處理異常情況處理（提前離店，延住）結算界面顯示從業務需求到系統需求軟件需求9功能需求

(Functionalrequirements)它是對系統應該提供的服務、功能以及系統在特定條件下的行為的描述。它與軟件系統的類型、使用系統的用戶等相關，有時需要詳細描述系統的功能、輸入/輸出、異常等，有時還需要聲明系統不應該做什么。用戶的功能需求可以高層次的說明系統需要做的功能，但軟件/系統的功能需求必須要是詳細的，可操作的。10非功能需求

(Non-functionalrequirements)定義了系統的屬性或約束，例如可靠性、響應時間、數據存儲要求等。非功能需求可能比功能需求更難達到。對非功能需求應該定義可以客觀評價的指標，以便通過測試來顯示它們被滿足。非功能需求無法滿足可能導致系統無法使用。包括產品/質量需求、機構需求和外部需求。1112領域需求

(Domainrequirements)它是由軟件系統的應用領域所決定，它描述了系統具有領域特征的功能或特性。新的功能需求已有功能的約束特殊的計算領域需求無法滿足可能導致系統無法正常工作。13例：圖書館系統有一大學圖書館系統，該系統能夠為學生和教工提供查詢、借閱圖書以及文獻資料的服務。基本數據維護功能基本業務功能數據管理與查詢功能14功能需求基本數據維護提供使用者錄入、修改并維護基本數據的途徑。基本數據包括讀者的信息，可以對這些信息進行修改和更新。基本業務功能新書編目、入庫；讀者借、還書籍的登記功能；書籍預留功能；書籍遺失登記功能等。數據管理與查詢功能對所有圖書信息及作者信息進行統一管理維護的功能；提供對各類信息的查詢的功能，如對本圖書館的書籍信息、用戶借書信息、還書信息、預留信息等進行查詢。15非功能需求系統安全性需求為保證系統安全性，對本圖書館的各項功能進行分級、分權限操作。系統效率需求各類查詢操作需要在5S內完成。每次借書/還書登記在1S內完成。系統可靠性需求借書/還書登記出錯率為1/10000次。系統故障率為1/500h。16領域需求圖書編目要求按照《中國圖書館分類法》進行。由于版權限制，某些文獻資料只能在圖書館規定的閱覽室閱讀，不能出借。17第一條需求是遵循我國圖書管理的規定，執行對圖書的分類管理的標準。第二條需求則是版權法對圖書館文獻資料的保護的需要，描述了對一類文獻資料有限制的使用和服務。優秀需求的特征完整性正確性可行性必要性劃分優先級無二義性可驗證性182.需求工程把所有與需求直接相關的活動通稱為需求工程。對系統應該提供的服務和所受到的約束進行理解、分析、建立文檔、檢驗以及跟蹤管理的過程。19需求開發過程域

需求開發的目的是通過調查與分析，獲取用戶需求并定義產品需求。

需求獲取的目的是通過各種途徑獲取用戶的需求信息，產生《用戶需求說明書》。

需求分析的目的是對各種需求信息進行分析，消除錯誤，刻畫細節等。需求定義的目的是根據需求調查和需求分析的結果，進一步定義準確無誤的軟件需求，產生《軟件需求規格說明書》。系統設計人員將依據《軟件需求規格說明書》開展系統設計工作。需求管理過程域

需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認是指開發方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業合同效果。

需求跟蹤是指通過比較需求文檔與后續工作成果之間的對應關系，建立與維護“需求跟蹤矩陣”，確保產品依據需求文檔進行開發。需求變更控制是指依據“變更申請－審批－更改－重新確認”的流程處理需求的變更，防止需求變更失去控制而導致項目發生混亂。

二個過程域需求開發和需求管理的邊界2.1需求獲取需求獲取是需求工程的主體，非常困難，主要原因：

缺乏領域知識存在默認知識存在多個知識源雙方誤解需求客戶可能的偏見…22需求開發過程23需求獲取技術建立聯合分析小組用戶領域專家分析員用戶訪談結構化面談非結構化面談問卷調查表觀察用戶工作流程原型法…24功能性需求獲取技術非功能需求獲取易用性–用戶的技能水平是什么？–用戶熟悉什么界面標準？–那些文檔需要提供（用戶手冊，操作手冊…）？可靠性–系統的可靠性，可用性的指標是什么？–用戶可用接受系統重啟嗎？–哪些、多少數據丟失會嚴重影響業務？性能–系統反應速度為多少？–哪些用戶的任務對時間是有要求的？–最多可用支持多少并發用戶訪問？可支持性–系統可以預計的擴展有哪些？–誰來維護系統？–有沒有計劃將系統移植到新的硬件、軟件平臺？…25需求獲取初步成果用戶需求說明書262.2需求分析分析包括將高層的需求分解成具體細節、建立需求模型，以及評估可行性和協商需求優先級。結構化分析面向對象分析27結構化分析

StructuredAnalysis(SA)將軟件系統抽象為一系列的邏輯加工單元，各單元之間以數據流發生關聯。基本思想——“分解”和“細化”分解：對于一個復雜的系統，為了將復雜性降低到可以掌握的程度，可以把大問題分解成若干小問題，然后分別解決。細化：分解可以分層進行，即先考慮問題最本質的屬性，暫把細節略去，以后再逐層添加細節，直至涉及到最詳細的內容。28結構化需求模型（結構化分析成果）功能模型數據流圖DFD(DataFlowDiagram)加工規格說明PSPEC

(ProcessSpecification)數據模型數據字典DD(DataDictionary)實體關系圖ER圖(EntityRelationDiagram)行為模型狀態轉換圖STD(StatusTransformDiagram)控制規格說明CSPEC(ControlSpecification)29結構化需求模型30面向對象分析

ObjectOrientedAnalysis(OOA)基于用例的面向對象需求分析Jacobson提出了Usecase的概念及可視化的表示方法—Usecase圖Usecase被廣泛應用到了面向對象的系統分析中。基于用例的需求方法，已成為面向對象的分析方法的主流。31面向對象需求模型（面向對象分析成果）用例模型用例圖

用例規約補充規約術語表32面向對象需求模型33編寫需求文檔目的提供用戶審核和批準的系統說明是一個正式的文檔用來在用戶、工程師和管理者之間溝通需求需求文檔內容應該包括:–系統提供的功能說明–約束條件?系統運行的約束條件?開發流程的約束條件?系統屬性（如：系統應急處理屬性）–外部接口(系統環境)?定義和其他系統的接口?描述需要運行硬件?應用域的其他信息表現形式：用戶需求說明書、軟件需求規格說明書34需求文檔“用戶需求說明書”與“軟件需求規格說明書”的主要區別與聯系前者主要采用自然語言（和應用域術語）來表達用戶需求，其內容相對于后者而言比較粗略，不夠詳細。后者是前者的細化，更多地采用計算機語言和圖形符號來刻畫需求，產品需求是軟件系統設計的直接依據。35用戶需求說明書參考模板

36軟件需求規格說明書(SRS)

SoftwareRequirementsSpecification（需求分析的成果）軟件需求規格說明精確地闡述了一個軟件系統必須提供的功能和性能以及它所要考慮的限制條件。它不僅是系統測試和用戶文檔的基礎，也是所有項目規劃、設計和編碼的基礎。描述方法自然語言圖形化模型形式化規格說明37軟件需求規格說明書模板38編寫需求規格的原則保持語句和段落的簡短編寫具有正確的語法、拼寫和標點的完整句子。使用術語與詞匯表所定義的應該一致為了減少不確定性，必須避免模糊的、主觀的術語避免使用比較性詞匯392.3需求驗證需求驗證是指開發方和客戶方共同對《軟件需求規格說明書》進行評審，雙方對需求達成共識后作出承諾以建立需求基線。需求驗證的必要性需求是軟件開發的第一階段需求的可變性40需求驗證內容有效性檢查—指功能需求是否符合用戶所提出的需求一致性檢查—系統功能描述和約束是否一致完備性檢查—是否包含所有用戶的需求和約束可檢驗性檢查—能否設計出一組驗證的方法，確定檢查的標準41需求驗證方法需求評審需求評審的目的，是在軟件項目初期發現那些潛在的缺陷或錯誤，避免這些錯誤和缺陷遺漏到項目的后續階段。評審進入標準文檔符合模板規范文檔已經做過拼寫檢查和語法檢查已經檢查了文檔在版面安排上所存在的錯誤審查員已經獲得所需要的文檔在文檔中打印了行號以方便在審查中對特定位置的查閱所有未解決的問題都被標記為TBD包括了文檔中使用到的術語詞匯表42需求驗證方法評審退出標準已經明確闡述了審查員提出的所有問題已經正確修改了文檔修訂過的文檔已經進行了拼寫檢查和語法檢查所有TBD的問題已經全部解決，或者已經記錄下每個待確定問題的解決過程，目標日期和提出問題的人文檔已經登記入項目的配置管理系統432.4需求管理需求管理包括在項目開發過程中維護需求約定的完整性、準確性以及保持需求約定是最新約定的所有活動。44需求管理變更控制控制項目范圍的擴展必須遵循一個過程需求跟蹤需求跟蹤的目的是建立與維護“需求－設計－編程－測試”之間的一致性，確保所有的工作成果符合用戶需求。正向跟蹤。檢查SRS中的每個需求是否都能在后繼工作成果中找到對應點。逆向跟蹤。檢查設計文檔、代碼、測試用例等工作成果是否都能在SRS中找到出處。45小結需求的定義及分類需求開發需求獲取需求分析需求定義需求管理需求確認需求跟蹤需求變更控制463.需求分析案例結構化分析面向對象分析47需求分析的實現步驟獲得當前系統的物理模型：物理模型是對當前系統的真實寫照；抽象出當前系統的邏輯模型：去掉一些次要的信息，建立起反映系統本質的邏輯模型；建立目標系統的邏輯模型：分析目標系統與當前系統在邏輯上的差別，建立符合用戶需求的目標系統的邏輯模型；補充目標系統的邏輯模型：對目標系統進行補充、完善。48教材銷售的需求分析過程獲得當前系統的物理模型：物理模型是對當前系統的真實寫照；491.學生提交購書申請開購書證明2.學生憑證明開購書發票3.憑發票交款并領取領書單4.憑領書單領書教材銷售的需求分析過程抽象出當前系統的邏輯模型：去掉一些次要的信息，建立起反映系統本質的邏輯模型；50關注系統的功能，而不是執行功能的人或機構教材銷售的需求分析過程建立目標系統的邏輯模型：分析目標系統與當前系統在邏輯上的差別，建立符合用戶需求的目標系統的邏輯模型；51審查有效性的目的是為了開發票，目標系統可以合并這2個步驟以提高工作效率教材銷售的需求分析過程補充目標系統的邏輯模型：對目標系統進行補充、完善。52假設用戶決定交款和發書仍然由人工完成。建立結構化需求模型53DD（數據字典）：系統所涉及的各種數據對象的描述。DFD（數據流圖）：指明系統中數據是如何流動和變換的。PSPEC（加工說明）：功能說明。E-R圖（實體-聯系圖）：描述數據對象間的關系，它代表軟件的信息模型。STD（狀態-變遷圖）：用于指明系統在外部事件的變化下將會如何動作，表明系統的各種狀態以及各種狀態間的變遷。數據流圖（DFD）是描述系統中數據流程的圖形工具，它描述了將系統的邏輯輸入轉換為邏輯輸出所需的加工處理過程。54數據流圖（DFD）55數據流圖（DFD）56數據流圖（DFD）57教材銷售的DFD58數據字典(DD)定義（作用）DFD中所有數據定義的集合.用途分析階段的交流工具數據庫設計的基礎基本內容名字：描述對象的主要名稱；別名：第一項中對象的其他名字；內容描述：描述對象內容的符號；補充信息：關于數據類型、預置值、限制等的其他信息。59數據字典(DD)DFD中的數據類別只含一個數據的數據項（或數據元素）；由多個相關數據項組成的數據流；數據文件或數據庫。60數據字典(DD)數據流條目給出一個數據流定義方法，通常是列出該數據流的各個數據項。61數據流“發票”的字典條目數據字典(DD)“=”定義符號，表示對名字的定義；“+”與符號，表示由幾個數據項組成；“[]”選擇符號，表示括號中內容可任意選取一個項；“{}”重復符號，表示括號中的內容可重復使用零次或多次；“()”可選符號，表示括號中的內容可選可以由設計者確定取舍；“*…*”注釋符，表示兩個*號之間的內容為對條目的注釋62數據字典(DD)注：對較長或復雜的數據流可用分層次描述 發票=(學號)+姓名+{發票行}+書費合計 發票行=書號+單價+數量+總價不允許同一個數據在系統中使用不同的名字63數據字典(DD)數據文件條目給出文件的定義，通常是列出記錄組成數據項和文件的組織。也可以列出數據文件或數據庫(表單)的結構。64“各班學生用書表”的字典條目數據字典(DD)數據項條目包含在數據流或文件中的數據項（數據元素），如果某數據項是很明顯的，不會產生二義性，則允許不單獨編寫數據項條目。一般包括數據項名、別名、取值、備注。數據項字典條目示例年級：屬于數據文件“各班學生用書表”；數量：屬于數據流“發票”；書費合計：屬于數據流“發票。”65數據字典(DD)數據項“年級”的字典條目66數據字典(DD)數據項“數量”的字典條目數據項“書費合計”的字典條目67加工說明(PSPEC)加工說明對DFD中的每個加工所作的說明。由輸入數據、加工邏輯和輸出數據等部分組成。加工邏輯闡明把輸入數據轉換為輸出數據的策略。描述工具結構化語言判定表判定樹68加工說明(PSPEC)結構化語言是一種介于自然語言與程序設計語言之間的語言，既具有結構化程序的清晰易讀的優點，又具有自然語言的靈活性。可使用順序、選擇、循環等控制結構，形式簡潔，易于理解。判定表或判定樹采用表格的方式，適用于表達含有復雜判斷的加工邏輯。若在加工邏輯中存在順序、選擇、循環3種結構，則不宜單獨使用判定表。69加工說明(PSPEC)判定表能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。一張判定表由四部分組成：左上部列出所有條件，左下部是所有可能做的動作，右上部是表示各種條件組合的一個矩陣，右下部是和每種條件組合相對應的動作。判定表右半部的每一列實質上是一條規則，規定了與特定的條件組合相對應的動作。70加工說明(PSPEC)71加工說明(PSPEC)判定樹是判定表的變種，也能清晰地表示復雜的條件組合與應做的動作之間的對應關系。72實體關系圖(E-R)用于對復雜數據的數據分析和建模實體、屬性和關系二個實體之間的關系有1:1，1:m，m:n73關系教材銷售ER圖學生：學號、姓名班級：系編號，專業和班編號，年級教材：書號74班級使用教材學生屬于1nmm“各班學生用書表”的字典條目某醫院病房計算機管理中心科室：科名、科地址、科電話、醫生姓名病房：病房號、床位號、所屬科室名醫生：姓名、職稱、所屬科室名、年齡、工作證號病人：病歷號、姓名、性別、診斷、主管醫生、病房號一個科室有多個病房、多個醫生;一個病房只能屬于一個科室；一個醫生只屬于一個科室，但可負責多個病人的診治;一個病人的主管醫生只有一個。75實體關系圖(E-R)一個科室有多個病房、多個醫生;一個病房只能屬于一個科室；一個醫生只屬于一個科室，但可負責多個病人的診治;一個病人的主管醫生只有一個。76實體關系圖(E-R)科室(科名，科地址，科電話)病房(病房號，床位號，科名)醫生(工作證號，姓名，職稱，年齡，科名)病人(病歷號，姓名，性別，主管醫生，病房號)77控制流圖(CFD)與控制說明(CSPEC)適合實時系統的分析與DFD和PSPEC類似和DFD與PSPEC配合使用DFD用來表示加工模型；CFD用來表示控制模型(行為模型)PSPEC會引發CSPEC中描述的狀態轉換CSPEC中的加工激活信號會作用于數據流圖表示控制流和控制加工78控制流圖(CFD)與控制說明(CSPEC)79顯像管生產檢測過程：當顯像管在流水線上經過光電管時，光電管根據形狀判斷是那種規格的顯像管，由計數器進行累計。累計數據每30秒傳送工控機一次，工控機每半個小時取出累積數據保存到數據庫，同時將半小時數據供大屏幕顯示。為使管理人員可隨時了解各班生產情況，可通過班數據處理將半小時數據匯總成一個班的8小時數據。80顯像管生產檢測81顯像管生產檢測82結構化分析方法T.DeMarco的定義使用DFD、DD、結構化語言、判定表和判定樹等工具，來建立一種新的、稱為結構化說明書的目標文檔。是一種面向數據流的分析方法。基本步驟由頂向下對系統進行功能分解，畫出分層DFD圖；由后向前定義系統的數據和加工，編制DD和PSPEC；寫出SRS。83結構化分析方法分層DFD圖由頂向下，逐步細化從系統的基本模型開始，逐層的對系統進行分解每分解一次系統的加工數量就增多一些，每個加工的功能也更具體一些。繼續重復這種分解，直到所有的加工都足夠簡單，不必再進行分解為止。原則：先全局后局部，先整體后細節，先抽象后具體84分層DFD圖85分層DFD圖在多層數據流圖中頂層流圖僅包含一個加工，它代表被開發系統。它的輸入流是該系統的輸入數據，輸出流是系統的輸出數據；底層流圖是指其加工不需再做分解的數據流圖，它處在最底層；中間層流圖則表示對其上層父圖的細化。它的每一加工可能繼續細化，形成子圖。86分層DFD圖參考原則一個加工每次分解得到的子加工數最多不要超過7個。分解要自然，概念上要合理、清晰。只要不影響數據流圖的易理解性，可適當地多分解成幾部分，以減少分解圖的層數。一般在上層可分解得快些，而在中、下層應分解得慢些。87分層DFD圖分層DFD中易出現的問題父圖和子圖不平衡分解的速度太快不遵守加工編號規則88分層DFD圖父子平衡—父圖和子圖的輸入數據和輸出數據分別保持一致。特殊情況出錯信息處理在低層考慮數據流滿足某些關系89分層DFD圖加工的編號規則頂層加工不編號；第二層的加工編號為1、2、3、…、N號；第三層為1.1、1.2、1.3、…、N.1、N.2、N.3…號。數據文件與各層DFD也要按規則編號90教材購銷系統畫分層DFD的4步驟抽取數據流圖的四種成分：源點或終點、處理、數據存儲和數據流。繪制基本系統模型頂層數據流圖，基本系統模型細化基本系統模型，描繪系統的主要功能功能級數據流圖在圖中給處理和數據存儲都加上編號，便于引用和追蹤。對功能級數據流圖中描繪的系統主要功能進一步細化模塊級數據流圖91教材購銷系統擴展上例中的教材銷售系統，加入教材進購功能。使得當教材存量不足時，以“缺書單”通知書庫保管員，并在采購后更新教材存量。畫出擴展后系統的分層DFD。92頂層DFD在頂層DFD中，整個系統被看成是一個加工。數據的源點和終點是學生和書庫保管員。93第二層DFD在第二層DFD中，購銷系統被細化為2個子系統，銷售子系統和采購子系統。銷售和采購之間存在2項數據聯系。94第三層DFD

—銷售95第三層DFD

—采購96面向對象需求模型面向對象需求模型包括用例圖和用例規約補充規約術語表97用例圖用例圖描述了軟件系統同外部參與者之間的交互。用例是從外部可見的一個系統功能。參與者是與系統交互的任意實體。98用例之間的關系擴展(extend)包含(include)99用例之間的關系擴展(extend)：extend關系是對基用例的擴展，基用例是一個完整的用例，即使沒有子用例的參與，也可以完成一個完整的功能。基用例中將存在一個擴展點，只有當擴展點被激活時，子用例才會被執行。

extend關系在用例圖中使用帶箭頭的虛線表示(在線上標注<<extend>>)，箭頭從子用例指向基用例。100用例之間的關系包含(include)當兩個或多個用例中共用一組相同的動作，這時可以將這組相同的動作抽出來作為一個獨立的子用例，供多個基用例所共享。一個用例功能太多需要分解為多個小用例。include關系在用例圖中使用帶箭頭的虛線表示(在線上標注<<include>>)，箭頭從基用例指向子用例。101用例之間的關系102面向對象的需求模型畫用例圖編寫用例規約編寫補充規約編寫術語表103104選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。畫用例圖確認參與者確定用例繪制和檢查用例圖105確認參與者參與者：參與者是存在于系統之外并與系統進行交互的主體。可以是人、其他系統或硬件。為找到參與者，可以瀏覽系統的問題描述并分析以下問題系統開發完成后，哪些人會使用系統？系統需要從哪些主體獲取數據？系統會為哪些主體提供數據？系統會與哪些其他系統關聯？誰來維護系統？106107選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。確認參與者候選參與者學生教授“課程目錄”數據庫系統、舊系統財務系統補充參與者管理員108參與者：學生、教授、課程目錄系統、財務系統、管理員確定用例確定參與者后，可以根據參與者是如何與系統進行交互的來確定系統用例。尋找用例時可以針對每一個參與者分析以下問題參與者為什么使用系統？參與者是否會在系統內存儲、修改、訪問數據？是如何完成的？參與者是否將外部事件通知系統？系統是否將內部事件通知參與者？109110選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。學生注冊課程查看成績單登錄系統111選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。教授選擇所教課程登記成績登錄系統112選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。課程目錄系統選擇所教課程注冊課程113選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和所開設的系部等，將幫助學生做出選課決定。系統允許學生每學期選擇4門課，如果學生沒有選到主選課，還有兩門備選課可選。每門課的學生人數限3-10人。不滿3人的課程將被取消。另外，每個學期有一段時間允許學生更改所選課程。學生可在改時間段訪問系統并添加/刪除課程。某個學生的選課一旦結束，選課系統即將該學生本學期的賬單信息送到財務系統。如果在選課時某門課人數已滿，學生在提交信息前會被告知。學期結束，學生可進入系統查看自己的成績。成績屬于隱秘信息，系統必須提供額外的安全措施阻止未授權訪問。教授能訪問系統指定其主講的課程，他們也需要知道是哪些學生選擇了自己的課程。另外，教授也能登記學生的成績。財務系統傳送賬單114選課系統-問題描述開發一個學生“選課系統”。通過這個系統，學生可以選課和查看成績報告單，教授可以選擇所教的課和記錄學生成績。學校保留原有的“課程目錄”數據庫系統來維護課程信息，但該系統的性能很差。所以新系統必須確保能及時訪問舊系統的數據。但新系統只能讀取舊系統的數據而不能更改。每學期開始時，學生請求查看本學期開設的課程目錄。有關課程信息，包括教授名和