第一篇：軟件需求書的寫作要求

引言

1.1 編寫目的【闡明編寫需求說明書的目的，指明讀者對象。（本文檔的編寫目的，闡述用戶需求，完成用戶功能模型的分析，為設計奠定開發基礎。）】

1.2 項目背景

【應包括

● 項目的委托單位、開心單位和主管部門；

● 該軟件系統與其他系統的關系。】

1.3 定義

【列出文檔中所用到的專門術語的定義和縮寫詞的原文。】

1.4 參考資料

【可包括

● 項目經核準的計劃任務書、合同或上級機關的批文

● 文檔所引用的資料、規范等

● 列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源】 2 任務概述

2.1 目標

【闡述系統目標（做系統分析前的目標），用戶希望達到的目標，描述系統需求條目。做一個簡單的功能結構圖，將用戶需求條目歸類到功能分類中】

2.2 運行環境

2.3 條件與限制

【系統運行前置條件，主要是系統運行對其它系統的依賴】數據描述

3.1 表態數據

【表態數據主要是描述實體對象和關系對象，表結構數據存儲的描述】

3.2 動態數據

【系統模塊之間的數據交流，包括輸入數據和輸出數據。】

3.3 數據庫描述

【給出使用數據庫的名稱和類型。】

3.4 數據詞典

實體數據的詞條

業務流程的詞條

【進行數據詞典分析，對詞條進行詳細描述】

3.5 數據采集

【需要采集的數據包括為系統運行之前需要準備的數據，系統初始化數據】 4 功能需求

使用用例分析來分析功能

4.1用例分析

對功能進行描述，分析功能，形成用例圖

【進行系統功能結構分析】

4.2用例描述

1、用例1

n目標

n事件流（業務處理流程）

n特殊需求

n前置條件

n后置條件

【根據需求條目，使用用例圖分析用戶需求，進行用例描述】性能需求

5.1 數據精確度

【對實時、高敏度系統必須】

5.2 時間特性

【如響應時間、更新處理時間、數據轉換與傳輸時間、運行時間等。】

5.3 適應性

【在操作方式、運行環境、與其他軟件的接口以及開發計劃等發生變化時，應具有的適應能力。】運行需求

6.1 用戶界面

【提出主要功能的界面設計方案，功能的界面流程，界面元素的定義。如屏幕格式、報表格式、菜單格式、輸入輸出時間等。】

1、用例1對應的功能

1)界面步驟1

輸入元素

輸出元素

顯示元素

2)界面步驟2

6.2 硬件接口

6.3 軟件接口

【軟硬件接口指系統與外部系統之間的接口，接口定義的是函數名和參數列表的定義】

6.4 故障處理其他需求

【如可使用性、安全保密、可維護性、可移植性等。】

第二篇：軟件需求說明[范文]

軟件需求說明

某公司總部設在北京，在上海、廣州、成都和西安有分支機構，公司員工接近700名。由于公司業務和員工團隊的迅速發展，為了提升整體工作效率，公司準備開發一套員工報賬系統，取代原來的人工處理方式。

報賬系統將支持員工記錄（或預見）日常業務活動的開銷，并自動結算每個月應該返還員工的補償金額，補償額會直接存入員工的工資帳戶中。

報賬系統應具有基于先進技術的圖形化界面，員工可以輸入業務活動的種類和簡短描述，活動開銷的類別，選擇不同的支付方式，并可以生成靈活的報表。

報賬系統應該有能力根據員工提供的信息和要求返還補償額，同時保存全部員工的報賬信息。員工可以通過他們自己的電腦來使用報賬系統。由于牽涉到財務信息，報賬系統必須提供可信的安全機制。

公司現有一套基于MicroSoft SQL Server的人事管理數據庫系統，記錄員工共的基本信息和團隊的組織結構。報賬系統將和現有人事管理數據庫系統協同工作，需要引用人事管理數據庫系統中的部分信息，但不會更新其內容。

通過報賬系統，員工能夠在出差前（提前2天）按照規定的額度向公司申請借款，相關的經理人員能夠通過報賬系統批復或拒絕。報賬系統應在相關負責人批復之后通知該員工提取現金或確認相應款項已經劃入指定信用卡（根據員工的要求）；員工可以通過保賬系統報銷合理的業務活動經費。

財務部門將指定一位報賬系統管理員監督擬建系統中的信息，負責初始設置和維護特定的分類額度準則，并能夠定期或隨機地向部門負責人提交報賬系統情況的統計報告。

報賬系統在每月的25日對通過審批的報賬申請自動作一次結算，并以電子郵件的方式通知應該得到補償的員工，同時生成一份統計報告傳送給財務部門的系統監管人員。

具體的局部功能需求-----“提交報銷申請”的Use Case

簡介：

員工通過報賬系統填寫報銷申請，輸入相關活動產生的費用，在一次或者多次填寫后提交，經驗證之后，以電子郵件的方式通知相應經理批復。

事件流（Flow of Events）

基本事件序列(Basic Flow)1.打開報銷單

[員工]：員工選擇進入“報銷申請”功能。

[系統]：該員工當月報銷單存在，系統將取出相應信息并展示給員工；如果該員工的當月報銷單不存在，則轉至A1備選事件序列。2.添加報銷記錄

[員工]：員工要求添加一條報銷記錄。[系統]：系統顯示一條空白的報銷記錄。3.填寫報銷記錄單

[員工]：員工開始填寫報銷記錄，每條報銷記錄包括的信息有：業務活動發生的時間、為了讓員工方便而準確地輸入相關信息，除了客戶名稱、業務活動原因和金額之外，其他信息域提供相應的下拉式選擇列表。并記錄員工輸入的信息。

（重復以上針對每一條報銷記錄的活動），直至所有記錄填寫完畢。）4.驗證報銷單

[員工]：員工填寫完畢所有報銷記錄之后，要求系統驗證這些記錄的合理性。[系統]：報銷記錄的初始狀態為“未驗證”，每當一條報銷記錄被驗證為合理，系統將該報銷記錄的狀態設置為“已驗證”，系統在驗證所有報銷記錄（為“已驗證”）之后提示用戶可以提交本月的報銷單。驗證為合理的記錄必須滿足集中條件：第一，不同種類的費用不超過相應得限額；第二，報銷費用的類型要和員工的職能匹配。對于未通過的驗證的報銷記錄，轉至A5備選事件序列 5.提交報銷單

[員工]：所有報銷記錄經過驗證之后，員工提交當月的報銷單。

[系統]：系統保存這張報銷單，將報銷單的狀態設置為“已提交”并記錄提交日期，同時這張報銷單被設為“只讀”。系統要從人事管理數據庫中獲知該員工及其經理（負擔該員工當月開銷者）的電子郵件地址。如果此時人事管理數據庫不可用，轉至A6備選事件序列。

為了及時通知相關人員，系統將自動生成一份以當前報銷單為內容的電子郵件發送到該員工及其經理的信箱中。當郵件成功發送后，員工得到一個確認信息。如果此時郵件系統未能將郵件及時發送，轉至備選事件序列A7。

備選事件序列組（Alternative Flows）

A1 創建當月報銷單

[起始位置]：基本事件序列中，員工進入報銷申請程序并準備打開當月報銷單。

[觸發條件]：系統沒有發現和該員工對應的當月報銷單。

[具體內容]：系統為員工創建一張當月報銷單。

[返回位置]：基本事件序列中的“打開報銷單” 步驟。

A2 刪除報銷記錄

[起始位置]：在提交報銷單之前任意時間點。

[觸發條件]：員工希望刪除某一條報銷記錄。

[具體內容]：系統刪除有員工指定的某一條報銷記錄。[返回位置]：同“起始位置”。

A3 更新報銷記錄

[起始位置]：在提交報銷單之前任意時間點。

[觸發條件]：員工希望更新某一條報銷單。

[具體內容]：系統根據員工輸入的內容更新相應的一條報銷記錄。[返回位置]：同“起始位置”。

A4 保存當月報銷單

[起始位置]：該Use Case 允許員工在事件流中的任意時間點保存當月的報銷單。

[觸發條件]：員工希望將已經錄入的報銷記錄保存在報賬系統中。

[具體內容]：系統保存該員工當月報銷單，并給出確認信息。員工可以在保存當月報銷單之后直接退出系統。

[返回位置]：同“起始位置”。

A5 報銷記錄不合理

[起始位置]：基本事件序列中，“驗證報銷單”步驟中對每一條報銷記錄驗證結束之后。

[觸發條件]：包銷記錄不滿足某一條適用的準則。有兩種情形：第一，某報銷記錄的金額超出了其對應類型費用的上限，已知有三種：請客戶用餐人均超過300元，出差時每天住宿費超過800元，移動電話費再無特殊說明情況下超過800元；第二，報銷費用的類型和員工所處部門及職能不匹配，已知的情形是業務部門的員工申請加班補助。

[具體內容]：系統告知員工不合理的報銷記錄編號，以及未通過驗證的原因。[返回位置]：即本事件序列中的“填寫報銷單”步驟，目的是更正有問題的報銷記錄。

A6 人事管理數據庫不可用

[起始位置]：即本事件序列中，提交報銷單步驟結尾

[觸發條件]：當報賬系統向人事管理數據庫索取信息而該數據庫沒有正常的響應。

[具體內容]：以對話框形式告知員工“人事管理數據庫不可用，報賬但沒有提交成功”。

[返回位置]：Use Case 執行結束。

A7 郵件未即時發出

[起始位置]：基本事件序列中，“提交報銷單”步驟的結尾，成功地從人事管理數據庫獲得相關信息后。

[觸發條件]：報賬系統要求發送相關郵件時，郵件系統沒有及時的響應。

[具體內容]：系統將以提示信息的方式告知員工“郵件沒有及時發出，但是報銷單在系統內已經提交成功，待郵件系統恢復后，相關郵件會自動發出”。[返回位置]：Use Case 執行結束。

特殊需求列表（專屬于該Use Case）

暫無

啟動條件

員工成功登錄系統，通過身份驗證。被系統提示進入“報銷申請”或“借款申請”功能。

結束狀態(組)如果該Use Case 順利執行，員工得報銷申請記錄將被建立，更新、保存或者保存并提交；否則，系統地狀態應該保持和該Use Case 執行之前相同。

輔助圖示(活動圖)

“補充規約”要點 1.RDBMS數據庫訪問 2.分布式處理

詞匯表 要點

? 員工。公司的正式雇員

? 經理。負責審批某員工當月開銷的管理者，是較高級別的員工。

? 報銷紀錄。與業務有關的某一項具體的花費，包括業務活動發生的時間、地點、客戶名稱（可選）、原因以及費用金額和種類（交通、餐飲、會議、通信和雜項）。? 報銷單。員工在一個（自然）月內的所有報銷紀錄的集合。

? 工資戶頭。公司將員工用于日常業務活動開銷的補償金額返還至員工的銀行賬戶，該帳戶的基本功能是供員工接受工資。

? 人事管理數據庫。該數據庫紀錄了有關人事管理的相關信息，與報帳系統有關的是公司的組織機構(“員工”和“經理”的關系)。

? 內部郵件系統。該郵件系統負責收發與公司業務有關的電子郵件信息。

“提交報銷申請”[控制，SubmitClaim]的Use Case

簡介：

員工通過報賬系統填寫報銷申請，輸入相關活動產生的費用，在一次或者多次填寫后提交，經驗證之后，以電子郵件的方式通知相應經理批復。

事件流（Flow of Events）

基本事件序列(Basic Flow)打開報銷單

[員工]：員工[實體，關鍵抽象，Employee]選擇進入“報銷申請”[邊界，SubmitClaimForm]功能。

[系統]：如果該員工當月報銷單[實體，關鍵抽象，ClaimReport]存在，系統將取出相應信息并展示給員工；如果該員工的當月報銷單不存在，則轉至A1備選事件序列。添加報銷記錄

[員工]：員工要求添加一條報銷記錄。[系統]：系統顯示一條空白的報銷記錄。填寫報銷記錄單

[員工]：員工開始填寫報銷記錄[實體，關鍵抽象，ClaimRecord]，每條報銷記錄包括的信息有：業務活動發生的時間、地點、客戶名稱（可選）、原因以及費用金額和種類（交通、餐飲、會議、通信和雜項）。

[系統]：系統顯示并記錄員工輸入的信息。為了讓員工方便而準確地輸入相關信息，除了客戶名稱、業務活動原因和金額之外，其他信息域提供相應的下拉式選擇列表。

（重復以上針對每一條報銷記錄的活動），直至所有記錄填寫完畢。）驗證報銷單

[員工]：員工填寫完畢所有報銷記錄之后，要求系統驗證這些記錄的合理性[實體，ValidRule]。

[系統]：包銷記錄的初始狀態為“未驗證”，每當一條報銷記錄被驗證為合理，系統監該報銷記錄的狀態設置為“已驗證”，系統在驗證所有報銷記錄（為“已驗證”）之后提示用戶可以提交本月的報銷單。驗證為合理的記錄必須滿足集中條件：第一，不同種類的費用不超過相應得限額；第二，報銷費用的類型要和員工的職能匹配。對于未通過的驗證的報銷記錄，轉至A5備選事件序列 提交報銷單

[員工]：所有報銷記錄經過驗證之后，員工提交當月的報銷單。

[系統]：系統保存這張報銷單，將報銷單的狀態設置為“以提交”并記錄提交日期，同時這張報銷單被設為“只讀”。系統要從人事管理數據庫[邊界，HRDatabase]中獲知該員工及其經理（負擔該員工當月開銷者）的電子郵件地址。如果此時人事管理數據庫不可用，轉至A6備選事件序列。

為了及時通知相關人員，系統將自動生成一份以當前報銷單為內容的電子郵件發送到該員工及其經理的信箱中。當郵件成功發送后，員工得到一個確認信息。如果此時郵件系統[邊界，MailSystem]未能將郵件及時發送，轉至備選事件序列A7。

第三篇：軟件需求-案例分析

1、問題描述

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。

2、情景描述的主要成分

2.1、該系統所涉及的用戶

本系統的用戶包含患者、醫生以及管理員三類。而且該三類用戶各自的特征和所要面對的情景也是截然不同的。

對于患者來說，他們在年齡、計算機使用能力等方面存在較大差異，但面對的情景都一樣，就是要預約掛號，掛號成功過后就診。

對于醫生來說，普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。所面對的情景有查看掛號信息，確定要就診的病人。

對于管理員來說，他們負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。

不同的用戶，對系統的要求也不相同。患者希望通過完成注冊和登錄后能夠進行掛號預約，查詢醫生的出診信息和個人預約信息，并且能夠在規定的時間內完成掛號預約或者取消已有的預約；醫生則希望能夠在登錄系統后可以查看病人的預約情況；而管理員希望可以修改出診信息和調整預約掛號。這些都是功能性的需求。

同時對于所有用戶都希望該系統是易用的，而且能夠對自己的信息起到保護即系統安全性的要求，還有比如說系統的性能比較高效，能夠及時處理自己的預約申請。當然開發系統的成本如果也能較低就更好了。這些都是非功能需求。

2.2、情景描述的主要成分

? 目標和關鍵成功因素

預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。關鍵成功因素，要保證系統能夠24小時正常穩定的運行，系統里的信息要是實時變化的，即可以預約的醫生要和實際在值班的醫生要匹配，不能出現掛上號了卻沒有醫生就診的情況。

? 物理上下文和邏輯上下文 物理上下文：醫院用于掛號的計算機可以正常的使用，情景中的可以被預約的醫生應該是在醫院值班的；而對于患者可以選擇在醫院進行預約，也可選擇在家中進行預約，只要在預約時間內能到達醫院就可。邏輯上下文：事件發生的條件是患者在系統中進行了預約，然后管理員會根據現有的資源（可以預約的醫生）對預約進行處理，如果同意，下一步就是醫生就診；如果沒有可以預約的醫生或合適的時間，患者的預約就不成功，患者需要重新選擇醫生或時間進行預約。

? 組成情景的主要事件和活動 主要事件：患者預約掛號，管理員對預約掛號的處理，醫生就診。主要活動：患者注冊、登錄系統，患者在系統中查詢可以預約的醫生和時間，患者取消已有預約，患者進行就診；管理員接受或拒絕預約，管理員分配醫生；醫生查詢預約信息。

? 涉及的執行者和其他參與者

執行者：醫院的醫生，預約掛號系統的管理員。其他參與者：醫院的相關人員，比如患者，前臺咨詢員等。

? 要使用的信息和資源 要使用的信息和資源包括，可以預約的醫生數量，所在科室等，醫院中的設備，病房等。? 要考慮的約束條件和要使用的規則 約束條件：同一醫生同一時間段內只能接受一名患者的預約，根據醫療設備的屬性決定是否要排他性的使用。

3、情景需求分析的步驟

需求規格說明輸入過程需求目標列表1.目標分析系統模型目標,目的使用情景用戶問題實例2.輸入事件分析初始系統模型用戶,環境事件情景腳本4.輸出需求分析3.刻畫系統輸出情景結構模型系統輸出類型信息需求5.社會影響分析Agent目標6.涉眾分析需求規格說明

3.1 目標分析

在第2部分情景描述的主要成分中已經對目標進行了分析，即：預約掛號情景的目標是“讓患者能夠及時的掛號，并能順利的就診”，而可能的子目標包括：患者能夠注冊賬號，患者能夠登錄賬號，患者能夠查詢預約記錄，患者能夠取消已有預約，患者能夠查詢出診信息。3.2 輸入事件分析

對于該系統的輸入事件可能會包括如下情況：初始使用該系統的用戶需要先注冊，而對于已經注冊的用戶在使用系統預約掛號時首先要登錄系統。這是最基本的兩個輸入事件。3.3 刻畫系統輸出

對于系統輸出我們要考慮系統輸出的形式，比如消息顯示，對話框等形式。不如用戶在登錄系統是輸入的用戶名和密碼不匹配的時候要給出對應的提示信息，比如用戶名未注冊或密碼不對等。在提交預約掛號申請后系統也應給出預約成功與否的提示。3.4輸出需求分析

對于輸出需求要根據用戶的輸入給出對應的輸出。比如用戶輸入查詢請求，那么系統應該能夠給出詳細的信息。系統只給出對應的輸出還不夠，同時要考慮輸出的信息是否合適。比如用戶要查詢眼科醫生的資料，系統的輸出就應該只是眼科醫生的信息，而沒有必要把所有醫生的信息都輸出。3.5 社會影響分析

在進行社會影響分析時要同時考慮到積極和消極兩個方面的問題。系統是否可以提高效率，減少人員的工作量。同時也要考慮過多的自動化是否會削弱人對整個系統的意識，導致人對意外處理的能力降低，比如系統臨時出現問題，是否有一套應急措施使醫院日常工作能夠正常的進行。

4、需求說明文檔

基于之前構建的模型，并參照IEEE 830-1998標準模板，撰寫的系統需求說明文檔如下。

4.1 引言

引言部分將對本文檔的編寫目的、系統的開發目的、名詞定義以及參考資料進行說明，并對文檔的后續內容進行概述。4.1.1 編寫目的

網上預約掛號系統是基于Web開發技術完成的網站。為了更好的設計并實現這一系統，對系統進行需求建模和分析是十分必要的。因此，基于之前構建的各類模型，撰寫系統的需求說明文檔，并將其作為后續項目設計、項目開發和項目測試的指導。

本文檔連同之前構建的模型，可用來與客戶進一步明確需求，同時可供項目經理、設計人員、開發人員參考。4.1.2 系統目的

許多醫院存在高峰期掛號排隊時間長，就診等待時間長，倒號現象頻發的問題。因此，構建一個網上預約掛號系統，通過推薦患者使用該系統進行出診信息查詢和醫生預約，可以緩解就診壓力、節約患者的時間，并且可以在一定程度上保證預約者和就診者一致，有利于提高醫院的服務質量。4.1.3 名詞定義 ? 患者預約系統

網上預約掛號系統的子系統，主要用于為患者提供預約掛號、信息查詢等功能。? 醫生工作查詢系統

網上預約掛號系統的子系統，主要用于為醫生提供各時段預約患者的信息。? 醫務管理系統

網上預約掛號系統的子系統，主要用于為管理員提供出診信息修改、預約掛號調整等功能。? 賬號控制系統

網上預約掛號系統的子系統，主要用于用戶賬號的注冊及登錄控制。? 安全保障系統

網上預約掛號系統的子系統，主要用于保障系統的程序、網絡及數據庫安全。4.1.4 參考資料

[1]Objectiver: A KAOS tutorial.Respect-It(2004)[2]吳雙兵,劉偉.網上預約掛號系統設計與實現[J].醫學信息學雜志, 2015, 36(1):36-39.4.1.5 文檔概述

需求說明文檔主要分為三個部分。本節屬于引言部分，主要用于對文檔本身進行定義和描述。文檔的第二部分為系統的整體描述，包括系統的預期目標、限制條件以及用戶的需求、特征。文檔的第三部分是需求說明，包含對系統需求的明確定義。

4.2 整體描述

本節將對系統預期、用戶需求、用戶特征、條件與限制、假定與依賴以及需求分配進行說明。

4.2.1 系統預期

為了方便用戶在不需安裝任何軟件的情況下使用系統，本系統整體采用B/S結構，用戶可以通過瀏覽器對其進行訪問。4.2.2 用戶需求

參照之前完成的目標模型，對用戶的需求進行整理和定義。由于系統整體較為復雜，因此本小節只包含已構建目標模型的功能性需求和非功能性需求。? 功能性需求

1.患者進行預約選擇

為了實現患者進行預約選擇的目標，系統應完成的需求如下。（1）系統擁有患者預約頁面以及預約按鈕：

系統的預約頁面可以顯示未來1至3天的出診醫生及其所有可被預約的出診時段。其中，尚未被預約的時段擁有預約按鈕；已被預約的時段無法被其他患者預約，因此無預約按鈕。（2）系統接收到預約請求：

當患者點擊預約按鈕，系統可以接收到預約請求。（3）患者被告知預約選擇結果：

系統可以對患者是否預約成功進行判定，如果成功則跳轉至信息確認頁面，否則彈出對話框給予患者相應提示。2.患者確認預約信息

為了實現患者確認預約信息的目標，系統應完成的需求如下。（1）系統擁有預約信息確認頁面以及預約提交按鈕：

系統的預約信息確認頁面會顯示預約的醫生和時段，患者的個人信息，以及預約提交按鈕，患者可以在提交預約前核對這些信息。（2）系統接收到預約提交請求：

當患者點擊提交按鈕，系統可以接收到預約提交請求。（3）患者被告知預約提交結果：

系統可以對預約是否提交成功進行判定，并彈出對話框給予患者相應提示。? 非功能性需求 1.安全的系統

為了保證預約掛號系統的安全性，系統應完成的需求如下。（1）用戶程序安全：

系統應明確區分不同類別用戶的權限。并且在用戶登錄時，輸入的密碼不可見、不可復制。（2）系統網絡安全：

系統應采取安全的網絡傳輸協議，網絡數據在被傳輸前應進行加密。（3）數據庫安全：

數據庫中存儲的數據應具備完整性，且密碼應在加密后被存儲到數據庫中。此外，數據庫中的數據應該可以被備份和恢復。2.低成本的系統 為了保證預約掛號系統的低成本，系統應完成的需求如下。（1）系統開發成本低：

開發團隊應具備合理的項目管理，且在開發前應盡可能明確系統的需求。（2）系統運營成本低：

系統在運行過程中，應該盡可能少的占用資源。（3）系統維護成本低：

系統應該健壯可靠，出現問題后應該易于修復，且系統的功能應該易于擴展。考慮到系統健壯可靠與系統開發成本低存在一定的沖突，因此需要進行一定的權衡。4.2.3 用戶特征

本系統的用戶包含患者、醫生以及管理員三類，其特征如下。? 患者

個體間在年齡、計算機使用能力等方面存在較大差異。? 醫生

普遍具備較高的學歷，在醫療方面具備專業知識，有一定的計算機使用能力。? 管理員

負責對出診信息進行管理，是醫院工作的安排者，具備較強的計算機使用能力。4.2.4 條件與限制

為了保證系統的可移植性和可擴展性，本系統應使用Java語言進行開發。4.2.5 假定與依賴

本系統假定提供的大、中、小三種字體大小可以滿足不同患者的需求，并且患者可以在系統的引導和提示下正常使用系統。4.2.6 需求分配

由于文檔中并未列出系統的全部需求，因此無法對所有需求進行優先級排序。但已經列出的均為系統較為核心的功能性需求和非功能性需求，應具有高優先級。

4.3 需求說明

需求說明部分將參照之前完成的模型，對系統結構、對象模型以及操作過程模型進行詳細描述。

4.3.1 系統結構

本部分將主要參照圖 3-1所示的責任模型，根據主體對需求進行劃分。考慮到系統較為復雜，因此只列出主體“患者預約系統”的相關需求。? 患者預約系統

系統擁有患者預約頁面以及預約按鈕。

系統接收到預約請求。

患者被告知預約選擇結果。

系統擁有預約信息確認頁面及預約提交按鈕。

系統接收到預約提交請求。

患者被告知預約提交的結果。4.3.2 對象模型

本部分將主要對圖 4-1所示的對象模型的結構進行解釋。

網上預約掛號系統可以被詳細劃分為患者預約系統、醫生工作查詢系統、醫務管理系統、賬號控制系統、安全保障系統等五個子系統。患者預約系統、醫生工作查詢系統、醫務管理系統的使用者分別為患者、醫生和管理員，這些用戶通過系統提供的頁面與系統進行交互。

對象模型中所涉及的名詞在4.1.3小節中有具體解釋。4.3.3 操作過程模型

本部分將主要對圖 5-1，圖 5-3和圖 5-4所示的操作過程模型進行說明，并以表格的形式列出各操作過程的參與主體及對應需求。? 患者進行預約選擇

患者點擊預約按鈕后，患者預約系統會收到患者的預約請求，并觸發預約驗證操作，得到預約驗證結果。接下來，患者預約系統會以得出的預約結果為基礎，進行預約結果判定，進而執行頁面跳轉或消息框彈出操作。? 患者確認預約信息

患者點擊提交按鈕后，患者預約系統會收到患者的預約提交請求，并觸發預約提交操作。接下來，患者預約系統會根據提交結果彈出包含相應信息的提示框。

以上部分涉及到的操作過程及與之對應的主體、需求如下表所示。

以上部分涉及到的操作過程及與之對應的主體、需求如表 4-1所示。

操作 預約驗證 參與主體

對應需求

患者預約系統 系統接收到預約請求，患者被告知預約選擇結果

預約結果判定 患者預約系統 患者被告知預約選擇結果 預約提交 患者預約系統 系統接收到預約提交請求，患者被告知預約提交結果

第四篇：軟件項目需求建議書

篇一：軟件需求建議書

醫院門診管理系統需求建議書

2012年3月26日

有關公司：

現需一個醫院門診管理系統，要求具有相關項目經驗的軟件公司參與競標，要求能對該系統進行合理的編寫，保證系統能夠穩定運行，并且在預定時間內交付我院使用。

項目目標：

系統分為5個子系統，即（a）掛號管理系統(b)病歷管理系統(c)藥品庫存管理系統(d)內部資料管理系統(f)財務管理系統。并且需要保證系統運行穩定準確。

1.工作表述

承包商應執行以下工作任務，及工作要求：

(1)系統應使用本院的局域網，win98、win2000、winxp、win7等環境

下，可進行穩定準確的查詢，修改、處理功能。

(2)數據錄入功能：其中包括在掛號時的患者信息錄入，病歷管理的錄

入處方和內部資料管理中的醫師信息的添加。

(3)數據的修改和刪除功能：其中包括改號、退號和內部資料管理中的

患者、醫師信息的修改和刪除功能。

(4)數據查詢功能：包括在診室管理中的藥品的模糊查詢，對庫存不足

的藥品報警，內部資料管理中的醫師、患者信息的查詢中包括單項查詢和組合查詢。

(5)統計報表功能，財務報表：統計每天患者交款報表和掛號員每天的

交款單。統計患者總人數和總費用。

(6)按處方類別和拼音碼分別統計藥品的總數和庫存剩容量。

(7)按科室名稱和是否專家級別分別統計醫師總人數信息。日報表：打

印每天的患者人數、就診科室等，以及醫師每天的出診數，檢驗、檢查、手術每天的執行次數，以及這些項目的總金額。

(8)合計費用功能：患者憑掛號單到交款處交款，系統根據門診號碼自 動調用患者信息，顯示患者的單項費用和總費用，自動找零。

(9)系統管理功能：其中包括用戶和內部人員的修改密碼功能，根據權

限添加用戶和管理員。數據備份功能。

(10)幫助功能：包含醫院簡介和系統主要實現功能簡介。

2交付實物

（1）必須準備一份詳細的系統設計報告，以及所用到的技術，用以監測產品

質量。

（2）有關項目進程的書面報告必須在每15天交給本院。報告應簡明，并且

重點放在與承約商的原計劃和時間表相對應的進程上。報告應涉及到各項活動、取得的進展、接下來15天的計劃、花費的時間與金錢。對于落后進度計劃進程的工作項目，應當提供一份計劃，使項目能在原進度計劃和預算內完成。

（3）在合同預期內，交付我院一個能夠運行正常穩定的完整的系統。并且在

后期一定時間內提供免費維護。

3其他要求

（4）本院會向承包商提供本院的一些業務流程。

（5）承約商必須在執行工作前，獲得本院對最終計劃的認同。

（6）合同必須以一個商定的價格，給提供滿足需求建議書要求工作的承約商

付款。

（7）承約商必須最遲在2012年5月1日以前提供給本院兩份建議書備份。

（8）本院希望在2012年6月1日前選中一家承約商。這個工程需要完成的

期限是十二個月，從2012年7月1日至2013年7月1日，所有交付物必須不遲于2013年10月1日提供給本院。

（9）本院將按照下面的時間表付款給承約商：當項目完成了1/3時付總額的

1/3；當項目完成了2/3時付總額的2/3；當本人已經滿意于項目的100%，并且承約商已履行了全部契約義務時再付出總額的最后1/3。

申請內容

(1)承約商能清晰理解需求建議書，理解什么是被期望達到的要求。承約商應有對每個任務和任務如何完成的詳細描述。

(2)承約商將要提供的每一份交付物的描述。

(3)列出條形圖或網絡圖表，列明每周要執行的詳細任務的時間表，以便在要求的項目完成日期內能夠完成項目。

(4)敘述一下承約商最近已經執行過的相似項目，包括已完成的子系統，以及其他子系統的完成進度。

(5)列出工程具體人員的姓名和詳細簡歷，以及他在類似工程的精彩的經歷。

(6)必須說明項目所需要的人月，并通過一份詳細的工作時間分解和每個被指派于工程的員工的小時成本費用來驗證。此外，所有直接費用逐條列表也必須包括進來。

(7)承包商需列出貴公司的軟件能力成熟度(cmmi)等級。

(8)本院將按照以下的標準評價所有承約商的申請書：

a．設計方案(30%)。設計的實用及涉及技術。

b．經驗(30%)。被指定工程的承約商和工作人員執行類似工程的經驗。

c．成本(30%)。承約商申請中的所列的固定成本。

d．進度計劃(10%)。為了在要求的項目完成日期內或在此日期之前完成項目，承約商應提出進度計劃的詳細而全面的連續說明。

篇二：軟件系統項目建議書完全版

****系統項目建議書

2014年5月

目錄

概述....................................................................1 1.1 文檔編寫目的...........................................................................................................1 1.2 系統建設目標與內容...............................................................................................1 1.2.1 系統建設目標...................................................................................................1 1.2.2 系統建設的主要內容.......................................................................................1 2 系統設計方案.............................................................1 2.1 總體架構設計...........................................................................................................1 2.1.1 系統總體業務架構...........................................................................................1 2.1.2 系統總體軟件架構...........................................................................................1 2.1.3 系統總體技術架構...........................................................................................1 2.2 系統組成...................................................................................................................1 2.3 系統數據流...............................................................................................................1 2.4 系統功能...................................................................................................................3 3 系統部署方案.............................................................3 3.1 系統部署架構...........................................................................................................3 3.2 系統環境...................................................................................................................3 3.2.1 軟件環境...........................................................................................................4 3.2.2 硬件環境...........................................................................................................4 4 系統界面設計.............................................................4 5 主要技術指標.............................................................4 6 交付成果................................................................6 7 驗收策略................................................................6 7.1 系統驗收測試的原則...............................................................................................6 7.2 驗收測試的具體內容...............................................................................................7 7.3 驗收測試的步驟.......................................................................................................7 8 質量保證................................................................8 8.1 軟件研制一般要求...................................................................................................8 8.2 軟件評審要求...........................................................................................................9 8.3 軟件配置管理要求.................................................................................................10 9 售后服務...............................................................10 9.1 培訓.........................................................................................................................10 9.2 維護與升級.............................................................................................................10 9.3 質量保證期內的服務.............................................................................................10 9.4 壽命期內維修服務.................................................................................................11 10 開發進度計劃............................................................11 11 項目報價...............................................................12 1 概述

1.1 文檔編寫目的 1.2 系統建設目標與內容

1.2.1 系統建設目標 1.2.2 系統建設的主要內容

系統設計方案 2.1 總體架構設計

2.1.1 系統總體業務架構 2.1.2 系統總體軟件架構 2.1.3 系統總體技術架構

2.2 系統組成

2.3 系統數據流

系統詳細數據流如下圖所示。

2.4 系統功能

系統部署方案 3.1 系統部署架構

表1各子系統部署架構

3.2 系統環境 篇三：需求建議書

題目：

假設你在嘉州新城購買了一套二室二廳一廚一衛，面積大約90平方的新房，先裝修入住，請你根據自己的需求對這個房屋裝修項目編寫項目需求建議書。

項目：房屋裝修

需求建議書：

（1）承約商要執行的任務：裝修材料的購買、家用設備的安裝、裝修工程。

① 代購裝修材料，如：地磚、涂料等等

② 廚房器具、淋浴設備等的代購

（2）承約商根據國家標準裝修，提供裝修計劃、施工方案，最后裝修符合標準的房

子。

（3）本人向承約商提供裝修方案。

要求：

①、臥室的顏色以暖色調為主

②、裝修后簡單、寬敞、采光效果良好

③、衛生間隔成兩部分，分為盥洗間和浴室

（4）和承約商簽訂一個商定的價格，以及滿足需求建議書的工作承約商付款合同。

（5）當裝修工程完成1／2時付總額的1／2；當裝修工程100%完成時，獲得本人的

滿意后，并且承約商已經全部履行契約義務時再付總額的最后1／2。

（6）希望這個項目在兩個月內完成，從5月15日到7月15日，所有的可交付成果 必須不遲于7月15日提供給本人。

（7）承約商必須最遲于4月30日以前向本人提交兩份申請書備份。承約商的申請書

至少包括以下內容： 1）承約商能清晰的理解需求建議書，要詳細描述承約商的實施裝修項目的方法，以及使用的裝修材料的具體規格。

2）承約商要提供可交付成果的詳細描述。

3）在6月15日向本人反映項目進行的進度。

4）敘述承約商最近實施的項目，包括客戶的姓名、地址和電話號碼，以備核實。

5）列出將被指定為項目主要負責人的姓名和聯系方式，以及工作經驗。

（8）申請書的評價標準

1）承約商提出的建設方案（30%）

2）被指定為執行此項目主要負責人的姓名和聯系方式，以及類似的工作經驗（30%）

3）承約商申請書所列的固定成本（30%）

4）承約商提供的施工計劃（10%）

組員：岳紅 117 王華 213 周燕飛 126 趙涵玉 223 曾志錦 203 篇四：需求建議書

需求建議書（request for proposal，rfp）

什么是需求建議書[1] 需求建議書是指從客戶角度出發，全面、詳細地向服務商陳述、表達為了滿足其已識別需求所應做的準備工作。也就是說，需求建議書是客戶向服務商發出的用來說明如何滿足其已識別需求的建議書，是客戶與服務商建立正式聯系的第一份書面文件，又稱招標書。需求建議書一般由客戶起草，主要描述客戶的需求、條件及對項目任務的具體要求。一份完整的需求建議書主要包括滿足其需求的項目的工作自述、對項目的要求、期望的項目目標、客戶供應條款、付款方式、契約形式、項目時間、項目申請書的要求等。好的需求建議書能讓服務商準確把握客戶所期待的產品或服務。當然，并非在所有情況下都需要準備一份正式的需求建議書，當某一企業的需求由內部開發項目予以滿足時，這一過程似乎變得簡單多了，此時更多需要的是口頭上的交流和信息傳遞，而不是把寶貴的時間耽擱在僅僅起到信息傳遞作用的需求建議書上。例如，某一軟件開發公司感到公司原來的財務分析系統已經遠遠不能適應日益增加的業務需要時，便可直接要求軟件開發小組進行開發，這時只需口頭把相關的要求傳達給軟件開發小組即可。

[編輯] 需求建議書的主要內容[2] 需求建議書一般包含以下主要內容：

客戶必須搜集大量相關資料準備需求建議書，因為it項目實施者需要按照rfp來準備他們的項目技術方案，并以此參與競標。rfp中包括項目的目標，也就是用戶的期望，也包括客戶要求項目的進度計劃；對實施商申請書的表格和內容的規定；客戶希望潛在的實施商提交投標申請書的最后期限；評價申請書的標準等。一份好的rfp應該包括以下一些內容。

1．工作表述

工作表述就是說明項目的工作范圍，概括客戶要求開發商或項目團隊執行的任務或工作單元，說明項目所涉及的各種事情，哪些必須由開發商或項目團隊去完成，哪些由客戶自己去做。例如，一個辦公自動化軟件系統的具體目標。又如建設一個網站，所需設備的采購任務，是由客戶自己完成，還是由開發商去完成；企業網站上的頁面文字，是客戶自己撰寫，還是由開發商撰寫等。2．任務要求

需求建議書必須要具體規定開發商需要完成任務的規格和特征，如要求涉及大小、數量、顏色、重量、速度和其他開發商提出的解決方案中，所必須滿足的物理參數和操作參數。例如，建立一個企業網站，可能要求在1 000人同時訪問的情況下不會產生堵塞的感覺，網

站的瀏覽頁面不低于多少；建立一個自動結賬和收款系統，可能要求每天能辦理12 000次交易的功能和其他特定的功能，如在開出了發票的30天內沒有收到賬款，就會自動產生催款通知。具體的任務要求，可能會成為將來的驗收標準。

3．交付物

交付物就是開發商所提供的實體內容，這在需求建議書中應該說明。例如，對于自動結賬和收款系統來說，客戶可能要求開發商提供硬件(計算機)、軟件(磁盤和一些印刷品)、操作手冊和培訓課程。交付物也可能包括客戶要求開發商提供定期進度報告或終期報告。

4．客戶供應條款

需求建議書還應該列出客戶的供應條款。例如，客戶需要建立一個網j站，可能需要向開發商提供企業內部的組織結構及各部門之間業務關系的詳]細說明，包括信息流程的類型、信息流量和發生頻率等。5．表述客戶對需求的確認

需求建議書不是對客戶需求的最后確認。最后的確認應該在對開發商提出的方案進行評估之后。例如印刷宣傳手冊，可能在開印之前要經過客戶審定；局域網的建設，在購買材料和設備之前，客戶必須審定開發商的技術方案。這一點在需求建議書中必須向開發商說明。

6．期望的合同類型(1)合同可以按固定價格訂立。這樣，開發商實際上就是費用包干。客戶只給固定的價錢，不管開發商實際工作花費多少。開發商必須保證功能的實現和質量要求，超支的風險由開發商負擔。

(2)合同也可以規定開發商不承擔風險，即在時間、原材料限制的條件下，不論實際成本多少，都會給開發商特定的報酬，也就是所謂包工不包料。在我國現階段的條件下，由于質量檢驗和資信度水平不高，這種合同比]較普遍。在需求建議書中，最好說明客戶是希望采用那種類型的合同。7．期望的付款方式

付款方式可以分為一次性付款和分階段付款；在開始前付款和結束后付款。一般依項目的性質來定付款方式。如網頁制作，往往在項目末期付款；而架設局域網，一般在方案確認后，付款30％以便開發商采購，工程結束驗收后付滿90％，留10％等到使用一段時間以后確認無問題時付清。具體付款方式需要合同雙方協商，但在需求建議書中，客戶應該先提出自己的期望付款方式。8．要求的進度計劃

進度計劃的要求可能很粗，如要求在6個月內完成；也可以詳細一些，如多長時間內完成方案設計和審定，多長時間內完成硬件選購與安裝，多長時間內完成軟件研制、測試與安裝，最后開發商在系統安裝調試后，在多長時間內提交所有的系統文件和操作培訓。9．申請書的格式和內容提示

為了便于在幾個開發商之間進行比較和評價，申請書應該在形式上采取同一個格式，內容的結構也應該一致。這樣對不同的申請者來說比較公平，也能減輕客戶在評審時的工作量。客戶在需求建議書中可以限定申請書的每一部分采用的文字數量或頁數。

10．提交申請書的最后期限

申請書受理的截止日期是必須要交代清楚的。例如，要求開發商在接到需求建議書后多少個工作口之內(如l周之內、1個月之內等)提交申請書，或大家一律在某月某日之前提交申請書。這樣做的目的是便于同時對眾多的申請者進行比較、評估，也是為了保持公正，不給某些開發商以額外的時間和機會。

11．對申請書的評價標準

要告訴開發商客戶將根據哪些準則來評價他提交的申請書。這樣做的目的，是指導開發商寫好申請書。一般評價標準包括4個方面的內容：

(1)開發商在類似項目中的經驗。如他們近期是否在預算內按期完成了類似的項目，客戶對他們是否滿意?(2)開發商提出的技術方案是否合適。如采用哪種類型的計算機軟件?數據庫的設計、方法是什么?用來建立管理信息系統的是哪種語言?采用哪些供應商的設備?等等。

(3)進度計劃。開發商是否能按照所要求的進度完成項目計劃?(4)成本。如開發商的報價是否合理?成本預算中有無漏算的條款?將來在執行時有沒有可能出現超支，或有無可能因過于節約而導致質量不能保證?有的申請人為了爭取合同，在報價上壓低成本，到了執行階段，或偷工減料，或增加成本，結果導致所建系統的缺陷很多，或使最終成本大大超出原始的估算。對此需要引起注意。

12．資金總量

開發商總是希望了解客戶有多少資金可以用于發展擬議中的真t項目，但客戶在需求建議書中，往往不愿意透露這個信息。其實，客戶暗示大約的數字，告訴開發商他打算花多少錢來辦這件事是有好處的，這樣可以使開發商能夠提交與資金水平相適應的申請書，提高在項目準備階段的工作效率。

[編輯] 需求建議書的必要性[2] 需求建議書(rfp)是項目客戶與開發商建立正式聯系的第一份書面文件，也叫招標書。一般由項目的客戶自己起草，主要描述客戶的需求、條件以及對項目任務的具體要求，向可能的開發商發送。

需求建議書是客戶為確保供應商理解項目的需求，并在此基礎上提供項目建議書而編制的需求規范。雖然它不能確保客戶據此就能獲得理想的解決方案，但卻可以幫助客戶發現那些盡可能接近自身需求的系統準備。其

目的是從客戶自身的角度出發，通過全面、詳細地陳述，使開發商或項目團隊理解客戶所希望的是什么，以可行的價格滿足客戶的已識別的需求。

對于一些預算較少的客戶，開發商往往不愿意花精力準備正式的方案建議書，這種情況下，客戶的需求建議書就變得很重要。事實上，項目無論大小，都需要編寫需求建議書。第一，需求建議書需要描述用戶的目標與需求。編制需求建議書的過程也是客戶進一步明確自己的目標與需求的過程，并以此建立起客戶與供應商進行深人溝通的橋梁。即使因為各種原因使得供應商看不到或不愿響應需求建議書，這種努力也是值得付出的。

第二，需求建議書可節省選型的時間，并使得對各供應商之間的比較變得更容易。客戶提供給所有競標供應商的信息都是一樣的，避免了跟各開發商的重復溝通，同時，有需求建議書作為基準，客戶可以約束各開發商以一致的格式提交方案建議書，以提高各供應商之間的可比性。

第三，需求建議書可以避免一些潛在的疏漏。在準備需求建議書時，客戶往往會因為太過關注具體細節而忽略了一些重要的因素。收到需求建議書后，有的供應商可能會主動對這樣的疏漏提出質疑以提醒客戶。還有些開發商為了使自己的方案建議書更具有吸引力，甚至會提出一些需求建議書沒有涉及的好想法來拓展客戶的思路。

[編輯] 編寫需求建議書的一般原則[2] 需求建議書應該由用戶編寫，但各種客觀因素的限制，實際上很難做[到。所以，很多時候都是由用戶與項目小組共同編寫。編寫項目需求說明的j過程也是項目小組帶領客戶進入項目需求啟發的過程。編寫優秀的項目需求[建議書沒有公式化的方法，需要大量的實踐經驗。以下是編寫需求建議書需要把握的幾個原則：

(1)需求應該是正確的。每個需求必須精確描述要交付的功能。確定需求內容是否正確，需要用戶的代表來參與確認，由他們檢查、決定用戶需[求的正確性。沒有用戶的需求檢查就會導致很多項目實施中的問題出現。例如用戶會說：“這不是我們要的東西”；“你沒明白我們的意思”，等等。

(2)需求應該是可行的。項目的需求應該在有限的資源(已知的能力、有限的系統及其環境)下是可實現的。為了避免需求的不可行性，在需求分析階段應該有核心技術人員參與，檢查在技術上什么能做、什么不能做，哪些需要額外的付出等。

(3)需求內容應該是必要的。需求建議書中的每個需求都應該有相應[的出處，即說明什么是客戶確實需要的，什么要順應于外部的需求、接口或標準。如果不能標識出處，則可能這個需求不是真正需要的。

(4)需求內容應該有優先權。優先權是由客戶或其代理及項目小組共同商討后建立的。如果所有的需求都被視為同等重要，那么在開發中遇到預t算削減、計劃超時或組員的離開而導致新的需求時，項目經理將無所適從。一般優先權有以下三個級別。

1)高優先權，表明需求必須體現在本階段項目的成果中或這個產品的版本中。

2)中優先權，表明需求是必須的，但是如果需要可以推遲到晚一些的產品版本中。

3)低優先權，表明有它很好，但我們必須認識到如果沒有充足的時間或資源，它可以被放棄掉。

(5)需求內容應該是明確的。需求不該有歧義，要避免使用一些對于擬訂項目需求建議書的人很清楚，但對于其他人模糊不清的詞匯。如：用戶友好性，容易，簡單，快速，有效，幾個，藝術級，改善的，最大，最小等等。每寫一個需要都應簡潔、直觀地采用用戶熟知的語言，而不要采用計算機術語。

[編輯] 需求建議書例子[2] 例：某企業項目管理軟件開發項目需求建議書

有關單位：某企業(甲方)由于業務發展的需要，決定采用項目管理的方式進行管理，為了更有效地對項目的執行過程進行控制，該企業決定開發一套項目管理軟件以滿足這一需要。

1．工作表述

開發商將執行下面任務：開發項目管理軟件。

開發項目管理軟件的主要功能包括項目及工作信息的錄入、項目網絡計劃圖的繪制、項目時間計劃的安排、甘特圖計劃的制定、項目執行信息的錄入與分析及各種計劃報表的輸出等功能。2．要求

開發商應根據國家有關標準，提供開發計劃和實施方案。篇五：軟件項目管理項目建議書

湖南文理學院實驗報告

時間： 2013 年 11 月 18 日

課程名稱： 軟件項目管理

實驗名稱：撰寫畢業生就業信息管理系統項目建議書

班級： 姓名： 同組人： 無

指導教師評定： 簽名：

一、實驗目的掌握項目建議書的格式和寫作要求，會結合具體項目寫作項目建議書。

二、實驗要求

1、結合模擬項目—畢業生就業信息管理系統項目寫出項目建議書。

2、提交畢業生就業信息管理系統項目建議書（報告）一份。

三、實驗環境 1．硬件：計算機 2．操作系統：windows平臺。

3．相關軟件：microsoft office軟件。

四、實驗步驟

1、背景介紹

隨著internet的迅猛發展和普及，我國高等院校紛紛建立自己的校園網，使高校的辦公，教學和管理工作發生了巨大的變化，并具有了新的特點，對教學管理工作提出了新的要求，也使得基于網絡的高校畢業生就業招聘成為可能。通過internet，用人單位和就業者利用網絡的便利，不直接見面，采用網絡交互地就業聯系、就業面試，以及就業意向和合同的簽訂等工作。我國部分高校目前正在嘗試通過網絡進行畢業生的就業分配工作，但目前使用的就業網站的開發應用，大多功能相對單一，多局限于就業信息的發布，就業信息的靜態統計結果的公布及簡單的就業信息查詢，其實用性和互動性已經不能滿足高校就業形勢的需要。隨著高校畢業生就業體制改革進程的不斷深化和畢業生就業市場的逐步建立，高校畢業生在各種就業活動中求職面窄、擇業率低、特別是信息量小的問題越來越突出。如何解決這一問題是擺在各級就業主管部門面前的嚴峻任務。正是在這種情形下，國務院對做好高校畢業生就業工作做出重要指示，即“要充分利用畢業生就業信息網絡，溝通行業間、地區間、學校與用人單位間的信息，在畢業生和用人單位之間牽線搭橋。同時，通過信息反饋，優化高等教育結構，合理

利用有效資源，促進高等教育的健康發展”高校就業系統以招聘和求職系統為核心，以用人單位需求和服務為目標。明確了系統的定位，有利于構建優化網上就業服務體系，有利于不斷激活畢業生就業市場，有利于網絡資源的充分利用，有利于網上動態管理、杜絕虛假信息、拓寬網上就業服務功能。

2、項目的意義和必要性

畢業生就業信息系統和就業服務體系不完善，畢業生就業主要由學校、人才市場舉辦招聘會等方式獲得信息，與需求方見面，信息渠道比較窄。畢業生的就業指導工作極為薄弱，就業指導教師水平參差不齊，專業的、高素質的就業指導教師太少；缺少優質的就業指導教材。所以，必須加強學生擇業的政策咨詢和信息服務，逐步建立起信息服務網絡，建立畢業生就業網絡系統，為實行網上求職擇業創造條件和提供服務。目前，建設好大學生的就業網站，不僅僅是政府部門應該關心的問題，作為培養大學生的湖南文理學院也有同樣的需求。

解決目前高校就業信息管理中存在的一些問題，如信息傳遞不方便、不快捷，數據分析及就業指導不及時，學生簽約必須到不同部門領表、上交等繁瑣的操作等。通過本系統可以使湖南文理學院畢業生就業信息管理工作更加合理化、科學化，提高工作的效率，從根本上改變就業管理工作的方式，通過internet，各院系和學生利用網絡的便利，可以直接查詢和提交就業信息。在這種系統平臺下，可以快速、有效、全面的反映最新的用人單位信息、畢業生基本信息和就業趨勢，及時提供高校學生工作管理人員對歷屆用人單位需求信息的分析統計，及時有效地調查分析大學畢業生的擇業趨勢和引發的心理問題并進行及時有效的就業指導。可以做到信息的規范管理、科學統計和快速查詢，從而減少管理方面的工作量。

3、項目產品或服務的市場預測

（由于這個系統不是學院的直接收益產品，這里不做分析。）

4、項目的規模和期限

基于學院的實際情況，這個畢業生就業信息可以初步分為三個階段來完成。

第一階段，著重處理學院現有的問題，把系統運行起來，重點放在用戶管理方面，分為用戶注冊、用戶審核和用戶登錄驗證三部分。

第二階段，注重完成學校的就業信息發布，用戶在通過系統注冊后，可以查詢各種信息。

第三階段，系統管理，管理可以對學生用戶和站內信息進行管理。

5、投資估算

具體相信的投資預算，由專業人員進行。這里只能給出對比其他同類學校信息系統的估算，3個階段全部完成，大概需要5萬人民幣。這個估算不包括硬件設備的預算。

6、市場前景及經濟效益初步分析

這個系統雖然不是學院的直接收益產品，但其帶來的間接效益是毋庸置疑。具體可以表現為：

（1）管理決策的科學化。

傳統的決策指示憑經驗的大致的估算，無法采集到大量的數據，也無法對采集到的數據進行精確的分析，而畢業生就業管理系統通過internet，各院系和學生利用網絡的便利，可以直接查詢和提交就業信息，比較全面、及時地采集信息數據、并選定合適的管理模式，做出科學的決策，減少決策失誤。

（2）管理工作的高效化。

在這種系統平臺下，可以快速、有效、全面的反映最新的用人單位信息、畢業生基本信息和就業趨勢，及時提供高校學生工作管理人員對歷屆用人單位需求信息的分析統計，及時有效地調查分析大學畢業生的擇業趨勢和引發的心理問題并進行及時有效的就業指導。

（3）網上就業服務體系的優化。

畢業生的就業指導工作極為薄弱，就業指導教師水平參差不齊，專業的、高素質的就業指導教師太少；缺少優質的就業指導教材。而畢業生就業網絡系統加強了學生擇業的政策咨詢和信息服務，逐步建立起信息服務網絡，為實行網上求職擇業創造條件和提供服務。

（4）網絡資源的充分利用。

指導老師可以開辟“求職顧問”，“就業指導”的板塊，告訴畢業生就業過程中應該注意的問題，幫助學生完善職業形象；了解勞動關系法規；增強自身的保護意識；提高大學生競爭就業意識和能力。

大學生可以利用就業網絡內容豐富、全面的就業信息，最新的國家就業政策和規范，了解國家就業形勢，更新就業觀念，樹立正確職業觀和就業觀。同時，制作個人簡歷，實現網上的自薦求職，查詢自己感興趣用人單位的資料，來了解用人單位的情況。

用人單位可以瀏覽學生所在學校的網站來了解學校的概況及專業設置情況，了解學生專業知識結構和綜合素質，并且通過學校就業網站來核對電子簡歷的誠信度。

（5）畢業生與用人單位的良好溝通

大學生通過查詢自己感興趣用人單位的資料，來了解用人單位的情況。對中意的單位可以投遞電子簡歷。用人單位通過瀏覽學生所在學校的網站，了解畢業生的信息。有意向的雙方可以通過網上面試的方式來進行進一步的溝通，提高學生和用人單位接觸頻率，促進就業工作開展。為企業和學生提供一個交流平臺及更為人性化、個性化的服務。

另外需要注意的是，畢業生就業管理系統的效益一般是無形的，只有經過長期運行后的分析統計才能計算其收益，往往越成熟、科學、優秀的畢業生就業管理系統，帶給我們的效益就越大。畢業生就業水平提高了，學校知名度也會隨之提高，學校的生源也會越來越好。

綜上所述，校方認為建立一個畢業生就業管理系統是非常必要的，請上級領導批示。

7、其他需要說明的問題

隨著計算機科學與技術學院學院人數不斷增加，畢業生的人數也會逐步增長，畢業生就業管理的難度也在不斷加大，所有我們認為建立一個計算機科學與技術學院畢業生就業管理系統是在將來的影響和效益是不可估量。

第五篇：軟件需求分析報告

軟件需求分析

軟件需求分析所要做的工作是深入描述軟件的功能和性能，確定軟件設計的限制和軟件同其它系統元素的接口細節，定義軟件的其它有效性需求。進行需求分析時，應注意一切信息與需求都是站在用戶的角度上。盡量避免分析員的主觀想象，并盡量將分析進度提交給用戶。在不進行直接指導的前提下，讓用戶進行檢查與評價。從而達到需求分析的準確性。分析員通過需求分析，逐步細化對軟件的要求，描述軟件要處理的數據域，并給軟件開發提供一種可轉化為數據設計、結構設計和過程設計的數據和功能表示。在軟件完成后，制定的軟件規格說明還要為評價軟件質量提供依據。

需求分析的任務

開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。目前，國內產品的龐雜，一家企業可能有幾個系統并立運行，它們之間接口是系統開發人員最頭痛的問題。對于商業最終用戶應用程序，企業信息系統和軟件作為一個大系統的一部分的產品是顯而易見的。但是對于我們開發人員來說，并沒有編寫出客戶認可的需求文檔，我們如何知道項目于何時結束？而如果我們不知道什么對客戶來說是重要的，那我們又如何能使客戶感到滿意呢？然而，即便并非出于商業目的的軟件需求也是必須的。例如庫、組件和工具這些供開發小組內部使用的軟件。當然你可能偶爾勿需文檔說明就能與其他人意見較為一致，但更常見的是出現重復返工這種不可避免的后果，而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價，這些血的教訓正在國內的軟件開發者身上發生。近來，我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟件。不幸的是，當他們開發完這個工具后，發現這個工具不能打印出源代碼文件，使用者當然希望有這個功能。結果這個小組只好手工抄寫源代碼文檔以供代碼檢查。這說明那怕需求明確無誤并構思準確，如果我們沒有編寫文檔，軟件達不到期望目標也只能是咎由自取了。相反的情況，我曾見一個要集成到“錯誤跟蹤系統”中的簡單界面寫了一頁需求說明。而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用。他們依據需求對系統進行測試時，此系統不僅非常清晰地實現了所有必需功能，而且未發現任何錯誤。事實上，需求文檔在開發過程中一直起指導作用。需求的類型

下面這些定義是需求工程領域中常見術語的定義。軟件需求包括三個不同的層次：業務需求、用戶需求和功能需求（也包括非功能需求）。1．業務需求（business requirement）反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目視圖與范圍文檔中予以說明。2．用戶需求(user requirement)文檔描述了用戶使用產品必須要完成的任務，這在使用實例（usecase）文檔或方案腳本說明中予以說明。3．功能需求(functional requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。在軟件需求規格說明書（SRS）中說明的功能需求充分描述了軟件系統所應具有的外部行為。軟件需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用。對一個大型系統來說，軟件功能需求也許只是系統需求的一個子集，因為另外一些可能屬于子系統（或軟件部件）。作為功能需求的補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反

映產品功能。多角度描述產品對用戶和開發人員都極為重要。下面以一個字處理程序為例來說明需求的不同種類。業務需求可能是：“用戶能有效地糾正文檔中的拼寫錯誤”，該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器。而對應的用戶需求可能是“找出文檔中的拼寫錯誤并通過一個提供的替換項列表來供選擇替換拼錯的詞”。同時，該拼寫檢查器還有許多功能需求，如找到并高亮度提示錯詞的操作；顯示提供替換詞的對話框以及實現整個文檔范圍的替換。從以上定義可以發現，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。項目也有其它方面的需求，如開發環境需求或發布產品及移植到支撐環境的需求。