第一篇：合同管理-需求分析文檔（模版）
合同管理需求分析 需求描述：
合同與招標管理主要實現對合同項目的立項審批、招標、合同以及竣工驗收的全過程管理。該系統主要由合同項目管理、招標管理、合同管理、客戶管理和灰名單管理等幾個模塊組成。
流程圖：
合同管理流程圖合同管理外包工程合同項目申請招標否自動創建項目合同項目審批招標書擬定標書簽收登記評標報告申請評標報告審批合同申請招標記錄填報談判紀要錄入資質與安全協議審查合同擬定付款申請合同記錄人員管理合同終止現場管理合同變更竣工/質保驗收申請竣工/質保驗收審批結束 3 項目管理
3.1 項目申請：
合同項目管理是指所有需要簽訂合同的項目都要在此進行申請。由各個部門的專工或主任提出申請。
合同項目申請又分為未運行、進行中和已完工。后兩者是屬于后補項目，后補項目必須增加先履行原因。
合同項目的屬性包括：項目編號、申請日期、后補類型（生產搶修、超過50萬已書面報分公司同意、后補或不招標超過10萬已書面報總經理同意）、項目狀況（未進行、進行中、已竣工）、申請方式（招標、不招標）、項目名稱、項目性質（新簽、續簽、變更、終止、補充）、資金來源、項目預算、費用管理部門、項目類型（技術服務、土建、維修、軟件等）計劃開工時間、計劃竣工時間、申請理由、申請人、申請部門、申請部門主管、不招標理由（有多條理由顯示，直接讓用戶勾選）、項目內容、工程量及物料人力資源情況。
合同項目申請時需要填寫承包商推薦會簽表，需要招標的項目至少選擇5家，不需要招標的項目至少選擇3家；如果選擇的承包商單位不足則需要在【備注】中填寫理由。合同申請的界面原型如下：
3.2 項目審批：
項目申請提交后，由各級進行審批，其中系統約定72小時，如果超過72小時，則系統自動推進，無需他在簽字審批。但是要在系統中列明原因：“該記錄已超過72小時，系統自動推進！”。如果是部門專工提出申請，則還需要部門主任審批，審批后由項目主管部門審批報公司分管領導審批，對于超過多少金額的還需要報總經理審批。對不同類型的項目，主管部門可能不一樣，例如生產項目的主管部門是設備部，非生產項目的主管部門是經營計劃部。項目審批的界面原型如下：
項目驗收
項目驗收分為: 竣工驗收單、質保驗收單和階段驗收單。
驗收單包括：驗收日期、驗收單類別（竣工、質保、階段）、項目名稱、資金來源、項目預算、履行地點、開工日期、竣工日期、質保金截至日期、甲方名稱、乙方名稱、項目摘要內容、評價等級、合格/不合格、客戶評價（符合合同要求、不符合合同要求、達到預期目標、未達到預期目標、可以投入使用、不可以投入使用、質保期質量無問題、質保期有問題）、填寫人、填寫時間、填寫部門、附件。
? 竣工驗收單申請：
由項目負責部門提出竣工驗收申請。
? 竣工驗收單審批：
竣工單申請后，經過各級審核通過后，就將該系統置為已竣工。當超過72小時候沒有審批就自動推進。
? 質保驗收單申請：
由項目負責部門提出竣工驗收申請。
? 質保驗收單審批：
質保單申請后，經過各級審核通過后，就將該系統置為已竣工。當超過72小時候沒有審批就自動推進。
? 階段驗收單登記：
由項目負責部門登記所有階段驗收的記錄。
如果項目是來自于外包工程，所有的驗收記錄和質保記錄同步保存到外包工程的記錄中。項目驗收的界面原型如下：
招標管理
對于需要招標的項目，應該進行招標。招標管理主要是做好三個方面的工作：分別是招標擬定，標書簽收登記以及項目評標報告。這三個節點只有在評標報告審批時必須要做的。
4.1 標書簽收登記：
標書簽收登記就是登記簽收標書的投標方單位。由項目負責單位登記所有投標方單位，并記錄投標單位名稱，投標時間，投標金額，聯系人及聯系電話。界面原型如下：
4.2 招標書擬定：
招標書擬定就是下載招標書模板后，根據模板要求填寫各項數據上傳到系統中。
4.3 工程評估報告申請：
由項目負責部門提出工程評估報告申請。
工程評標報告屬性：項目名稱、資金來源、項目預算、參與投標單位（序號、公司名稱、投標報價、資質）、評標意見、綜合排序（將投標單位排序）、擬中標單位、中標金額、參與人員、備注、申請人、申請時間、申請部門、各種附件。工程評估報告申請的界面原型如下：
4.4 工程評估報告審批
項目評估報告提出申請要經過審批，經過審批后才發布。由各級領導進行審批，各個上傳的附件應直接在屏幕上顯示出來。對于超過72小時未審批的要自動推進。
工程評估報告審批的界面原型如下：
合同管理
合同管理包括：合同申請審批、合同擬定、合同談判紀要、其他付款、付款申請審批、合同變更、合同終止等管理。
5.1 合同申請：
合同申請審批是由合同起草人或項目負責部門提出申請。合同申請的屬性有：合同名稱，合同編號，合同性質，合同類型，資金來源，合同金額，項目預算，所屬項目，簽約單位（我方）（承包部門，部門負責人，承辦人），簽約單位（對方）（承辦人，承辦人聯系電話）,簽約時間，簽約地點，備注，附件，申請部門，申請人，申請時間。
合同申請的界面原型如下：
5.2 合同審核：
合同申請由項目負責部門提出后，經過部門主任審批、主管部門領導審批、公司領導審批后通過（具體流程可以靈活設置）后生效。合同審核的界面原型如下：
合同擬定
通過下載【合同模板】后，填寫合同內容上傳擬定好的合同文本到系統中。合同擬定的界面原型如下：
5.4 合同談判紀要
合同的談判紀要是在系統中錄入合同談判的紀要內容。合同談判紀要的界面原型如下：
5.5 付款申請
由項目提出部門提出付款通知單，并經過相關部門和公司領導審批。一個項目可以多次付款。超過總金額后就不能再付款了。系統應該要有剩余質保金的到期提示。付款申請的界面原型如下：
5.6 付款審核
合同付款審核的界面原型如下：
5.7 其他付款
其他付款是申請付款通知單的一種，是多那些沒有按正規流程辦理的項目的付款。其他付款的界面原型如下：
5.8 合同變更
由項目負責人根據合同的實際情況可以對合同進行變更，需要填寫變更原因，記錄好變更的時間。合同變更的界面原型如下：
合同終止申請
當合同有效時間到達時，合同自動終止，或者因為其他原因可以由項目負責部門提前終止合同。合同終止申請的界面原型如下：
5.10 合同終止審核
項目負責部門提出合同終止申請后，需要通過各級部門審核通過后才能終止合同。合同終止的審核的流程需要通過工作流來進行配置。
合同終止審核的界面原型如下：
客戶管理
合同管理中的承包單位統一在【承包商】模塊中進行管理，創建合同項目時自動將對應的承包商信息保存到【承包商】模塊中。
第二篇：合同管理系統需求分析（定稿）
1.1.1 合同管理
1.1.1.1 管理思想及綜述
可實現多種合同類型的管理，可實現對合同在集團內部的多級審批。并可實現對項目類合同進行合同錄入、合同變更、合同結算管理。并可實現對合同附件的管理。可實現項目月度資金計劃的錄入，并可實現與進度相結合的項目款的支付管理，最后實現付款記錄自動生成憑證到總賬系統。
1.1.1.2 管理流程
1.1.1.3 系統功能 1.1.1.3.1 合同訂立
合同錄入
操作組織：實體成本中心組織或者非實體成本中心組織
可以修改和刪除“保存”或者“提交”狀態下的合同；單擊【【】，就可以上傳“合同文本”和“工程附件”；單擊【
】和】，就可以對審批后的合同進行“責任部門”移交；單擊【同所有相關的信息。
合同錄入完畢后，點【
】，就可以查看該合】，然后在序時簿界面進行審批，合同審批支持工作流。
合同修訂
操作組織：實體成本中心組織或者非實體成本中心組織
進入“合同修訂”主界面，選中需要修訂的已審批合同，單擊工具條上【就可以修改和刪除“保存”或者“提交”狀態下的合同修訂；
】和【
】，合同查詢
本功能用來自定義條件查詢合同，雙擊查詢出來的合同，可以看到該合同相關的執行信息，包括合同信息、拆分信息、結算信息、變更信息、成本信息、付款信息、付款計劃等信息。
操作組織：實體成本中心組織或者非實體成本中心組織 用戶可以根據需要選擇界面上的選項進行查詢。合同執行
“合同執行”包括六個方面的內容：合同變更發起、變更審批單查詢、變更簽證確認、變更指令單查詢、結算單錄入、結算單查詢。
合同變更發起
操作組織：實體成本中心組織或者非實體成本中心組織
進入“合同變更發起”主界面，選中最明細工程項目，單擊工具條上的【】進入“變更審批單-新增”界面；單擊工具條上【或者“提交”狀態下的變更審批單；
變更審批單錄入完畢后，點【進行審批，該審批支持工作流。
】和【】，就可以修改和刪除“保存”
】，單據狀態變為“已提交”，然后在序時簿界面
1.1.1.3.2 變更簽證確認
操作組織：實體成本中心組織或者非實體成本中心組織
該功能是用來登記變更指令單的“下發”、“簽證”以及“變更結算”等信息。如下圖：
填寫完畢之后，點“確定”，則該變更指令單的狀態變為“已簽證”。點【可以進行簽證的反向操作。
系統支持批量簽證的功能，點【
】
】，則自動將選擇的項目分期下的所有“已下發”狀態下的變更指令單列示出來，供用戶逐一簽證確認。如下圖所示：
選擇“已簽證”狀態的變更指令單，點【結算金額。如下圖所示：
】，就可以錄入變更指令單的1.1.1.3.3 結算單錄入
操作組織：實體成本中心組織或者非實體成本中心組織
進入“結算單錄入”主界面，選擇需要錄入結算的合同，單擊工具條上的【入“結算單-新增”界面；單擊工具條上【或者“提交”狀態下的結算單；
】和【
】進
】，就可以修改和刪除“保存”
1.1.1.3.4 無文本合同
“無文本合同”包括兩個內容：無文本合同錄入、無文本合同查詢。無文本合同錄入
操作組織：實體成本中心組織或者非實體成本中心組織 “無文本合同-新增”編輯界面如下，黃色部分為必錄字段。
1.1.1.3.5 扣款及獎勵
“獎勵及扣款”包括六個方面的內容：違約金錄入、獎勵單錄入、扣款單錄入及三種單據的查詢。
1.1.1.3.6 違約金錄入
操作組織：實體成本中心組織或者非實體成本中心組織
1.1.1.3.7 獎勵單錄入
操作組織：實體成本中心組織或者非實體成本中心組織 “獎勵單-新增”編輯界面如下，黃色部分為必錄字段。
1.1.1.3.8 扣款單錄入
操作組織：實體成本中心組織或者非實體成本中心組織
“扣款單-新增”編輯界面如下，黃色部分為必錄字段。
1.1.1.3.9 違約/獎勵/扣款查詢
操作組織：實體成本中心組織或者非實體成本中心組織
用戶可以根據需要選擇菜單，實現對違約、獎勵、扣款的分別查詢。點開相應菜單后，用戶可以按照界面上的選項進行查詢。
用戶也可以通過設置“自定義”頁簽里條件進行組合查詢。
1.1.1.3.10 付款計劃
合同付款計劃
“付款計劃”包括七個內容：合同付款計劃、月度付款計劃、項目計劃執行表、項目月度計劃申請表、項目計劃申報表、付款計劃查詢、付款計劃執行表。
操作組織：實體成本中心組織。
該模塊的功能為：按照“單一合同”為緯度，編輯每個合同的付款計劃。進入“合同付款計劃”主界面，選中相應的合同，單擊工具條上的【
】進入“合同付款計劃”編輯界面；
月度付款計劃
操作組織：實體成本中心組織或者非實體成本中心。
該模塊的功能為：按照“合同”為緯度，查詢每個責任部門的付款計劃（默認為三個月）。
計劃申報
該模塊的功能為：按照“成本科目-合同”為緯度，編輯工程項目的（12個月）付款計劃。
月度計劃申報
該模塊的功能為：按照“成本科目-合同”為緯度，編輯工程項目的月度（3個月）付款計劃。
如下圖所示:
該表錄入完畢后，點【
】，然后在序時簿界面進行審批，該審批支持工作流多級審批。當該表審批之后，自動將3個月內的付款計劃反寫到對應的“合同付款計劃”。
付款計劃查詢
該模塊的功能為：通過條件設置來查詢合同付款計劃，每一行顯示一個合同的一個月計劃。數據來源于“合同付款計劃”。
付款計劃執行表
該模塊的功能為：以合同為緯度，匯總展現工程項目下合同的月度付款計劃執行情況。示例如下：
項目計劃執行表
該模塊的功能為：以成本科目為緯度，將“項目計劃申報表”、“項目月度計劃申請表”以及月度實際付款等信息結合起來應用，通過層層累計的方式綜合展現“項目周期”、“本”和“本月份”三個不同的時間縱深的付款計劃的執行情況。因此，本表的數據來源為：“項目計劃申報表”、“項目月度計劃申請表”以及月度實際付款等信息。如下圖所示：
在項目執行情況表中，展開“項目成本執行情況”，顯示的是項目累計發生的成本、付款、欠款以及待發生情況。如下圖：
在項目執行情況表中，展開“預算執行情況”，顯示的是本成本、付款預算的執行情況，如下圖：
在項目執行情況表中，展開“本月計劃執行情況”，顯示的是查詢當月的成本/付款計劃、成本/付款實際發生、以及計劃與實際的差額情況，如下圖：
1.1.1.3.11 付款管理
“付款管理”包括四個內容：付款申請單錄入、付款申請單查詢、付款單錄入、付款單查詢。
付款申請單錄入
付款單錄入
1.1.1.4 系統應用價值和特點
本系統應用價值和特點有如下幾點： 1.涵蓋合同管理全周期和合同管理全要素（合同訂立過程、合同內容、合同主體（締約方）、合同標的、合同變更與索賠、合同結算與支付、履約風險、履約聯系、合同終結與總結等）；
2.3.4.5.6.7.8.9.支持各類合同的業務流程靈活匹配；
能夠根據投資預算和項目管控要求，進行合約規劃； 按照權責體系和績效考核要求，實行合同的分級分類管理； 承接招評標數據，全面登記合同事務；
提供完整的合同錄入、變更、結算、付款管理流程；
根據合同付款計劃，嚴格控制合同付款申請，保障項目現金流； 實現項目資金計劃申報和資金全面預算管理； 有效實現變更管理，掌控項目過程成本發生；
10.實現合同文檔管理、分次結算管理；
11.通過數據一體化功能，全面掌握合同執行情況； 12.通過流程管控實現企業內部控制以及工作流驅動。
第三篇：合同管理系統需求文檔
合同管理系統需求文檔
一、開發前提：
合同系統的開發在原資金系統的基礎上，人員組織結構、系統角色設置與資金系統基本一致或做少量修改。
合同系統審批方式采用類似于資金系統的網上審批。系統可以滿足各種復雜的審批流轉規則，尤其是滿足集團公司多個子公司多種不同審批流程（同一模塊每一個子公司一個流程）的需求。
合同系統中的合同隸屬于資金系統中的項目，合同審批簽訂后占用項目的預算。通俗的講，項目的預算是通過項目所對應的合同執行的，合同的簽訂、金額變更受到項目預算的制約。
二、詳細需求：
1.供應商管理：
系統需求：
? 對供應商的基本信息進行管理，通過一個頁面直觀的展示合同對方的信息。? 可以方便的增加、修改、模糊搜索供應商的信息。
? 系統提供上傳供應商的資質信息等附件功能。
? 提供EXCEL導入導出供應商信息功能。
報表需求：
? 可以按照各種條件查詢供應商的相關信息。
? 可以鏈接到供應商相關項目、相關合同和已經簽署資金統計等內容。
2.合同管理（基礎數據）：
系統需求：
? 可對多種合同類型進行管理。如：設備合同、建安合同、服務合同、租賃合同等。? 合同一定是和資金系統中的項目關聯的。
? 合同分為開口合同和閉口合同。
? 合同金額分為合同金額（標的金額）、預算金額（計劃金額）、實際結算金額三種。? 合同保證金（尾款）。合同保證金的金額由錄入合同的人計算填寫，保證金交付
日期由合同錄入人計算錄入。
? 系統提供附件的上傳和下載。
? 各式的合同系統提供填寫模板、默認一些合同信息、校驗一些合同信息輸入的合法性。
? 系統提供合同樣本的打印功能。并提供合同樣本的導出為EXCEL功能。報表需求：
? 根據檢索條件快速、準確找到合同資料，支持關鍵字模糊搜索、分組顯示等。? 提供合同按照類型、按照單位、按照項目的一些統計圖表。
3.合同建立與審批管理（略）。
系統需求：
? 合同簽訂/變更是需要審批流程的，可根據合同類型、合同金額等條件自動匹配
合同審批流程。實現并簽、串簽、按條件跳轉等功能。
? 合同的審批具有短信通知功能。
? 系統提供合同存檔功能。
4.合同的變更管理。
系統需求：
? 系統提供合同基礎信息變更的流程。可變更合同金額等基礎信息。
報表需求：
? 提供合同具體的變更記錄。
5.合同系統與資金系統的深度關聯，預算管理。
系統需求：
? 任何合同都隸屬于資金系統中的一個項目。
? 合同的建立、變更（金額）都受到項目預算的控制。在新增合同時如果合同所
屬項目的資金不足則不允許新建合同。在最后的領導審批后，再次進行項目資
金進行是否滿足合同資金的驗證。驗證復核后合同正式建立。合同變更中，如果合同金額增加同樣需要驗證其金額是否超出項目總金額。
? 合同的執行。合同的執行是在資金系統中填寫合同報銷單。以合同資金的支出
進度判斷合同的執行進度。
? 合同保證金只有在合同保證金交付日期到達之后進行交付（報銷）。報表需求：
? 項目報表中，分為項目預算、已簽署合同金額、已執行合同金額、項目可簽署
余額、項目實際剩余金額等字段。
? 項目報表中可以鏈接到支出類型表。
? 項目報表中可以鏈接到合同信息表。
? 項目報表提供按照供應商的統計報表及圖表。
? 項目報表中提供按照時間的資金支出統計及報表。
? 預警提醒。報表提供合同進度逾期和資金逾期等提示。
6.系統設置。
? 填單權限設置。
? 報表查看權限設置。
? 組織結構、角色、等同資金管理系統。
中科普達軟件公司
第四篇：圖書管理系統需求分析
云南工商學院09信息管理1班
圖書管理系統需求分析
班級：09信息管理1班
組員： 唐學悅，段敏，楊文燕，胡勇毅，余科輯，林春宇，李波
任務分配情況：
云南工商學院09信息管理1班
目錄 系統需求概述...............................................................................................................................3 1.1 圖書管理系統功能概述....................................................................................................3 1.2 系統主要業務流程分析....................................................................................................3 1.3 系統功能模塊分析............................................................................................................3 1.4 建立用例模型....................................................................................................................4 1.4.1 讀者用例圖.............................................................................................................4 1.4.2 圖書管理員用例圖.................................................................................................4 1.4.3 系統管理員用例圖.................................................................................................5 1.5 詳述用例............................................................................................................................5 2 系統分析.......................................................................................................................................6 2.1 類圖....................................................................................................................................6 3 系統設計.......................................................................................................................................8 3.1 用例動態模型設計............................................................................................................8 3.1.1 實現“讀者查詢個人借閱信息”用例的動態模型.................................................8 3.1.2 實現“查詢圖書信息”用例的動態模型.................................................................9 3.1.3 實現“借閱圖書”用例的動態模型.........................................................................9 3.2 類圖設計..........................................................................................................................11 3.3 物理架構設計..................................................................................................................12 3.3.1 組件圖...................................................................................................................12 3.3.2 配置圖...................................................................................................................13 2
云南工商學院09信息管理1班
1.系統需求概述
1.1 圖書管理系統功能概述
圖書管理主要是借書、還書以及其他一些附帶操作（例如，超期罰款、催還圖書等）的處理。一個簡單的圖書管理系統應提供如下功能：
·借書處理：完成讀者借書的流程處理。·還書處理：完成讀者還書的流程處理。
·信息查詢：包括圖書信息查詢和讀者借閱情況查詢。·圖書管理：包括輸入新書記錄和刪除舊書記錄。
1.2 系統主要業務流程分析
與系統功能相對應，系統主要有4個流程：結束流程、還書流程、圖書查詢、圖書資源管理。各流程的主要過程描述如下：
·借書流程：讀者借閱所需的圖書，借出后圖書記錄中的借閱標志被置為false(不能再借)，借書文件中增加一個借書記錄。
·還書流程：讀者歸還所借的圖書，還書后圖書記錄中的借閱標志被置為true(可被外借)，在借書文件中刪除一個借書記錄。
·圖書查詢：讀者和工作人員可以進行圖書信息查詢，輸入圖書的編號或書名，可從圖書對象列表中查找相應的記錄。
·圖書管理：首先由工作人員在“錄入新書資料”和“刪除舊書資料”兩個選項中選擇。若是“錄入新書資料”，則由工作人員輸入新書資料，將新書添加為對象列表的新紀錄。若是“刪除舊書資料”，則查找需要刪除的圖書，將其從圖書對象列表中刪除。
1.3 系統功能模塊分析
滿足上述需求的系統主要包括以下幾個系統模塊：
·基本業務處理模塊：主要用于實現圖書管理員對讀者借閱圖書和歸還圖書的處理。
·信息查詢模塊：重要用于實現讀者對圖書信息和自身借閱信息的查詢。
云南工商學院09信息管理1班
·系統維護模塊：主要用于實現系統管理員對讀者信息、圖書管理員信息、圖書信息、和數據庫的管理。
1.4 建立用例模型
根據功能需求構造用例模型，主要任務是識別系統中的所有參與者，并對每個參與者找出其用例，建立用例模型。
系統主要的參與者為“讀者”、“圖書管理員”、和“系統管理員”。各個參與者的用例圖如下：
1.4.1 讀者用例圖
<
圖1-1 讀者用例圖
1.4.2 圖書管理員用例圖
<
圖1-2 圖書管理員用例圖
云南工商學院09信息管理1班
1.4.3 系統管理員用例圖
添加書目添加讀者刪除書目刪除讀者系統管理員查詢圖書查詢讀者
圖1-3 系統管理員用例圖
1.5 詳述用例
在識別了參與者和主要用例并創建了用例圖之后，如果有必要，還可以按順序詳述每個用例，包括用例如何開始、結束以及如何與參與者進行交互。
表1-1 讀者查找個人借閱信息用例
用例：讀者查找個人借閱信息(用例名稱)(唯一標識符)(涉及用例的參與者)(用例開始時，系統必須滿足的條件)ID：1參與者：
1、讀者前提條件： 讀者已登錄到系統事件流：
1、讀者選擇查找個人借閱信息界面
2、讀者輸入圖書證編號
3、系統按圖書證編號查找讀者借閱信息結果：系統向讀者顯示讀者借閱信息，該用例結束(用例中的實際步驟)(用例結束時，系統的狀態)
云南工商學院09信息管理1班
表1-2 讀者查找圖書信息用例
用例：讀者查找圖書信息(用例名稱)(唯一標識符)(涉及用例的參與者)ID：2參與者：
1、讀者(用例開始時，系統必須滿足的條件)前提條件： 讀者已經啟動圖書管理系統，并已知書名或書號事件流：
1、讀者選擇查找圖書信息界面
2、讀者輸入書名或書號
3、系統按書名或書號查找圖書信息結果：系統向讀者顯示圖書信息，該用例結束(用例中的實際步驟)(用例結束時，系統的狀態)系統分析
2.1 類圖
在定義系統需求后，下一步就是確定系統中存在的對象類。系統中對象類的識別可以使用名詞/動詞分析法來進行，即文本中的名詞和名詞短語暗示類或類的屬性，動詞和動詞短語暗示職責或者類的操作。
通過用例圖的分析可知，在圖書管理系統中可以確定的主要對象類包括 “讀者”，“圖書”、“圖書管理人員”和“系統管理員”。其中“讀者”和“圖書”通過借閱關系可以構成一個新類“借閱記錄”。
另外，分析用例圖可知，用例“身份驗證”和“圖書資料查詢”是對象類“讀者”和“工作人員”共同擁有的，并且用例“身份驗證”是除用例“圖書資料查詢”之外其余用例執行的前提，因此可以將“身份驗證”與“圖書資料查詢”定義為接口類中的操作(接口類是不含屬性且操作函數沒有具體實現的抽象類，接口類通過一個實現聯系獲得其它對象類的支持，這些對象類實現接口類中定義的全部操作)。其余用例則抽象為與該用例交互的參與者所屬對象類的操作。因此，最后可獲得的對象類圖為：
云南工商學院09信息管理1班
系統管理員-name-password1*讀者-name-number-password+借書()+還書()+借閱情況查詢()***<
圖1-4 系統對象類圖
除了定義上述用于系統數據信息存儲管理和業務邏輯控制的類之外，在用圖形用戶界面開發系統時，我們還可以定義一些相應的用戶界面類：
(1)MainWindow類—MainWindow是圖書管理員與系統交互的主界面，系統的主 界面具有菜單，當用戶選擇不同的菜單項時，MainWindow對象調用相應的方法完成功能操作。
(2)BorrowDialog類—BorrowDialog是進行借書操作時需要的對話框。(3)ReturnDialog類—ReturnDialog是進行還書操作時需要的對話框。(4)QueryDialog類—QueryDialog是查詢某借閱者的借閱信息或圖書庫存信息的對話框。
(5)MaintenanceWindow類—MaintenanceWindow是系統管理員對系統進行維護的主界面，它也提供菜單項。
ReturnDialogBorrowDialogMainWindowQueryDialogMaintenanceDialog 圖1-5圖書管理系統的用戶界面類
云南工商學院09信息管理1班 系統設計
系統設計的主要工作是用例實現—設計。即對每個用例進行動態建模，包括建立序列圖、協作圖等，描述如何通過類對象的協作來實現用例中的功能。隨著動態建模的深入，會發現原來建立的類存在缺陷或不夠完整，需要對分析中得到的類圖進行不斷的修正和調整。所以，還應該通過動態建模來修正和完善類圖。
3.1 用例動態模型設計
3.1.1 實現“讀者查詢個人借閱信息”用例的動態模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:getBook5:消息查詢6：返回借閱信息7：顯示借閱信息
圖1-6 讀者查詢個人借閱信息序列圖
1:queryLoan():MainWindowerBorrower6:顯示借yLoanInfo()閱信息5:返回借閱信息:Borrower-Book4:getBook():QueryDialog2:createDialog()3:qu
圖1-7 讀者查詢個人借閱信息協作圖
云南工商學院09信息管理1班
3.1.2 實現“查詢圖書信息”用例的動態模型
:MainWindow:QueryDialog:BorrowBookBorrower1:queryLoan2:createDialog3：queryLoanInfo4:findBook5:圖書信息查詢6：返回圖書信息7：顯示圖書信息 圖1-8 讀者查詢圖書序列圖
1:queryLoan():MainWindowerBorrower6:顯示圖yLoanInfo()書信息5:返回圖書信息:Borrower-Book4:findBook():QueryDialog2:createDialog()3:qu
圖1-9 讀者查詢圖書協作圖
3.1.3 實現“借閱圖書”用例的動態模型
云南工商學院09信息管理1班
:MainWindow:BorrowDialog:QueryDialogBorrower1:queryLoan2:createDialog4:查詢圖書庫存5:返回圖書是否可借6:修改讀者的借閱信息及庫存信息7:修改成功8:顯示借書成功
圖1-10 讀者借閱圖書序列圖
2:createDialog()oan():MainWindow:BorrowDialogry1:queL息6:顯示借書成功存庫信書借存圖可庫詢否及查是息功:4書信成圖閱改修Borrower回借:7返者:讀5改修:6:QueryDialog
圖1-11 讀者借閱圖書協作圖
云南工商學院09信息管理1班
3.1.4 實現“歸還圖書”用例的動態模型
:MainWindow:ReturnDialog:QueryDialogBorrower1:queryLoan2:createDialog3:修改讀者的借閱信息及庫存信息4:修改成功5:顯示還書成功
圖1-12 讀者歸還圖書序列圖
1:queryLoan():MainWindowBorrower6:顯示還書成功4:修改成功:QueryDialog3:修改讀者的借閱信息及庫存信息:ReturnDialog2:createDialog()
圖1-13 讀者歸還圖書協作圖
3.2 類圖設計
進一步擴充和細化分析階段定義的類，包括定義新的類來處理用戶的需求。隨著動態建模的深入，也會發現原來建立的類存在缺陷或不夠完整，需要對分析中得到的類圖進行不斷的修正和調整。所以，還應該通過動態建模來修正和完善類圖。
云南工商學院09信息管理1班
系統管理員-name:string-password:string+AddBook()+QueryBook()+AddBorrower()+QueryBorrower()借書記錄-borrower:string-book:string-date:Date+newLoan()+getBorrower()+getBook()11*讀者-name:string-number:string-password:string+Borrow()+Return()+QueryLoan()***<
圖1-14 設計類圖
3.3 物理架構設計
物理架構設計就是用UML圖形描述系統軟件和硬件的大致結構，包括畫出組件圖和配置圖。
3.3.1 組件圖
組件圖：表示構成軟件系統的各物理組件及其相互之間的聯系。它能明確表示軟件系統各部分的功能職責。圖書管理系統的組件圖如下所示，其中包含“借/還書處理”、“信息查詢”、“圖書資源管理”和“身份驗證”等組件。
云南工商學院09信息管理1班
圖書管理系統借/還處理信息查詢圖書資源管理身份驗證圖書信息借閱信息
圖1-15 系統組件圖
3.3.2 配置圖
圖書管理系統是一個基于網絡和數據庫的應用系統,可以采用B/S結構,系統配置圖下圖所示：
數據庫服務器圖書信息借閱信息讀者客戶端借/還書處理工作人員客戶端公共客戶端身份驗證圖書資源管理借閱信息圖書資料查詢 圖1-16 系統配置圖
第五篇：圖書管理系統需求分析
圖書管理系統需求分析報告
1.引言 1.1 編寫目的
軟件需求分析，其目的是用于說明軟件產品或軟件項目需要滿足的條件和限制。在軟件工程項目中，首先要獲取用戶的需求，通過對軟件需要的提取、分析、文檔化和驗證，為進一步的設計和實現提供數據。軟件需求與其他活動也密切相關，如軟件測試、配置管理和質量管理等。
本需求的編寫是為了研究利用大型數據庫做基礎的圖書管理系統軟件的開發途徑和應用方法。同時它也是進行項目策劃、概要設計和詳細設計的基礎，是維護人員進行內部維護，信息更新，驗收和測試的依據。
1.2 項目背景
本項目的名稱：圖書管理系統。
圖書管理系統這任務提出與開發者為某學生的課程設計,用戶是學校圖書館。本產品是針對電腦管理圖書的需求設計的，可以完成圖書信息錄入、修改、刪除，讀者登記、購入新書、讀者借還書、圖書注銷等。
1.3 相關定義
數據流圖（Data Flow Diagram）：簡稱DFD，它從數據傳遞和加工角度，以圖形方式來表達系統的邏輯功能、數據在系統內部的邏輯流向和邏輯變換過程，是結構化系統分析方法的主要表達工具及用于表示軟件模型的一種圖示方法。數據字典：它是數據的信息的集合，即對數據流圖中包含的所有元素的定義的集 合。其作用是為設計人員提供關于數據描述的信息。數據字典應該由對以下四類元素的定義組成：數據流、數據流分量（即數據元素）、數據存儲、處理。
2.需求概述 2.1 目標
“圖書管理系統”主要提供圖書信息和讀者基本信息的維護以及借閱等功能。本系統是提高圖書管理工作的效率，減少相關人員的工作量，使學校的圖書管理工作真正做到科學、合理的規劃，系統、高效的實施。
2.2 用戶類和特征
最高用戶是圖書管理員和讀者，圖書管理員需要進行用戶的創建、修改和刪除等工作，要求具備計算機知識，如權限管理等。讀者是普通用戶，具備一定的計算機操作即可。
2.3 運行環境
服務器：CPU P4 1GHz以上;內存256M以上配置。由于服務器將存儲大量圖書資料，建議準備100G以上硬盤、并預留磁盤擴充接口。
客戶端：CPU C433MHz以上；硬盤：200M以上空白空間；內存：128M以上配置。
軟件運行環境：服務器：Windows 2000 Server、Windows 2000 Advanced Server、Windows 2003均可;Microsoft SQL Server 2000 或 2005。
3.需求分析 3.1數據需求
圖書館管理信息系統需要完成功能主要有：
1)讀者基本信息的輸入，包括借書證編號、讀者姓名、讀者性別等。2)讀者基本信息的查詢、修改，包括讀者借書證編號、讀者姓名、讀者性別等。3)書籍類別標準的制定、類別信息的輸入，包括類別編號、類別名稱。4)書籍類別信息的查詢、修改，包括類別編號、類別名稱。
5)書籍庫存信息的輸入，包括書籍編號、書籍名稱、書籍類別、作者姓名、出版社名稱、出版日期、登記日期。
6)書籍庫存信息的查詢，修改，包括書籍編號、書籍名稱、書籍類別、作者姓名、出版社名稱、出版日期登記日期等。
7)借書信息的輸入，包括讀者借書證編號、書籍編號、借書日期。
8)借書信息的查詢、修改，包括借書證編號、借書證編號、讀者姓名、書籍編號、書籍名稱、借書日期等。
9)還書信息的輸入，包括借書證編號、書籍編號、還書日期。
10)還書信息的查詢和修改，包括還書讀者借書證編號、讀者姓名、書籍編號、書籍名稱、借書日期、還書日期等。11)超期還書罰款輸入，還書超出期限包括超出期限還書的讀者借書證號，書籍編號，罰款金額。
12)超期還書罰款查詢，刪除，包括讀者借書證編號、讀者姓名、書籍編號、書籍名稱，罰款金額等
13)管理員管理：包括創建讀者用戶信息、刪除讀者用戶信息、添加圖書信息、刪除圖書信息。
3.2事物需求
1)在讀者信息管理部分,要求: a.可以查詢讀者信息。
b.可以對讀者信息進行添加及刪除的操作。
2)在書籍信息管理部分,要求: a.可以瀏覽書籍信息。
b.可以對書籍信息進行維護,包括添加及刪除的操作。
3)在借閱信息管理部分,要求: a.可以瀏覽借閱信息。
b.可以對借閱信息進行維護操作。
4)在歸還信息管理部分，要求: a.可以瀏覽歸還信息。
b.對歸還信息可修改維護操作。
5)在管理者信息管理部分,要求: a.顯示當前數據庫中管理者情況。b.對管理者信息維護操作。
6)在罰款信息管理部分，要求: a.可以瀏覽罰款信息。b.對罰款信息可以更新。
3.3確定用例及編寫用例文檔
用例描述了一個完整的系統事件流程，其重點在于執行者與系統之間的交互而不是內在的系統活動，并對執行者產生有價值的可觀測結果。
在這個“圖書管理系統”中的用例圖如下所示。
用例圖不能提供用例所具有的全部信息，為此需要使用文字描述那些不能放在圖形上的信息。用例文檔是關于執行者與系統如何交互的規格說明，要求清晰明確，沒有二義性。在描述用例時，應該只注重外部能力，不涉及內部細節。
4.非功能需求 4.1 性能需求
學校對系統性能無特殊的要求，只要查詢圖書的時候沒有明顯的延遲就可以了，查詢的時間不要超過3秒鐘。條件、假定和限制：
1）系統最小壽命： 系統應該能在無重大改動的條件下正常運行5年以上。
2）對設備的要求：
要求計算機穩定性良好，整套系統經濟實惠。
3）可以利用的信息和資源：
圖書管已經配置了所有的計算機，以及網絡設備，操作人員將使用win2003 4)圖書管員工受過較好的計算機方面的培訓，在調研的時候感覺有不少員工有計算機方面的專業經驗。5）編目要參照中圖法。
安全性需求
對于圖書管理系統的圖書量會非常大，所以在對這些圖書導入和查詢時要保證速度。在圖書借閱過程中又要保證事務的完整性。對于整個系統，需要完整的權限控制，防止某些人惡意攻擊系統，修改原始記錄，同時對于數據庫中的數據需要定時備份，防止系統數據丟失。此外，系統要求用戶在登陸時需要身份驗證。
5.故障處理
在正常情況下，應不出錯。一旦發生意外，比如掉電、網絡不通等，也應保證系統數據不會丟失。
故障出現后可能采取的變通措施，包括：
備份：使用附加存儲設備備份數據。備份頻率為每日一次。需手動備份。恢復及再啟動：如果數據造成丟失，可使用備份數據還原。
點擊咨詢 