飯堂管理系統需求尺寸說明書編撰人員：主任：班委：目錄1、目的：12、參考資料：13、可行性剖析：13.1、食堂管理系統問題剖析13.2、可行性剖析14、功能需求：3（1）功能界定：3（2）功能描述：35、性能需求：56、數據流圖：66.1頂樓數據流圖：66.2第二層數據流圖：86.3第三層數據流圖：97、數據字典：91、目的：隨著計算機的迅速發展，計算機被廣泛的應用到各個領域，因為當前校區的規模不斷擴大，中學生數目不斷降低，中學生信息量也成倍下降，飯堂管理工作成為中學各項管理工作的一個重要部份。面對龐大的信息量，怎樣有效的提升飯堂管理工作的效率是中學急需解決的問題。為此我們提出了借助計算機軟件管理飯堂系統，這樣除了增強了工作效率，也防止了先前手工作業的麻煩，因而促使管理者才能確切，有效的管理餐飲。2、參考資料：《軟件工程——原理、方法與應用》《需求剖析報告模板》3、可行性剖析：3.1、食堂管理系統問題剖析信息社會的高科技，商品經濟化的高效益，使計算機的應用已普及到經濟和社會生活的各個領域。為了適應當代學院生高度強烈的時間觀念，飯堂管理系統以實時性、高效性的特征著力的滿足了學院校園的飯堂用餐問題，減少了中學生因過于集中而導致的時間浪費，飯堂職工因不了解市場需求而導致的飯菜短缺、外賣不能及時送達，飯堂管理員因不了解中學生需求而作的錯誤決策等等。
各大院校都在擴招，校園的設備和生活區都已達到飽和狀態，尤其是飯堂。以本校為例，雖非3個飯堂，但三萬多的師生的群體仍是存在多種困難。人流分布不均，飯堂營業時間不定，飯菜種類雜多等等都讓飯堂的管理員無可怎奈，同時也讓中學生對其喪失好感。為了解決以上的問題，讓飯堂管理員要想有效的把握飯堂的運行現況，中學生的需求趨勢，飯堂信息、數據進行合理管理，因而應開發出一套適宜飯堂合理運行的管理系統。3.2、可行性剖析小組成員及課題開發軟件名稱：飯堂管理系統。項目任務提出者：中國礦業學院計算機大學軟件工程課程設計小組小組成員：趙之克等六人本項目是采用C#為開發軟件的數據庫服務程序。二．現有的飯堂管理系統的狀況現有的飯堂餐飲管理系統均是以人為主體的，須要很的人力、物力、財力食堂點餐系統，且效率不是很高，因為人為誘因在系統營運時也可能形成人為的失誤。中學生因過于集中而導致的時間浪費，飯堂職工因不了解市場需求而導致的飯菜過剩、外賣不能及時送達，飯堂管理員因不了解中學生需求而作的錯誤決策等。新系統的構想基本說明研制飯堂管理信息系統，改善先前飯堂人流不均勻，菜譜信息修改不及時，外賣混亂的現象，使飯堂那個舊的人員統計信息的方法淘汰，利用該系統的結果可以達到以下目的：首先，便捷中學生可以安全的查找自己想要的各個飯堂人流情況，菜譜，營業的現況和進行外賣點餐。
也可以通過系統的互動環節對飯堂進行評價；其次，讓飯堂的前后臺職工、外賣職工通過使用本系統可以及時把握中學生需求的動態，提升飯堂的管理效率；優點剖析因為系統的極好的兼容性，對于原先的軟件和系統都留下了插口，無需作任何更改飯堂，即可運行。系統完成后可大大提升提高現代飯堂管理水平和服務檔次；創造可靠、高效、便捷餐飲管理環境最大限度減少餐飲管理營運成本；提升經營效益。適應市場經濟需求，提升工作效率，推廣電子化進程。可行性的剖析技術可行性因為系統采用C#開發設計主界面，借助SQL2000做數據庫，這兩個工具都是谷歌的產品，在兼容性上比較好，但是比較容易實現，所以我們借助現有的技術完全可以設計出滿足用戶所要求的功能的系統，并在規定的年限內完成。2）法律方面的可行性所有軟件都選用正版，所有技術資料都由提出方保管，協議制訂確定毀約責任。3）使用可行性使用本軟件人員要求有一定計算機基礎的人員,系統管理員要求由計算機的專業知識,所有人員都要經過培訓，管理人員也需經通常培訓，經過培訓人員將會熟練使用本軟件。4、功能需求：（1）功能界定：a貨運管理b財務管理c職工信息管理（2）功能描述：a貨運管理：管理各類用具、食品的使用情況，采購情況，對商品的入庫，領料，運輸，結算的管理。
要有明細賬，記載出入庫的詳盡情況。供飯堂負責人員和采購人員還有審查工作，實現對于每晚各部門中所使用的貨物進行初審和查看現有庫存情況。b財務管理：對成本收益的綜合剖析。成本包括固定成本（人員薪資、水電、稅等）變動成本（菜、酒、米等的采購成本）。收入指每晚的銷售收入。能核算每晚、每月、每年、以及任何一段時間的成本，收益。微機室核計每晚各單位、各窗口的利潤情況并將結果送入數據庫供管理層查詢；c職工信息管理：對每個職工的姓名、性別、年齡、身份證號碼、聯系方法、家庭住址等個人信息和工作職務、工齡、工作考評成績、年度評比記錄等工作信息記錄到數據庫文件中，為職工的薪水領取，人員調動等管理活動提供參考信息。管理系統應容許管理人員對數據進行查詢、修改、添加、刪除的操作。飯堂管理系統職工信息管理財務管理貨運管理職工信息查詢職工信息更改帳目統計收支核算運輸庫存職工信息添加職工信息刪掉資金領取采購財務匯總職工薪資分配對上述各項功能進行集中、分塊剖析，根據結構化程序設計的要求，得到如圖所示的這個系統的功能模塊圖。5、性能需求：數據可靠性：要求保證能及時正確保存和更新相關信息，還能查詢到所要查詢的相關信息并保證其正確率。
軟件運行的效率性：要求及時響應用戶的操作懇求，保證通常操作的響應時間應在1－2秒內。適應性：要求滿足運行環境在容許操作系統之間的安全轉換和與其它應用軟件的獨立運行要求，與通常軟件沒沖突情況。安全性：要求數據的安全保密性，不能被管理者以外的人隨便改寫數據信息。為此，要做好加密保密的處理。對用戶要有身分驗證等多重保密處理。界面簡練：要求設計的軟件要用戶滿意，好學好懂，界面用語緊貼用戶的職業，系統要確切響應用戶的具體需求，與用戶的意圖統一，讓用戶滿意。6、數據流圖：6.1頂樓數據流圖：注：這個飯堂管理系統面向的用戶主要是貨運部、內務部、財務部這三個部門。貨運部負責貨運管理，主要涉及到采購、運輸和庫存三個方面。內務部主要工作于人事管理和制度完善，主要關心職工信息的管理和對職工薪資分配。財務部負責飯堂的財務管理，管理飯堂各項工作的開支和收入。頂樓數據流圖給出了這三個主要部門和整個飯堂管理系統之間的信息交流。貨運部向系統提供訂單，主要是飯堂的糧食、蔬菜、油鹽等輔料、衛生用品的開支等。待系統處理好用戶的要求以后，系統會向貨運部遞交庫存的所有物品的詳盡存貨單。內務部可以通過這個管理系統處理職工信息，包括職工信息的查詢、修改、添加、刪除、還有職工薪資分配的記錄。
內務部管理人員向系統提供操作懇求后，待系統處理好后，向用戶提供操作結果。財務部通過該系統處理財務食堂點餐系統，對各項資金的入出進行處理。系統處理好后，會遞交給用戶一張財務報表。6.2第二層數據流圖：注：貨運管理和財務管理之間通過貨運帳單這個數據儲存文件構建關聯，職工信息管理和財務管理之間通過職工資金領取表這個數據儲存構建關聯。6.3第三層數據流圖：注：貨運部的采購會形成采購帳單，運輸會形成運輸帳單，庫存會形成庫存記錄，而從庫存記錄中我們可以得出飯堂售出飯菜的信息。這種加上職工薪資、損耗成本，一起提供給帳目統計處理。帳目匯總表中記錄的有飯堂的收入和開支的信息匯總。7、數據字典：數據元素：名稱：訂貨編號別稱：取值：字符型寬度:10個字節描述：采購的物品位置：訂貨單名稱：存貨編號別稱：取值：字符型寬度:10個字節描述：庫存的物品位置：存貨單名稱：郵費帳單編號別稱：取值：字符型寬度:10個字節描述：每次運輸所耗費的費用位置：郵費帳單名稱：職工號別稱：取值：字符型寬度:10個字節描述：職工基本屬性位置：職工信息表，收支帳單，薪資清單名稱：薪資清單編號別稱：取值：字符型寬度:10個字節描述：記錄職工薪資領取情況位置：薪資清單數據流：名稱：存貨詳單描述：根據庫房庫存編撰的清單來源：庫房去處貨運部組成各類物品的統計表流通量：名稱：訂單描述：須要的物品清單來源：貨運部去處采購員組成各類缺乏的物品流通量：名稱：運輸單描述：所運輸的物品清單來源：采購員去處貨運部組成運輸的物品集合流通量：名稱：薪資清單描述：職工的薪水領取列表來源：帳目匯總表去處財務部組成職工的薪水流通量：名稱：收支帳單描述：根據收支估算出的清單來源：收支核算去處財務匯總組成平常所耗費的費用與收入流通量：名稱：操作懇求描述：
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
