第一篇:河北省警綜平臺需求分析說明書
河北省三河市警綜平臺需求分析說明書
2011年12月25日
第一項目建設的背景........2 針對公安信息化建設的應用和現狀,從信息資源整體規劃設計、信息充分共享和綜合應用的角度出發,在充分保護和利用原有信息化建設基礎設施的前提下,研究構建一個警務綜
合信息應用平臺。............2
第二項目的目標與任務......2
2.1建設目標..............2
2.2建設任務..............3
第三系統建設技術要求......3
3.1 總體技術要求..........3
3.2 系統功能.............3
第四項目實施計劃及實施要求.......4
4.1第一階段、初期項目計劃......4
4.2第二階段:項目建立...........4
4.3第三階段:系統設計...........5
4.4第四階段:現場準備...........51
4.5第五階段:系統安裝...........5
4.6第六階段:系統測試與調試.....5
第五投標單位資質要求......6
第六項目驗收方式與內容...........6
第七資金預算和付款方式...........6
河北省三河市警綜平臺需求分析
第一項目建設的背景
針對公安信息化建設的應用和現狀,從信息資源整體規劃設計、信息充分共享和綜合應用的角度出發,在充分保護和利用原有信息化建設基礎設施的前提下,研究構建一個警務綜合信息應用平臺。
第二項目的目標與任務
2.1建設目標
以公安計算機網絡為依托,以案事件業務為主線,實現公安主要業務全面融合,面向全警,建立集數據采集、業務管理、數據交換、統計分析、查詢比對、法制監督、法律文書、日常辦公、績效考核等于一體的警務綜合信息應用平臺,實現公安各類業務信息的快速傳遞、完整收集和充分共享,促進公安各項業務工作的規范化建設推動公安組織體制和警務運作機制的改革,全面提升工作效率和水平,建立現代化數字警務和與其相適應的警務工作機制的基本框架,全面增強公安機關整體作戰和快速反應能力。
2.2建設任務
1、建立省級公安綜合信息查詢系統
2、省級綜合數據庫的建立與管理
3、實現數據集中整合4、實現統計數據和報表自動生成,系統的數據及時更新
5、建立信息統一接入接口為其它系統提供綜合數據服務
6、建立全網統一數字證書身份認證、授權管理及訪問控制機制
第三系統建設技術要求
3.1 總體技術要求
整個平臺建設應包括網絡系統平臺、存儲管理平臺、數據庫系統平臺、安全保障平臺、標準控制平臺、應用系統平臺和數據交換平臺 等七個部分。
警綜平臺涵蓋了網上執法辦案、實有人口管理、社區警務(基礎信息采集)三大業務域的主要業務工作。
3.2 系統功能
執法辦案、派出所建設、管理防范、實有人口、地址管理、社區警務、外網采集平臺、警綜門戶、實戰應用、綜合查詢、統計報表、條線整合、監督考核、系統管理、運維管理、數據監測、警綜與情報對接。
3.3 系統性能指標
1、建成了連接所有分縣局和業務部門(公安三級網)的千兆計算機交換網絡,建成聯接所有基層科所隊的寬帶接入網(傳輸速率 至少2兆以上);
2、實現各類警務信息數據庫的集中存放。
3、對于某一資源庫的精確條件查詢,要求響應時間在3秒內;對于單類信息模糊條件查詢,在1000萬數據記錄條件下,要求響應時間在2分鐘內;
4、多種自動提示功能;
5、導航查詢的響應時間在3秒內;
6、系統運行穩定可靠,年故障率在99.9%以下;
3.4 標準與規范
1、應遵循的國際安全模式和規范
2、應遵循的公安部頒布的標準規范
第四項目實施計劃及實施要求
4.1第一階段、初期項目計劃
主要工作有:
1.安排相關會議:
會見合作方:有關設備廠商及合作伙伴
2.建立項目管理規范,安全規范,作業規范:
包括項目任務分派、項目執行授權、項目任務細化、項目變更規范、文檔規范等。
3.實施隊伍的建設:根據項目的技術特色和技術要求,組織合格的項目實施隊伍。
4.確定合作方公司現場地點及其他設施
安排現場項目介紹給公司各個項目職能部門、小組和其他合作伙伴。
4.2第二階段:項目建立
主要工作有以下部分組成:
.建立項目實施團隊并配備相關設施
.建立用戶現場工作行政管理制度
.建立現場定期會議和操作細則
.建立工作與項目實施流程
.建立問題的解決流程
.建立變更的處理流程
4.3第三階段:系統設計
第二階段和第三階段是同步運行的,具體有以下部分組成:
.項目最終需求確認
.合作方和用戶就項目需求、實施方法和實施目標進行討論并雙方確認
.依據上述文件完善系統設計
.生成設計方案與報告
.生成實施計劃及有關圖表和文件
此后,需要做的工作是設計方案與各種制度的評審,主要是將相關方案和制度與用戶共同定稿。
4.4第四階段:現場準備
現場準備主要由雙方根據合同完成,包括:
.機房相關環境的測試確認
.系統測試相關調試工具與測試工具
4.5第五階段:系統安裝
.備份軟件升級操作
.設備配置和聯機測試
.生產系統的備份測試
4.6第六階段:系統測試與調試
.最終測試與調試
.根據項目需求書實施系統測試
.提交測試報告
.用戶最終驗收
第七階段:調整與維護階段
項目安裝調試后應試運行一段時間,在試運行過程中如有問題根據相關需求進行必要調整,同時,建立完善的維護體系。
第五投標單位資質要求
(1)投標單位須為在中華人民共和國境內注冊的獨立法人單位,工商注冊資金不低于人民幣200萬元(含);
(2)參加本次政府采購活動前三年內,在經營活動中沒有重大違法違規記錄;
(3)具有良好的商業信譽和健全的財務會計制度 ;
(4)具有履行合同所必須的設備和專業技術能力;
(5)投標方必須具有《計算機系統集成》三級或以上資質證書。
(6)工程驗收后提供三年免費維護,項目設備提供五年免費保修。
(7)投標方須提供對招標方業務使用人員和技術人員進行技術培訓,確保參訓的使用人員完全掌握培訓內容,技術人員能夠完全獨立維護整個軟件系統。所提供的培訓課程表隨投標文件一起提交。
第六項目驗收方式與內容
委托省軟件評測中心對開發的“公安機關警綜平臺”軟件進行驗收測試,依據項目開發合同,參考相關的國家標準和公安部標準,分別從軟件文檔、功能性、可靠性、易用性、效率、維護性、安全性、兼容性、數據庫設計等九個方面對該項目進行符合性測試和綜合的評價。
第七資金預算和付款方式
7.1資金預算:50萬元
7.2付款方式
合同簽定后7個工作日內支付合同總金額的60%,項目驗收結束后支付合同總金額的30%,項目驗收結束后試運行3個月內支付合同總金額的10%。
第二篇:警綜平臺運用交流材料
警綜平臺應用交流材料
各位領導、同志們:
今天在這里跟大家一起交流警綜平臺的應用,但主要是向大家學習,把大家好的經驗和心得帶回去,今年是公安機關四項建設年,信息化建設是重中之中,各級領導高度重視,信息化應用尤為重要,去年最初接觸警綜平臺,發現平臺涵蓋的內容相當廣泛,有點是我接觸過的業務,有些是我們農村派出所根本就沒有的業務,幾乎包容了整個公安工作,功能越來越完備,警綜平臺的設計具有很強的科學性、實用性,已經發揮了實戰效益,并且正越來越顯示出其對公安工作的重要性。從我個人來講,因為參加公安工作以前,有一定的計算機知識基礎,應用起來比起別的同志適應的快一些,就我應用警綜的心得,和大家交流一下:
最開始,警綜平臺啟用之時,我對平臺也很怕,怕搞不好,認為工作已很辛苦,搞平臺多此一舉、浪費時間。應用了一段時間后,發現其實警務平臺操作并不難。簡單的道理,一個東西研究出來,如果要在多數人中推廣使用,它應該具有很強的實用性、可操作性,也絕對是體現以人為本這條原則的。不象搞研究,必須是具有高深專業知識的尖端人才才能去搞。平臺設計的所有功能模塊,都與我們平時的實際工作緊緊相連。比如:案件查詢,實際辦案中查詢未破案件、以前處理人員資料,需要翻本子、打電話等,現在只需輸入幾個查詢條件,鼠標輕輕一點即可,后者無疑具有前者無可比擬的優越性,享受到了它的方便實用后,就能很快的運用到實戰中了。
執法規范化建設與信息化建設是“四項建設”的兩大主要內容,我結合實戰辦案的實際,向所長建議,將二者結合起來,以規范警綜平臺操作為抓手促進全所的執法規范化建設。在警綜平臺的應用中,處處規范操作,來規范辦案民警的執法行為,因為人是感情動物,可以講人情,可電腦程序不講人情,不規范執法行為,就不能規范操作警綜平臺,不規范操作,信息就錄上去,以辦理刑事案件為例,實際辦案中接受案件、對嫌疑人強制措施呈請報告等等,平臺上均有。整個刑事辦案的流程平臺均能反映,并且平臺上表格填完后,辦案所需的法律文書均能打印出來,即方便實用,又能規范執法。
警綜平臺運行時間不短,在今后的工作中,我要更加認真進行學習并勤于操練,處處用平臺規范工作,結果絕對是警務平臺促進工作,并越來越顯示出其應有的生機和活力。
謝謝大家!
第三篇:電子商務系統(java)需求分析說明書
電子商務系統需求分析說明書
一. 引言...............................................................................................................................................1 1.編寫目的............................................................................................................................................1 2.背景..................................................................................................................................................1 3.定義..................................................................................................................................................1 二. 任務概述.......................................................................................................................................2 1.目標.................................................................................................................................................2 2.用戶的特點......................................................................................................................................2 3.系統功能示例..................................................................................................................................2 三. 需求細則.......................................................................................................................................2 1.對功能的規定...............................................................................................................................2 2.對性能的規定...............................................................................................................................5 3.對排版的規定...............................................................................................................................5 4.對可維護性的規定........................................................................................................................5 5.對個性的規定...............................................................................................................................6 6.對項目過程的規定........................................................................................................................6
一. 引言
1.編寫目的
通過與多位軟件使用者進行全面深入地探討和分析,并完成《電子商務系統》市場的前期調查后,提出了這份軟件需求分析說明書。
此需求分析說明書對《電子商務系統》軟件做了全面細致的用戶需求分析,明確所要開發的系統應具有的功能、性能與界面,使系統分析人員及軟件開發人員能清楚地了解用戶的需求,并在此基礎上進一步提出概要設計說明書和完成后續設計與開發工作。
本說明書的預期讀者為客戶、業務或需求分析人員、測試人員、用戶文檔編寫者、項目管理人員。
2.背景 3.定義
二. 任務概述 1.目標 2.用戶的特點 3.系統功能示例
需求:
1、購物車管理
購物車內商品的增、刪、改 生成訂單
2、訂單管理
訂單的增、刪、查
3、使用數據庫(mysql)保存用戶信息、商品信息、訂單信息 用戶表,商品表,訂單表,訂單項表
技術要求:
1、商品類
2、購物車類
3、購物項類
4、訂單類
5、訂單項類
6、用戶類
7、應用MVC模式
購物流程:
用戶登錄,瀏覽商品頁面,挑選商品加入購物車,繼續瀏覽商品頁面…… 購物車頁面顯示當前所購商品信息(名稱、數量、價格),提交生成訂單,保存到數據庫中(訂單表存儲訂單基本信息:訂單號、用戶名、訂單總價、生成時間
訂單項表存放各訂單詳細訂單項信息:所屬訂單號、商品號、數量)
三. 需求細則 1.對功能的規定
分必選項和任選項,其中,必選項是必須完成的,屬于項目答辯的入口條件,所有人都要做,未完成者取消答辯資格;任選項不是入口條件,但每完成一項都會加分,對于完成了必選項的同學,盡可能地多完成一些任選項,以期獲得更高的答辯成績。如果所有項(包括必選和任選)都完成,那么功能分就是滿分。如果設計思路、界面效果、代碼組織等方面有個性(或和別人的不同),則獲得附加分。
1.1 注冊、登錄功能
屬性:必選
描述:用戶必須注冊,登錄之后才能使用本電子商務系統
1.2 商品瀏覽功能
1.2.1 商品類定義 屬性:必選
描述:商品信息必須包含如下項(包括但不限于):
● ID:要求全局唯一
● 商品名稱(字符串)● 商品單價 ● 商品庫存 ● 商品類別
1.2.2 用戶類定義 屬性:必選
描述:用戶信息必須包含如下項:
● 用戶ID:要求全局唯一 ● 用戶密碼 ● 用戶名
● 用戶送貨地址 ● 用戶郵箱 ● 用戶等級
1.2.3 瀏覽商品 屬性:必選
描述:用戶登陸以后能夠按類別瀏覽商品信息。
1.2.4 數據庫保存商品和用戶信息 屬性:必選
描述:商品信息(用戶信息)能夠存于數據庫中,掉電后信息不丟失。必須完成下面兩種情況:
在數據庫中,以表的形式存放商品和用戶信息。
1.3 購物車功能 1.3.1 購物車類 屬性:必選
描述:購物車類必須包含如下項(包括但不限于):
● 購物項集合(購物項類類型)
● 購物總額
1.3.2 購物車功能實現 屬性:必選 描述:增刪改查。
● 添加購買商品 ● 修改購買商品數量 ● 刪除購物項 ● 顯示購物車內容
● 計算購物車內商品總價(考慮用戶等級折扣)
1.3.3 購物項類 屬性:必選
描述:購物項類必須包含如下項(包括但不限于):
● 商品ID
● 購買數量
1.3.4 通過購物車下訂單 屬性:必選
描述:根據購物車內購物項集合下訂單,生成訂單內容信息必須保存在數據庫中
1.4 訂單處理功能 1.4.1 訂單類定義 屬性:必選
描述:訂單信息必須包含如下項(包括但不限于):
● ID:要求全局唯一
● 訂單明細集合(訂單明細項類型)● 訂單總額 ● 下單用戶ID ● 下單時間
● 訂單狀態(提交、審核、等待付款、發貨、完成)
1.4.2 訂單明細項類定義 屬性:必選
描述:訂單明細信息必須包含如下項(包括但不限于):
● 商品ID
● 購買數量 ● 訂單ID
1.5 數據庫功能 屬性:必選
1.5.1 用戶信息表 1.5.2 商品信息表 1.5.3 訂單信息表
1.5.4 訂單明細項信息表
1.6 商品評價
屬性:任選
描述:購買過某商品的用戶可以對該商品進行評價,評價內容保存在數據庫中,用戶瀏覽商品時可以查看評價信息
1.7 管理員后臺管理模塊
屬性:任選
描述:管理員登錄系統,查看商品庫存,查看用戶訂單,進貨處理,訂單狀態管理
2.對性能的規定
本系統在設計方面本著方便、實用的宗旨,性能方面應遵循如下原則: ● 執行效率(時間): 軟件運行應該盡量高效;避免沒有必要的循環處理、重復處理; ● 資源損耗(空間):設計盡量節約資源(內存、數組、鏈表等); ● 初始化: 局部變量、數組成員、內存塊等都要初始化; ● 健壯性:
◎ 申請內存之后,應該立即檢查引用值是否為null; ◎ 方法的入參必選進行有效性判斷;
◎ switch-case一定要有default;if-else if等后要有else; ◎ 數組的下標不要發生“多1”或者“少1”操作。
3.對排版的規定
● 縮進要對齊; ● 長行拆分;
● 二元操作符的前后應當加空格,包括如下操作符:
賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符,如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”, “^” 等;
● 空行:
◎ 類聲明之后、每個方法定義結束之后都要加2行空行;
◎ 邏輯上密切相關的語句之間不加空行,其它地方應加空行分隔; ◎ 一行代碼只做一件事情;
◎ “if”、“for”、“while”、“do”等語句自占一行,執行語句不得緊跟其后。不論執行語句有多少都要加 “{ }”;
4.對可維護性的規定
對可維護性的最終要求:別人能夠輕松上手你的代碼。
● 結構清晰:
◎ 模塊化:對界面(顯示)、菜單管理、邏輯管理、文件操作等等代碼要獨立; ◎ 封裝:一個模塊只做一件事,模塊功能要單一;一個方法不能超過50行;
避免重復、冗余代碼; ◎ 代碼塊清晰。
● 變量命名規范,變量名應該具有自明性:
◎ 常量定義命名
常量名由全大寫字母組成,單詞間通過下劃線來界定; ◎ 方法的命名:
使用“動詞”或者“動詞+名詞”(動賓詞組)的形式,由一個或多個單詞組成且以小寫字母開頭,以后每個單詞的首字母要大寫便于界定 ◎ 變量的命名與定義
應當使用“名詞”或者“形容詞+名詞”,由一個或多個單詞組成且以小寫字母開頭,以后每個單詞的首字母要大寫便于界定。
● 注釋充分:變量、方法(包括參數、返回值)、代碼功能塊、一些復雜算法??等都需要
清晰明了地說明;
5.對個性的規定
把項目做出個性出來。下列各項中有和比人不同之處、或很有創意,即可認為有個性。獨立設計的軟件,一般都會出現一些個性。參考、抄襲不會出現個性。
● 設計思路:包括軟件的整體架構、功能塊的設計思路、類封裝等等; ● 功能實現:從用戶的角度,使用上發現與眾不同的地方; ● 其它方面;
6.對項目過程的規定
本著緊張但不急躁、不參考、不拷貝的原則進行。? 緊張但不慌張
項目周期只有一周,這還包括項目答辯時間。所以項目時間比較緊張,但不能慌張。要有自己明確的設計思路,一步步沿著思路走下去,以此來鞏固自己所學,鍛煉自己的獨立工作能力。? 能自己做,絕不參考別人
自己還沒有做,還沒有想,就去看比人的,這樣盡管功能做出來了,但卻沒有什么意義,真正面試時還是不會。作者和讀者,天壤之別。
如果自己實在無法搞定,一個問題卡了快一天了,則可以咨詢別人一下想法,再行編碼;盡量不直接看別人代碼。? 不拷貝
一旦發現拷貝,取消答辯資格。答辯時發現,答辯成績減半。
copy別人的代碼,甚至直接運行別人的代碼,以此作為自己的項目進展,這是嚴禁的。嚴禁運行效果出來了,卻不知道是哪些代碼造成的,嚴禁明明是自己寫的代碼,但卻不知道為什么這么寫。
第四篇:教師工資管理系統需求分析說明書
學校內部工資管理系統
需求分析報告
系統分析員:張倩、施婷婷、毛思雨、吳園希、陳金淼
日期:2011-5-3
1、目導言
1.1 目的
為工資管理系統提供一套具有基本功能的模擬軟件支持系統提供基本的需求分析和描述,為軟件的開發參與者(系統設計人員、程序員、測試人員、開發商、管理人員等)提供完整的需求信息。
1.2 范圍
本軟件適用于我校工資系統的管理和應用,它是完善、安全、穩定的系統管理模擬軟件。待開發軟件系統的名稱:基于Web應用的學校教師工資管理系統
本產品能具體化、合理化、安全的模擬實現基于Web應用的工資管理系統的各種基本操作。
2、系統定義
2.1 項目來源及背景
本系統是一個學校內部工資管理系統。對教職員工的基本信息和工資信息進行添加和修改,能夠調整工資項目,根據需要對教職員工基本信息和工資信息的查詢,本系統能夠生成各個月的工資表,能夠打印報表方便保存和管理,還包括對系統的一些基本操作功能,比如為完善系統管理功能,增加工資系統用戶管理功能,系統應該包括系統用戶數據的添加,修改和刪除。教職員工為系統普通用戶,只能運行系統個人工資查詢功能;系統管理員則能運行系統所有功能,從而有效保證系統數據的安全性,系統應該具有簡單,易用,小巧,經典的特色,應該能夠對高校工資管理進行優化,使其系統化,高效化,智能化。并保證工資管理的準確性,簡易性,為學校財務人員提供便利。
2.2 用戶的特點
本系統的用戶主要有以下幾類:
教職工:提交各人信息和查詢總工資表;
財務處:查詢總工資表,生成正確的工作表,生成各教職工工資條; 人事處:提交人員變動情況,制定獎懲實施細則,生成可變工資; 學校各部門:提交出勤情況,提交業績情況,讀取工資條。
本軟件的使用對象是我校全體教職員工,必須通過IE瀏覽器訪問該系統,然后再登陸頁面輸入正確的用戶明和密碼方可使用(即成功登陸)。
3、功能規格
3.1 角色定義
角色或者執行者指與系統產生交互的外部用戶或者外部系統。
3.1.1 教職工
學校教職工通過系統可以實現以下使用需求:提交個人信息,登陸修改個人信息,查詢個人工資各項詳情。
3.1.2 財務處
學校財務處可以通過系統實現以下需求:讀取工資表,生成正確工資表及查詢工資情況。
3.1.3 人事處
學校人事處可以通過系統實現以下使用需求:輸入教職工調動信息,讀取教職工出勤及業績情況,制定獎懲實施細則,生成教職工出勤工資、獎金及扣款清單。
3.1.4 學校各部門
學校各部門可以通過系統實現以下使用需求:給出教職工出勤情況,給出教職工業績考核情況,讀取各部門匯總表,得到工資條。
3.1.5 數據庫數據庫是一個與系統產生交互的外部系統,這個角色負責系統的數據查詢、增加、刪除、和修改等操作。
3.1.6 學校人事處
在學校教師工資管理系統中,管理員可以提交人員變動,提交可變工資(統計出勤工資、獎金及扣款項目),制定獎懲明細,查詢工資表。具體描述如下。
用例描述:學校人事處管理; 執行者:學校人事處;
前置條件:人事處管理者已登錄系統;
后置條件上:如果人員和工資產生變化,則數據庫中的隨之變化。基本路徑:
登錄成功,進入管理界面。
然后根據選擇不同的操作分別進入不同狀態,如:選擇提交人員變動,可以對員工調入、調出、校內調動、離退休等數據進行修改,進入的狀態為一個系統
反饋的信息表。若選擇提交可變工資,則會再次給出選擇分別進入狀態為:出勤工資表,獎金表后者扣款清單表。
根據相應選擇查詢不同信息。查看信息完畢后,最后退出系統。
在學校教師工資管理系統中,財務處管理員可以查詢工資表,然后每月月底將教職工的工資表做好并將數據送往銀行。每月初(3日前)將工資條發給各單位。具體描述如下。
4、性能需求
4.1 界面需求
1.以通信功能作為界面設計的核心
人機界面設計的關鍵是使人與計算機之間能夠準確地交流信息。一方面,人向計算機輸入信息時應當盡量采取自然的方式;另一方面,計算機向人傳遞的信息必須準確,不致引起誤解或混亂。
2.界面必須始終一致
統一的人機界面不致于會增加用戶的負擔,讓用戶始終用同一種方式思考與操作。最忌諱的是每換一個屏幕用戶就要換一套操作命令與操作方法。
3.界面友好、使用方便
4.2 響應時間需求
系統能設置登錄等級,對于使用服務器端工作者可以先行響應;
4.3 開放性需求
一個優秀的軟件應該提供在線求助功能,甚至提供使用向導,這將給用戶帶來極大的方便。在多媒體環境下,以語音提示作為操作向導,不會干擾屏幕信息,是一個極佳的選擇。
4.4 可擴展安全性需求
系統對要提供與讀取信息的用戶進行身份驗證,登錄后各員工只能可以看到各自工資詳情;
第五篇:財務需求分析說明書
財務管理系統需求分析說明書(版本號:V1.0.2)
文檔信息:
項目名稱:財務管理系統項目經理:sGlobalMethod階段:需求分析
·1.引言
1.1 編寫目的
為使系統開發人員和業務需求人員達成對本次虛賬戶管理系統項目開發需求的一致理解,同時做為下一階段系統設計的依據,特編寫此《需求分析說明書》。
2收入管理需求描述
根據業務提出需求,需要增加學費管理,寢室費管理菜單,下面對功能進行詳細描述。
2.1收入管理
2.1.1功能概述
收入列表顯示,添加,刪除,修改
2.1.2界面描述
2.1.2.1寢室費
第一頁寢室費收入列表顯示(所有數據)按院校日期,地點,寢室號等分類查詢 顯示寢室費收入列表;
添加功能,單條/批量刪除,修改功能,導出功能。按添加按鈕跳入第二頁 第二頁寢室費錄入功能
含有表頭的可編輯的空表格,添加可編輯行數(1)刪除可編輯行數(1)保存;
2.1.2.2學費
第三頁學費收入列表顯示(所有數據)按院校日期等分類查詢 顯示學費收入列表;
添加功能,單條/批量刪除,修改功能,導出功能,導出當前所選擇的記錄。按添加按鈕跳入第四頁 第四頁學費錄入功能
含有表頭的可編輯的空表格,添加可編輯行數(1)刪除可編輯行數(1)保存;
3支出管理需求描述
3.1支出管理 3.1.1功能概述
支出列表顯示,添加,刪除,修改
3.1.2界面描述
3.1.2.1財務報銷
第一頁財務報銷支出列表顯示(所有數據)按院校,報銷類別,日期等分類查詢; 顯示財務報銷列表
添加功能,單條/批量刪除,修改功能,導出功能。按添加按鈕跳入第二頁 第二頁財務報銷錄入功能
含有表頭的可編輯的空表格,添加可編輯行數(1)刪除可編輯行數(1)保存;
3.1.2.2付款申請
第一頁付款申請支出列表顯示(所有數據)按院校,付款類型,日期等分類查詢; 顯示付款申請列表
添加功能,單條/批量刪除,修改功能,導出功能。按添加按鈕跳入第二頁 第二頁付款申請錄入功能
含有表頭的可編輯的空表格,添加可編輯行數(1)刪除可編輯行數(1)保存;
3.1.2.3采購申請
第一頁采購申請支出列表顯示(所有數據)按院校,采購類型,日期等分類查詢; 顯示采購申請列表
添加功能,單條/批量刪除,修改功能,導出功能。按添加按鈕跳入第二頁 第二頁采購申請錄入功能
含有表頭的可編輯的空表格,添加可編輯行數(1)刪除可編輯行數(1)保存;