1、需求規格說明書1. 引言1.1 編寫目的本學生宿舍分配系統以公寓房間、入住學生為基礎信息源，可以對房間和床位分配，可以使教務處、學生處、保衛處、公寓管理中心、財務處等學校職能部門及學校學院領導隨時獲得全方位的公寓管理信息，實現信息共享，提高工作效率。本文檔從用戶、功能、性能、運行環境等各方面對系統進行了分析，以確保在系統開發過程中，確定好具體目標，使工作能有條不紊的進行，提高工作效率。1.2 背景很多學校特別是中等及高等院校中，學生在校住宿的情況極其普遍。隨著高校的擴招，需要住宿的學生人數和學生公寓樓房越來越多，宿舍管理人員的需求量也相應地增加。許多高校后勤實施社會化改革，學生住宿條件得到了很

2、大改善，宿舍安排上打破了原來按專業班級強制集中住宿的限制，可供學生選擇的余地也越來越大，相關部門對公寓管理的要求越來越高，導致公寓管理的難度越來越大，原來的手工管理已經無法適應，需要用信息化手段來實現。因此，開發一個學生宿舍分配軟件是十分必要的，希望能夠為廣大教師、校院領導、宿舍管理員和學生提供便利，加強學生住宿管理、規范高校公寓日常工作、提高公寓管理效能的有效工具。1.3定義用例圖 (Use Case) ：是指由參與者（ Actor ）、用例（ Use Case ）以及它們之間的關系構成的用于描述系統功能的動態視圖。呈現了一些參與者和一些用例，以及它們之間的關系，主要用于對系統、子系統或類的

3、功能行為進行建模。順序圖：是將交互關系表示為一個二維圖。縱向是時間軸，時間沿豎線向下延伸。橫向軸代表了在協作中各獨立對象的類元角色。類元角色用生命線表示。類圖 (Class diagram) ：是顯示了模型的靜態結構，特別是模型中存在的類、類的內部結構以及它們與其他類的關系等。類圖不顯示暫時性信息。狀態圖 (Statechart Diagram) ：是描述一個實體基于事件反應的動態行為，顯示了該實體如何根據當前所處的狀態對不同的事件做出反應的。活動圖（ activity diagram ）：是闡明了業務用例實現的工作流程。工作流程通常包括一個基本工作流程和一個或多個備選工作流程。工作流程的結構

4、使用活動圖來進行說明。協作圖 / 通信圖 (Communication Diagram)：而“協作”作為一個結構事物用于表達靜態結構和動態行為的概念組合，表達不同事物相互協作完成一個復雜功能。1.4 參考資料（ 1）殷建民 主編，軟件系統分析與設計，中國水利水電出版社，2008（ 2）學生宿舍基本需求（ 3） 2012 級軟件系統分析與設計實驗指導書（16 學時宿舍分配系統）2任務概述2.1目標本學生宿舍分配系統以公寓房間、入住學生為基礎信息源，可以對房間和床位分配，可以使教務處、學生處、保衛處、公寓管理中心、財務處等學校職能部門及學校學院領導隨時獲得全方位的公寓管理信息，實現信息共享2.2用

5、戶特點學生：若要住宿需提交住宿申請，然后等待分配。如有特殊要求，務必專門說明。一旦得到批準通知，可以查詢個人宿舍安排。住宿后若有特殊原因，可以申請調整宿舍或床位，但依然要經過審核、批準。一旦調換了宿舍，其所使用的設備也要隨之變更記錄。教師：分為班主任和輔導員。輔導員負責查看、初審學生提交的住宿申請，對基本符合要求的，轉交給宿舍負責人。班主任和輔導員可以隨時查看、了解所負責班級住宿學生的情況。宿舍負責人：負責對住宿申請進行綜合審查，通過的則以班為單位分配床位。可以隨時查看和了解宿舍的基本情況、所有住宿情況和設備使用情況，對特殊情況及時進行統計，并報送相關領導。學生一旦畢業或提出退宿，其宿舍和床位

6、會立即變空，等待重新分配使用。宿舍管理員：負責宿舍設備情況的記錄（購入登記、各建宿舍配置、損壞和修理登記、報廢登記）、每日查房結果記錄、學生晚歸記錄、宿舍具體情況管理（新房間登記、房間撤消、格局調整）。校院領導：可以隨時查看、了解學校和學院宿舍的詳細信息、學生住宿狀況和宿舍管理員的基本情況以及每日查房的情況。2.3假定與約束經費限制： 由于是學習之作，資金的不足限制了本軟件的研發。開發期限 ; 在時間方面，只能在課余時間完成本軟件，對時間的安排需做到合理，恰當才能很好的完成本工程。3. 需求分析建模3.1 功能需求本學生宿舍分配系統以公寓房間、入住學生為基礎信息源，可以對房間和床位分配，可以使

7、教務處、學生處、保衛處、公寓管理中心、財務處等學校職能部門及學校學院領導隨時獲得全方位的公寓管理信息，實現信息共享。基本流程圖如下:3.1.2總體功能分析各類角色的大體功能分析：學生 : 填寫申請表、提交住宿申請、查看申請結果、申請宿舍調整輔導員 : 查看學生住宿情況、查看住宿申請、初審、返回申請結果給學生班主任：查看本班學生住宿情況宿舍負責人：復審、分配床位、查看住宿信息、宿舍住退更新、特殊情況報送領導宿舍管理員: 宿舍查房記錄、宿舍設備情況記錄、晚歸記錄、宿舍集體情況校院領導：查看宿舍詳細信息、查看住宿情況、宿舍管理員情況、每日查房情況具體用例圖如下：填寫申請表提交住宿申請查看申請結果學生

8、申請宿舍調整復審分配床位查看住宿信息宿舍住退更新宿舍負責人特殊情況報送領導查看學生住宿情況查看住宿申請初審輔導員班主任返回申請結果給學生宿舍查房記錄查看宿舍詳細信息宿舍設備情況記錄查看住宿情況晚歸記錄院校領導宿舍管理員宿舍管理員情況宿舍集體情況每日查房情況3.1.3功能模塊分析( 詳述 學生申請 )由學生申請住宿用例：當學生登錄后，進入申請界面，填寫申請報告，出現兩種情況，即填寫正確或錯誤 / 部分錯誤，對應的成功提交申請或返回重新填寫申請.構建活動圖、協作圖、順序圖等來完成功能的具體分析。活動圖 ：狀態圖：學生申請這一事件對應的狀態：首先是要進行申請表的填寫預準備工作，即新建一張空白申請表，

9、進行填寫，完成后進行提交，即等同于進入等待審核狀態；等待后臺審核完成后，學生進行查看可以找到審核通過不通過以及不通過（部分不符合要求）三種狀態，一次審核通過后二審，產生批準不批準兩種狀態，批準通過，進入入住狀態。新建批準保存已入住審核通過不批準提交審核不通過部分通過順序圖 :根據流程圖和活動圖，可以建立學生申請的工作順序圖，首先是登陸到首頁進入申請界面， 申請表的填寫與是否可以成功提交由提交控制檢測并返回可申請 / 不可申請 / 有錯重新填寫，提交成功則學生等待來自輔導員以及宿舍管理員的的審核結果以及宿舍分配結果。協作圖：3.2 性能需求在進行向數據庫文件提取數據時，要求數據記錄定位準確，在往

10、數據庫文件數組中添加數據（如申請表，住宿信息等）時，要求輸入準確學生姓名，身份證，學號，班級，宿舍號等，按需求設定字符數。（ 1）查詢類頁面響應時間=3s（ 2）更新處理時間，如新建、提交等最長時間不超過2s。（ 3）數據的轉換和傳送時間，如遠程數據傳輸不超過5s。3.3 數據需求3.3.1輸入輸出數據要求1） 宿舍的詳細數據、學生住宿的情況以及宿管人員的具體數據要完整保管，且一旦發生變化，必須及時變更記錄。2） 上述數據要能夠導出到excel文件中，或從excel文件導入。3） 分配床位時可以采取二種方法： 第 1 是按照一定的算法進行自動分配， 第 2 是針對特殊要求進行手工分配4） 學生

11、住宿需要記錄的內容主要包括：學號、姓名、所屬學院、所屬系、宿舍房間號、床鋪號、柜子號、入住時間、聯系電話等。5） 每個房間需要記錄的內容主要包括：宿舍房間號、面積、可容納人數、目前空床數、6） 為簡化宿舍分配過程中學生信息的重復錄入，保證數據的一致性和統一性，最好可利用現行的學籍管理系統中的信息。類圖分析：用戶主要分為學生和職工兩大類，學生類和職工類繼承于people 類，而教師類、領導類、宿舍負責人類和宿舍管理員類繼承于職工類，輔導員和班主任類繼承于教師類；學生與輔導員、班級、住宿登記表、床位、宿舍、住宿申請等都是關聯關系。3.4 故障處理要求正常使用時不應出錯，對于用戶的輸入錯誤應給出適當的改正提示。若運行時遇到不可恢復的系統錯誤，也必須保證數據庫完好無損，可以通過日志來了解故障現象、發生時間。3.5 其他專門要求（ 1）進度需求：系統開發的階段進度要求。（ 2）運行環境需求：平臺、體系結構、設備要求。（ 3）培訓需求：無實體培訓，系統配