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

篇一：軟件需求建議書

醫(yī)院門診管理系統(tǒng)需求建議書

2012年3月26日

有關公司：

現(xiàn)需一個醫(yī)院門診管理系統(tǒng)，要求具有相關項目經(jīng)驗的軟件公司參與競標，要求能對該系統(tǒng)進行合理的編寫，保證系統(tǒng)能夠穩(wěn)定運行，并且在預定時間內(nèi)交付我院使用。

項目目標：

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

1.工作表述

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

(1)系統(tǒng)應使用本院的局域網(wǎng)，win98、win2000、winxp、win7等環(huán)境

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

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

入處方和內(nèi)部資料管理中的醫(yī)師信息的添加。

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

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

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

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

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

交款單。統(tǒng)計患者總人數(shù)和總費用。

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

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

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

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

(9)系統(tǒng)管理功能：其中包括用戶和內(nèi)部人員的修改密碼功能，根據(jù)權

限添加用戶和管理員。數(shù)據(jù)備份功能。

(10)幫助功能：包含醫(yī)院簡介和系統(tǒng)主要實現(xiàn)功能簡介。

2交付實物

（1）必須準備一份詳細的系統(tǒng)設計報告，以及所用到的技術，用以監(jiān)測產(chǎn)品

質(zhì)量。

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

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

（3）在合同預期內(nèi)，交付我院一個能夠運行正常穩(wěn)定的完整的系統(tǒng)。并且在

后期一定時間內(nèi)提供免費維護。

3其他要求

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

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

（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；當本人已經(jīng)滿意于項目的100%，并且承約商已履行了全部契約義務時再付出總額的最后1/3。

申請內(nèi)容

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

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

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

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

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

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

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

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

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

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

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

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

篇二：軟件系統(tǒng)項目建議書完全版

****系統(tǒng)項目建議書

2014年5月

目錄

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

1.1 文檔編寫目的 1.2 系統(tǒng)建設目標與內(nèi)容

1.2.1 系統(tǒng)建設目標 1.2.2 系統(tǒng)建設的主要內(nèi)容

系統(tǒng)設計方案 2.1 總體架構設計

2.1.1 系統(tǒng)總體業(yè)務架構 2.1.2 系統(tǒng)總體軟件架構 2.1.3 系統(tǒng)總體技術架構

2.2 系統(tǒng)組成

2.3 系統(tǒng)數(shù)據(jù)流

系統(tǒng)詳細數(shù)據(jù)流如下圖所示。

2.4 系統(tǒng)功能

系統(tǒng)部署方案 3.1 系統(tǒng)部署架構

表1各子系統(tǒng)部署架構

3.2 系統(tǒng)環(huán)境 篇三：需求建議書

題目：

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

項目：房屋裝修

需求建議書：

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

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

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

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

子。

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

要求：

①、臥室的顏色以暖色調(diào)為主

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

③、衛(wèi)生間隔成兩部分，分為盥洗間和浴室

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

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

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

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

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

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

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

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

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

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

（8）申請書的評價標準

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

2）被指定為執(zhí)行此項目主要負責人的姓名和聯(lián)系方式，以及類似的工作經(jīng)驗（30%）

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

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

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

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

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

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

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

1．工作表述

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

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

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

3．交付物

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

4．客戶供應條款

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

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

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

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

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

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

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

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

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

11．對申請書的評價標準

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

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

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

12．資金總量

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

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

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

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

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

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

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

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

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

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

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

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

1)高優(yōu)先權，表明需求必須體現(xiàn)在本階段項目的成果中或這個產(chǎn)品的版本中。

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

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

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

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

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

1．工作表述

開發(fā)商將執(zhí)行下面任務：開發(fā)項目管理軟件。

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

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

湖南文理學院實驗報告

時間： 2013 年 11 月 18 日

課程名稱： 軟件項目管理

實驗名稱：撰寫畢業(yè)生就業(yè)信息管理系統(tǒng)項目建議書

班級： 姓名： 同組人： 無

指導教師評定： 簽名：

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

二、實驗要求

1、結合模擬項目—畢業(yè)生就業(yè)信息管理系統(tǒng)項目寫出項目建議書。

2、提交畢業(yè)生就業(yè)信息管理系統(tǒng)項目建議書（報告）一份。

三、實驗環(huán)境 1．硬件：計算機 2．操作系統(tǒng)：windows平臺。

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

四、實驗步驟

1、背景介紹

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

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

2、項目的意義和必要性

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

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

3、項目產(chǎn)品或服務的市場預測

（由于這個系統(tǒng)不是學院的直接收益產(chǎn)品，這里不做分析。）

4、項目的規(guī)模和期限

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

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

第二階段，注重完成學校的就業(yè)信息發(fā)布，用戶在通過系統(tǒng)注冊后，可以查詢各種信息。

第三階段，系統(tǒng)管理，管理可以對學生用戶和站內(nèi)信息進行管理。

5、投資估算

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

6、市場前景及經(jīng)濟效益初步分析

這個系統(tǒng)雖然不是學院的直接收益產(chǎn)品，但其帶來的間接效益是毋庸置疑。具體可以表現(xiàn)為：

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

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

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

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

（3）網(wǎng)上就業(yè)服務體系的優(yōu)化。

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

（4）網(wǎng)絡資源的充分利用。

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

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

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

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

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

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

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

7、其他需要說明的問題

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

第二篇：如何寫軟件項目需求說明書

如何寫軟件項目需求說明書

進入軟件開發(fā)行業(yè)也有一段時間了，大大小小項目也接觸了一些，對于怎么寫好項目需求文檔做一下總結，發(fā)表一下自己的看法。1 獲取需求：

作為需求方也就是甲方，通過語言描述或文檔的方式將需求（系統(tǒng)需要提供的功能）提交給開發(fā)人員（需求分析人員）。

獲得需求的方式可以有多種多樣：電話詢問、現(xiàn)場考察、聆聽用戶講解、閱讀用戶編制的相關文件(如招標書)，其實這些方法都是GET方式，我們可以通過以下兩類技術手段來達到：GET(獲取)和PUSH(引導、反饋、激發(fā))相互結合的方式來得到我們真正的需求，而這兩個過程都是必須交互進行的，一般我們可以篩選一名非常有經(jīng)驗(包括談判技巧、深厚的業(yè)務和技術背景、人緣很好、勤奮努力)的人士擔任需求工程師，長期在客戶那里工作。2 需求分析人員

（1）根據(jù)客戶提供的文檔或語言描述，將需求按功能劃分，以用例圖的方式表達系統(tǒng)提供的功能模塊及功能模塊之間的關系，完成用例圖后與客戶確認大的功能模塊，并對每個功能模塊做進一步的溝通詳細記錄用戶所提供的關鍵性的描述，此過程需要系統(tǒng)分析人員對客戶進行引導。

（2）對每個功能模塊進行詳細分析與描述，具體信息包括：用戶角色、功能說描述、IPO的方式進行描述（即輸入項、輸出項、處理）、要提供必要的功能說明，如果使文檔更加直觀，更容易讓客戶理解，可以用UI的方式表達輸入輸出，配合必要的描述，這樣對于客戶更加容易理解，需要與客戶進行大量的溝通確認。

（3）編寫數(shù)據(jù)字典：在需求階段，很難使團隊的思路一致，建立一個合適的機制是完全必要的，這就是數(shù)據(jù)字典，數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項以確保客戶與開發(fā)小組是使用一致的定義和術語。分析和設計工具通常包括數(shù)據(jù)字典組件。

（4）關于文檔具體表述的格式與形式，要根據(jù)所要表達的功能來確定，最重要的是把事情描述清楚,這事最終的目的；

(5)需求文檔確定后，設計人員根據(jù)這份需求文檔進行系統(tǒng)的設計工作了。

第三篇：軟件項目開發(fā)需求報告

軟件需求分析格式_如何寫需求分析報告 軟件需求說明書 1 引言

1.1 編寫目的：闡明編寫需求說明書的目的，指明讀者對象。1.2 項目背景：應包括

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

● 該軟件系統(tǒng)與其他系統(tǒng)的關系。

1.3 定義：列出文檔中所用到的專門術語的定義和縮寫詞的愿文。

1.4 參考資料：可包括

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

● 文檔所引用的資料、規(guī)范等

● 列出這些資料的作者、標題、編號、發(fā)表日期、出版單位或資料來源 2 任務概述 2.1 目標 2.2 運行環(huán)境 2.3 條件與限制 3 數(shù)據(jù)描述 3.1 表態(tài)數(shù)據(jù)

3.2 動態(tài)數(shù)據(jù)：包括輸入數(shù)據(jù)和輸出數(shù)據(jù)。3.3 數(shù)據(jù)庫描述：給出使用數(shù)據(jù)庫的名稱和類型。3.4 數(shù)據(jù)詞典 3.5 數(shù)據(jù)采集 4 功能需求 4.1功能劃分 4.2功能描述 5 性能需求 5.1 數(shù)據(jù)精確度

5.2 時間特性：如響應時間、更新處理時間、數(shù)據(jù)轉換與傳輸時間、運行時間等。

5.3 適應性：在操作方式、運行環(huán)境、與其他軟件的接口以及開發(fā)計劃等發(fā)生變化時，應具有的適應能力。6 運行需求

6.1 用戶界面：如屏幕格式、報表格式、菜單格式、輸入輸出時間等。6.2 硬件接口 6.3 軟件接口 6.4 故障處理 7 其他需求

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

需求分析的格式 需求分析要對目標系統(tǒng)提出完整的、準確的、清晰的和具體的要求。

1．綜合需求： 項目 說明 備注

1）功能要求 描述軟件用來做什么

能夠進行度量衡的相互轉換，如：長度公制之間的轉換，公制和英制的轉換等。能夠添加或創(chuàng)建新的度量衡。能夠按照用戶自己的需要進行排序。能夠作為其他軟件的插件或輔助工具使用。能夠知道度量衡所應用的范圍，如：國家，行業(yè)等。

2）性能要求 軟件能達到什么性能

數(shù)據(jù)的最大存儲量，數(shù)據(jù)的轉換要有連續(xù)性，軟件對每項操作的響應時間，更新處理時間，數(shù)據(jù)轉換和傳送時間，軟件的輸入輸出數(shù)據(jù)精度，軟件失敗和成功的定義。

3）運行要求

軟件能正常運行在微軟中文版WINDOWS系列的可以獨立運行的安裝包或可執(zhí)行文件

開發(fā)軟件的開發(fā)工具清單。是否需要外部存儲器和數(shù)據(jù)通信接口。

4）升級要求

是否可以升級，是否可以進行擴充。是否容易進行維護。能夠作為什么軟件的插件或輔助工具使用。如何添加新的公式

5）對應關系

用戶需求和軟件功能的對應關系 說明每一個模塊對應實現(xiàn)什么功能。

2．數(shù)據(jù)要求： 項目 說明 備注

1）數(shù)據(jù)輸入

來源、準確性、取值范圍、格式、非法值的處理、出錯信息

2）數(shù)據(jù)輸出 目的地、準確性、數(shù)值范圍、格式、非法值的處理、出錯信息

輸出的數(shù)據(jù)可以修改，如：1米=100厘米=1000毫米，將100厘米改為90厘米時，相應的1米就自動改為0.9米，1000毫米變?yōu)?00毫米。

3）數(shù)據(jù)存儲 最大存儲量

4）數(shù)據(jù)的安全性 訪問的權限

5）數(shù)據(jù)備份 能否導入和導出

可以將輸出的數(shù)據(jù)保存為文本格式

6）數(shù)據(jù)流圖

在分析過程中得出的數(shù)據(jù)流圖

7）數(shù)據(jù)篩選

能夠將選擇的幾個度量單位進行匯總

8）主要算法

簡要描述軟件的主要算法

3．界面要求：請參照“界面樣式圖” 項目 說明 備注

1）軟件名稱 為軟件起一個名字 可以發(fā)揮自己的想象力

2）功能模塊

有幾個功能模塊，分別是什么

3）顏色

采用什么底色，窗口是什么顏色

4）字體

字型、大小，字間距，顏色

5）按鈕

顏色、字型、大小、樣式

4．軟件描述：從用戶的角度來描述軟件，相當于一份初步的用戶手冊。項目 說明 備注

1）功能描述

能實現(xiàn)，不能實現(xiàn)什么需求 應用范圍。什么人員可以使用

2）性能描述

最低配置，操作系統(tǒng)，需要安裝什么輔助軟件

3）操作步驟 如何使用軟件 主要步驟和方法

4）用戶責任

用戶在操作過程中的注意事項 出現(xiàn)問題時如何解決 如何寫需求分析報告

近來學校的一些科研項目又在申報了，一些學弟開始Q我一些軟件工程上書面的問題。大概的總結了下，寫到這里。本文涉及到的是需求分析部分的書寫，主要是根據(jù)國家標準文檔中的要求來的。

在互聯(lián)網(wǎng)公司或者一些敏捷開發(fā)的公司里，其實大家都是秉承著重開發(fā)，重討論，而輕文檔的態(tài)度。這個輕文檔并不是指沒有文檔或者幾乎不做文檔，而是在嚴格的文檔流程中解脫出來，只把最最實際的部分寫出來。這個特征是有互聯(lián)網(wǎng)本身迭代周期短，版本發(fā)布快等特點決定的。而在實際的兼職項目的時候，同學們就要注意了，最重要的應該就是在簽合同的時候一定要附上最清楚的一份需求分析，雖然這份需求說明可能不是按照某些標準文檔而來的，描述清楚每個功能達到的效果，而這個效果一定要讓客戶點頭確認，而不能出現(xiàn)“應該是”、“可能是”、“也許是”這樣的模糊回答。否則在項目后期就會比較難過了。在學校申請的項目和大型公司項目開發(fā)中，是重視文檔流程的，一部一部來。所以還是看情況來對待文檔的深度和標準。

一、目錄： 目錄要用word的 “引用”—>”目錄”，自動生成目錄，一般都是要三級目錄。通常這部分基本都不需要改結構，直接更新頁碼即可。

二、內(nèi)容部分。國家標準軟件需求說明書G856T-88下載 1引言 1.1編寫目的

說明編寫這份軟件需求說明書的目的，指出預期的讀者。（這部分說明需求分析報告的概況，例如：本X需求分析報告是為S系統(tǒng)而編寫的。+S系統(tǒng)的兩句話概述。+本X報告旨在使U1（需求者）明確S系統(tǒng)的要求和細節(jié)，給U2(開發(fā)人員)了解需求實現(xiàn)的難度和困難，最終提供給U3（審核人、管理者）討論和審核，達到溝通效果）

1.2背景 說明：

a． 待開發(fā)的軟件系統(tǒng)的名稱； b． 本項目的任務提出者、開發(fā)者、用戶及實現(xiàn)該軟件的計算中心或計算機網(wǎng)絡；

c． 該軟件系統(tǒng)同其他系統(tǒng)或其他機構的基本的相互來往關系。

（這部分可以將a,b,c分為2部分，例子如下： 1.2.1項目概況

本需求分析報告所預期開發(fā)的軟件系統(tǒng)是:S。S是（不是則無）SS系統(tǒng)的某一個功能子模塊，S和S1、S2等系統(tǒng)之間的聯(lián)系，以及概述其他系統(tǒng)的狀態(tài)等等。1.2.2任務分配

a.任務提出者：xxx b.軟件開發(fā)者：xx c.產(chǎn)品使用者：xx d.文檔編寫者：xx e.預期產(chǎn)品使用者：xx）1.3定義

列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。

（這部分很簡單，就是描述專業(yè)詞匯，比如

1.XML(Extensible Markup Language)即可擴展標記語言,它與HTML一樣,都是SGML(Standard Generalized Markup Language,標準通用標記語言)。2.Word2, 解釋。。）

1.4參考資料

列出用得著的參考資料，如：

a． 本項目的經(jīng)核準的計劃任務書或合同、上級機關的批文； b． 屬于本項目的其他已發(fā)表的文件；

c． 本文件中各處引用的文件、資料、包括所要用到的軟件開發(fā)標準。列出這些文件資料的標題、文件編號、發(fā)表日期和出版單位，說明能夠得到這些文件資料的來源。2任務概述 2.1目標

敘述該項軟件開發(fā)的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發(fā)的背景材料。解釋被開發(fā)軟件與其他有關軟件之間的關系。如果本軟件產(chǎn)品是一項獨立的軟件，而且全部內(nèi)容自含，則說明這一點。如果所定義的產(chǎn)品是一個更大的系統(tǒng)的一個組成部分，則應說明本產(chǎn)品與該系統(tǒng)中其他各組成部分之間的關系，為此可使用一張方框圖來說明該系統(tǒng)的組成和本產(chǎn)品同其他各部分的聯(lián)系和接口。|（本模塊開發(fā)主要是為SS的整體服務，完成SS工作中的XX部分以及相關的工作。其涉及的范圍就是，從下達A、B命令后，到給出C結果的過程。具體描述：B1，來完成B11功能；B2，來完成B22功能； 等等。本部分是（否）耦合在分詞工具包其他部分中的，主要為嵌入方式和先后方式相互交互。圖

圖1.該系統(tǒng)的組成同其他各部分的聯(lián)系和接口）

2.2用戶的特點

列出本軟件的最終用戶的特點，充分說明操作人員、維護人員的教育水平和技術專長，以及本軟件的預期使甩頻度。這些是軟件設計工作的重要約束

（例如：二次開發(fā)和系統(tǒng)調(diào)用人員：具有很高的專業(yè)知識水平，理解XX的運行機制。可以對開放代碼進行閱讀和分析，以完成其系統(tǒng)獨特的需求，提供給這部分用戶開放API手冊和Debug版本的源代碼即可；預期這部分用戶會占本系統(tǒng)總用戶量的多大部分。

xx使用者：具有一定的計算機操作能力和知識，了解xx領域的相關概念和用途。提供給這部分用戶操作手冊即可。預期這部分使用者主要是來簡單的xx操作。

維護人員：具有較高的計算機專業(yè)水平，可以對常見的系統(tǒng)Bug進行追蹤和分析，具有一定的測試能力。這部分用戶主要是采用了本系統(tǒng)之后的后期工作維護者。等等）

2.3假定和約束

列出進行本軟件開發(fā)工作的假定和約束，例如經(jīng)費限制、開發(fā)期限等。（這部分重要是對你有的技術力量、資金狀況、人力資源等情況的假設，以使得你可以在什么樣的情況和時間范圍內(nèi)完成工作。工期約束，經(jīng)費約束，人員約束，地理約束，設備約束等幾個方面列舉說明。）3需求規(guī)定 3.1對功能的規(guī)定

用列表的方式（例如IPO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟件所提出的功能要求，說明輸入什么量、經(jīng)怎樣的處理、得到什么輸出，說明軟件應支持的終端數(shù)和應支持的并行操作的用戶數(shù)。（例如： INPUT輸入 PROCESS處理 OUTPUT輸出 LOAD負載量

A 預處理,做怎樣的動作，AA CC B BBBB Bb v C CCCC cc v

表

一、xx模塊IPO表 對IPO表的簡單文字描述。）

3.2對性能的規(guī)定 3.2.1精度

說明對該軟件的輸入、輸出數(shù)據(jù)精度的要求，可能包括傳輸過程中的精度。（例如：

Xx目標處理：1Byt–10M，包括左右邊界值。yy精度范圍：?.ZZ的精度：由于xx的特殊性，本系統(tǒng)均采用xx型來進行字符統(tǒng)計運算，概率部分以及其他比率部分精度精確到0.0x%。）

3.2.2時間特性要求

說明對于該軟件的時間特性要求，如對： a． 響應時間； b． 更新處理時間；

c． 數(shù)據(jù)的轉換和傳送時間； d． 解題時間；等的要求。(這部分只要一一列舉就可以：

由于xxx過程中，需要大量xxxx操作或怎樣，故xx解題時間占總時間的最大部分。其次就是xx轉換和存儲的開銷。其具體時間特性要求，如下： a． xx響應時間：xxms左右； b． yy更新處理時間：yy；

c． zz數(shù)據(jù)的轉換和傳送時間：zz； d． vv解題時間：vv。等等)3.2.3靈活性

說明對該軟件的靈活性的要求，即當需求發(fā)生某些變化時，該軟件對這些變化的適應能力，如： a． 操作方式上的變化； b． 運行環(huán)境的變化；

c． 同其他軟件的接口的變化； d． 精度和有效時限的變化； e． 計劃的變化或改進。

對于為了提供這些靈活性而進行的專門設計的部分應該加以標明。

（這部分按列舉來即可，由于本模塊第一目的是用于xxx，其次則是xxxx。故本模塊的靈活性在于實際應用者的不同。當需求發(fā)生某些變化時，該軟件對這些變化的適應能力。具體情況如下： f． 操作方式上的變化：采用集成運行制和獨立運行制兩種模式，集成運行制是把本模塊嵌入到分詞工具包的主框架中，提供給用戶具有一定UI的可操作軟件；獨立運行制是可以獨立運行于后臺，并提供給各種程序調(diào)用的模式的工作方式，以增強其生命力。

g． 運行環(huán)境的變化：主采用Windows平臺的編譯版本運行和調(diào)試，在時間允許的情況下，同步開發(fā)支持SUSE Linux的服務器版本。；

h． 同其他軟件的接口的變化：在盡量保證接口不出現(xiàn)變動的情況下，允許接口的重載和再定義。但接口的命名規(guī)則是統(tǒng)一的；

i． 精度和有效時限的變化：精度在必須調(diào)整的條件下，可以上下浮動10個百分點；有效時限則依據(jù)現(xiàn)實的測試情況允許稍大范圍的變化。

j． 計劃的變化或改進：工作時間安排會存在必然的浮動，這部分要協(xié)同分詞工具包課題設計組其他成員一同來進行商定，前期的計劃可以稍微有些變動，后期的安排盡量按照計劃執(zhí)行。等等）3.3輸人輸出要求

解釋各輸入輸出數(shù)據(jù)類型，并逐項說明其媒體、格式、數(shù)值范圍、精度等。對軟件的數(shù)據(jù)輸出及必須標明的控制輸出量進行解釋并舉例，包括對硬拷貝報告（正常結果輸出、狀態(tài)輸出及異常輸出）以及圖形或顯示報告的描述。

（這部分可以把輸入輸出分為 3.3.1輸入要求和3.3.2輸出要求，如下給出一個單元的例子。XXX輸出

數(shù)據(jù)名稱：XXX輸出數(shù)據(jù) 實際含義：用于XX,表示XXXX 數(shù)據(jù)類型：Character(字符串)數(shù)據(jù)格式：XX 數(shù)據(jù)約束：由于xxx,，大小在xx以內(nèi)）

3.4數(shù)據(jù)管理能力要求

說明需要管理的文卷和記錄的個數(shù)、表和文卷的大小規(guī)模，要按可預見的增長對數(shù)據(jù)及其分量的存儲要求作出估算。（根據(jù)實際系統(tǒng)要求列舉即可 Name名稱 Number數(shù)量 Size大小 Increase增長

詞典xx xx xxxx 并行執(zhí)行，其大小依據(jù)實際xx大文本而增長）

3.5故障處理要求

列出可能的軟件、硬件故障以及對各項性能而言所產(chǎn)生的后果和對故障處理的要求。

（包括軟件壓力，內(nèi)存不足，硬件損壞等，這部分可以根據(jù)百度到其常見故障。）3.6其他專門要求

如用戶單位對安全保密的要求，對使用方便的要求，對可維護性、可補充性、易讀性、可靠性、運行環(huán)境可轉換性的特殊要求等。

（例如安全保密性：密鑰更換等； 預期擴展：擴展兼容等；OS更換：Slackware轉SUSE等）

4運行環(huán)境規(guī)定 4.1設備

列出運行該軟件所需要的硬設備。說明其中的新型設備及其專門功能，包括：

a． 處理器型號及內(nèi)存容量；

b． 外存容量、聯(lián)機或脫機、媒體及其存儲格式，設備的型號及數(shù)量；

c． 輸入及輸出設備的型號和數(shù)量，聯(lián)機或脫機； d． 數(shù)據(jù)通信設備的型號和數(shù)量； e． 功能鍵及其他專用硬件（列舉說明即可）4.2支持軟件

列出支持軟件,包括要用到的操作系統(tǒng)、編譯（或匯編）程序、測試支持軟件等。（操作系統(tǒng)和版本：xxxx 支撐環(huán)境和版本：xxxx 備用IDE環(huán)境和版本：xxxx 與該軟件有關的軟件組件：xxxx 后續(xù)可能擴展環(huán)境：xxxx）4.3接口

說明該軟件同其他軟件之間的接口、數(shù)據(jù)通信協(xié)議等。(例如：

a．用戶和主程序調(diào)用接口(圖中接口1)。這個接口采用封裝API形式和函數(shù)調(diào)用形式，分別以外部調(diào)用和內(nèi)部調(diào)用的方式為不同用戶提供使用本機械分詞工具的入口。例如以xxxx方式調(diào)用DLL文件，以xxxx方式調(diào)用函數(shù)。如下圖2所示。圖2.軟件接口調(diào)用圖 b.xx接口(圖中接口2)。這里是一個xxx的接口調(diào)用過程。xxxx)4.4控制

說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源。(例如：

下面通過圖表的形式，將本模塊以及涉及到本模塊的軟件模塊的運行方法、控制信號，以及這些控制信號的來源，其中箭頭所指方向對應的模塊的控制信號來自箭頭另一方向的模塊，具體情況如下： 圖3.控制流程圖

圖3的具體說明情況如下表所示： Name模塊名稱 Method運行方式 Signal控制信號 Forward控制去向

主程序模塊 運行框架 用戶調(diào)用或運行 1.調(diào)用xx模塊 2.調(diào)用xx方法 3.調(diào)用標準輸出模塊

xxx模塊 xxx xxx調(diào)用 Xxx模塊)

第四篇：軟件項目需求分析總結

軟件項目需求分析總結

我們做的需求只解決了我們能做出這樣的項目，但是沒有解決這樣的項目是不是真就是客戶想要的。造成這種狀況的原因主要是下面幾個情況：

客戶本身說不清楚

文物網(wǎng)是這樣，中彰國際更是這樣，但是這不能怪客戶，畢竟客戶在軟件方面的知識要少的多，也沒有相關的經(jīng)驗，可能心里只有一個想要的軟件的輪廓，于是可能會要求我們?nèi)ヌ嫠麄儊硗暾@個輪廓的細節(jié)，而我們的能力、我們能否真正站在客戶角度去搜集和整理這些需求，就決定了這個需求的完整性和有效性。

需求自身經(jīng)常變動

隨著客戶對這個項目越來越深刻的理解，那么可能他的需求也會隨之改變，這些變化的可能性越大項目風險就會越大，我們在需求分析的時候就要充分考慮到哪些需求是相對固定的需求，哪些可能會是產(chǎn)生變動的需求，考慮到他的可變性，這樣設計功能和數(shù)據(jù)庫的時候不致因為后面的變動而影響整個工程。分析人員或客戶理解有誤

畢竟，不是每個分析人員都是專業(yè)而合格的，為避免這種情況的發(fā)生，需求分析必須要有審核制度，公司自己內(nèi)部要審核一遍，客戶再審一遍，提出意見，修改后雙方共同評審簽字，確認。

由此出現(xiàn)的問題：

a)需求分析過于籠統(tǒng)，只關注到面上，沒有關注到點上，開發(fā)出來的東西在具體的細節(jié)上和客戶的理解有誤差，并且無法嚴格界定是否屬于需求變更。中彰的方案就是這樣的。

b)需求報告只求我們這方評審通過，不去關心客戶的評審，認為只要客戶簽字認可就行。雖然簽字認可能夠給日后出現(xiàn)問題時劃清我們的責任，但是不能保證使項目實施成功。

c)需求分析中含有技術實施上有難度的功能，一味的求全和盲目按照客戶的設想，受客戶影響過大，畢竟，很多時候，客戶的想法在實際實施過程中是不現(xiàn)實的，或者可以有更為簡便的方法來替代的。如中彰國際的在線交易功能，后臺大批量郵件群發(fā)功能。

d)對雙方已經(jīng)確定的需求，實現(xiàn)以后并不適合客戶使用，需要按照變更手續(xù)執(zhí)行的時候，客戶可能會糾纏，提出“你們是專業(yè)人士，你們應該事先能提醒我們可能會出現(xiàn)這種問題”并以此來把責任推給我們，而我們又不好完全按照變更手續(xù)執(zhí)行，因為可能激化雙方的矛盾，比如508的批量處理功能，因為屬于人事

管理比較專業(yè)的細節(jié)問題，需求分析師開始沒有對客戶業(yè)務熟悉到如此細致的地步，而客戶也沒有過多關注這些細節(jié)，導致軟件的某些功能不合用，較為繁瑣，而重新按著客戶的意見修改的話工作量比較大，導致成本增加、工期延長。e)項目的成熟度受客戶預算的限制。大部分客戶在項目投入上都是有預算的，在成本有上限的前提下，項目的功能設計(軟件的成熟度)方面必然受一定影響，畢竟功能越多越完善，相應的開發(fā)成本就越高。這種功能上的不完善需要事先告知客戶并得到理解。

f)此項工作的反復造成思想上的倦怠，使需求分析最后虎頭蛇尾。需求分析是一項繁瑣枯燥的工作，需要和客戶之間不斷的商討、確認和反復，另外由于大部分的客戶雖然安排專人負責這項工作，但是該人并不只做這項工作，特別當他被很多其他的事情纏身的時候，而無心細看提交過去的需求報告的時候，他很可能會給你一個錯覺，讓你認為他已經(jīng)真正的理解并認可了你的設計。結論

a)需求分析是整個項目管理中需要重點控制的幾個關鍵節(jié)點之一，首先思想上一定要重視。

b)需求分析報告的編寫者要參與到需求的搜集工作中，準確領會客戶的意圖，并轉化成軟件能夠實現(xiàn)的功能。對于說不清楚需求的客戶，要善于問關鍵問題，引導客戶提出自己的需求。可以采取的措施是事先編制一個問卷調(diào)查之類的文檔，詳細列舉需要客戶回答的問題，以便防止遺漏。

c)需求報告的編寫者要能夠對客戶需求進行深入分析，區(qū)別出哪些需求存在日后變更的可能，哪些需求屬于相對固定的，哪些需求能夠實現(xiàn)，哪些需求需要變通才能實現(xiàn)，以便于指導后面的功能設計。

d)需求分析報告對功能細節(jié)的描述不能有歧義，描述一定要全面、準確，防止開發(fā)方和客戶只見對同一個問題有兩個截然不同的理解。可以通過評審，用大家的力量來避免這種情況發(fā)生

e)需求報告的每個關乎功能的描述都要讓客戶明白和理解，客戶在理解之上的確認才能夠保證日后一旦出現(xiàn)問題不致出現(xiàn)雙方互相推托責任糾纏不清的情況。

f)需求報告一定要經(jīng)過一個有技術人員和業(yè)務人員參加的評審，要充分發(fā)揮團隊的力量，重視每個人的才智，一個模塊一個功能的逐一的過，讓大家來共同找出需求報告里不合理的、有歧義的、不完善的、遺漏的等等問題g)幫助客戶去理解提交給他的需求分析報告而不是只等簽字，對于有能夠用好幾種方式實現(xiàn)的功能，盡量做到能讓客戶去比較和選擇。不要讓客戶對報告中的部分產(chǎn)生歧義。只有客戶對報告的完全的理解，才能在日后客戶提出的修改被認為是需求變更的時候能夠得到客戶的理解

h)最后，需求分析報告一定要雙方共同簽字確認

第五篇：軟件項目需求調(diào)研總結

軟件項目需求調(diào)研總結

一、需求調(diào)研準備：

在需求調(diào)研過程中，應該做好三種準備，保持兩種心態(tài)，做到五種提高：

三種準備

1）調(diào)研前應該將所有項目前期資料進行匯總，與相關的前期銷售人員進行交流，以便對項目有一個基本輪廓的認識。

2）做好調(diào)研前使用資料的準備，如需求調(diào)研模板，需求調(diào)研問題列表等。

3）做好不怕一切困難的準備。

兩種心態(tài)

1）保持一種和客戶平等合作的心態(tài)，確定需求調(diào)研是為了給客戶解決問題，探討問題，而不是接受問題，更不是來指導工作的。

2）平靜面對需求變更的心態(tài)，在需求調(diào)研過程中，往往雙方對需求理解不一致，造成需求調(diào)研前后矛盾，應當心平氣和的去引導客戶，達到需求理解基本一致。

三種提高

1）首先提高自己業(yè)務知識，對于人力資源的標準業(yè)務應該基本熟悉。

2）其次應該努力的去熟悉用戶的行業(yè)，學習用戶使用的術語，標準，以便能夠準確的理解用戶。這就需要我們閱讀用戶所在行業(yè)的資料、文章，盡量多選取一些整體性介紹的文章，這樣可以在短時間內(nèi)能夠對該行業(yè)有一個全面的認識，這樣我們就能夠較好的和用戶進行交流了。

3）需求調(diào)研中，學會盡量不使用IT行業(yè)的術語，而采用淺顯易懂的口頭語言來解釋IT行業(yè)中高深莫測的術語，以便用戶能夠很好的理解，提高自己的溝通交流能力。

4）提高自己的速記能力，文字表述能力以及歸納，能迅速的記錄需求調(diào)研核心的問題，總結歸納形成原始的需求調(diào)研資料。

5）提高自己的總結能力，書寫一份完整的、前后一致的、可追蹤的需求報告。

二、需求調(diào)研過程的總體流程

需求調(diào)研中應遵循一定的流程，而且在調(diào)研過程中表現(xiàn)出規(guī)范，調(diào)研有條不紊，對客戶有理有據(jù)，調(diào)研中資料做好備份，做到有備無患：

三、需求調(diào)研過程中注意問題

四、需求報告書寫要求及標準

編寫優(yōu)秀的需求是沒有公式化的方法的。這需要大量的經(jīng)驗，要從你在過去的文檔中發(fā)現(xiàn)的問題學習。請在組織軟件需求文檔時，嚴格遵從這些方針。

句子和段落要簡練。使用正確的語法，拼寫，標點。使用術語，要保持一致性，并在術語表或數(shù)據(jù)字典中定義它們需求編寫者還要努力正確地把握粒度。多個需求盡可能拆分開。

整個需求文檔細節(jié)上要保持一致。

避免在需求報告中過多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會給文檔的維護增加困難。文檔的多份文本要在同一時間內(nèi)全部更新，避免不一致性。

需求調(diào)研對于系統(tǒng)的構造，系統(tǒng)測試以及最后的客戶滿意，都會成為好的奠基石。并且要記住，沒有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠不知道你會得到什么。我希望我們能得到一塊“德芙”。

調(diào)研概要情況：X項目需求調(diào)研開始于2006-3-23結束于2006-6-15，內(nèi)容包括現(xiàn)場需求調(diào)研4個人月和分析需求編寫需求文檔6個人月。參與調(diào)研的包括項目經(jīng)理、技術經(jīng)理和兩個開發(fā)骨干，編寫需求規(guī)格說明書字數(shù)95.4萬。

1.把二期項目當作一個新項目來做調(diào)研，避免需求細節(jié)遺漏。在調(diào)研的初期我們曾經(jīng)有過疑慮，這是一個二期的項目，那么調(diào)研的內(nèi)容是否只針對二期的新需求，對需求內(nèi)容二期和一期一致的部分就不必調(diào)研了?

經(jīng)過討論我們還是決定把二期項目當作一個新項目來做調(diào)研，即使二期和一期需求內(nèi)容一致，我們也在調(diào)研會上討論，并記錄在調(diào)研筆記及以后的需求文檔上。這樣的好處是最大限度地避免了需求細節(jié)的遺漏。在現(xiàn)場調(diào)研時，發(fā)現(xiàn)有不少地方原來以為是二期不必修改的，經(jīng)過討論后發(fā)現(xiàn)還是需要修改。（往往危險的需求描述就在于“這部分做的和某個系統(tǒng)或某個版本的舊系統(tǒng)一樣就可以了”）

2.調(diào)研團隊參加所有子系統(tǒng)的調(diào)研會議，可以相互補充避免需求遺漏。這個項目規(guī)模比較大，根據(jù)業(yè)務的類型不同，分成了6個子系統(tǒng)，各個子系統(tǒng)的業(yè)務信息互有接口。我們安排每個人至少負責一個子系統(tǒng)的需求，但是在調(diào)研時，只要可能，我們都盡量讓每個人都參與所有系統(tǒng)的調(diào)研會議。對項目經(jīng)理和技術經(jīng)理則進一步要求了解所有系統(tǒng)的業(yè)務需求。這樣做的好處是，對于子系統(tǒng)之間的業(yè)務關系，調(diào)研團隊都可以有全面的了解，對業(yè)務的理解比較透徹全面，并且還可以相互補充遺漏。

3.多人調(diào)研，在會議后應該立刻回顧整理統(tǒng)一的會議筆記，消除歧義，避免遺漏。在開調(diào)研會時，全體與會人員都各自記自己的會議筆記，會后沒有強調(diào)當天整理會議筆記（會議進度很緊，每天開會到晚上8、9點鐘）。這導致以后閱讀會議筆記發(fā)現(xiàn)一些描述很簡單理解上有歧義的內(nèi)容，或者同一份需求在幾個筆記上記錄的內(nèi)容細節(jié)上有差異，事后難以追溯正確的信息。給編寫需求文檔帶來了一些困難，需要再次討論需求。

4.需求文檔編寫完成后，在開發(fā)階段也應該做檢查和更新，避免文檔錯誤對開發(fā)的誤導。我們在完成大量的需求文檔編寫工作后，在開發(fā)階段有部分文檔沒有做內(nèi)容檢查和及時更新。后期測試時才發(fā)現(xiàn)少數(shù)需求內(nèi)容的矛盾和錯誤，導致需要重新修改。

建議：

1、如果在編寫需求文檔后，開發(fā)階段應該做一邊閱讀需求文檔，一邊做需求文檔的檢查，對于保證需求質(zhì)量效果會更好。

2、應該指定人負責需求追蹤和更新，在開發(fā)階段、測試階段要保持和用戶的需求溝通，這不是一個可有可無的簡單工作，很重要，并且會占用責任人50%的工作時間。

3、企業(yè)業(yè)務管理信息系統(tǒng)的需求調(diào)研方法：我認為對調(diào)研的組織安排是非常重要的，好的調(diào)研安排雖然未必產(chǎn)生質(zhì)量高的需求，但是一個不遵循調(diào)研規(guī)律的調(diào)研活動，必然是低效的。下面是H項目調(diào)研組采取的調(diào)研流程，供參考：

4、第一步不是立刻和用戶當面討論需求細節(jié)，而是要業(yè)務關鍵用戶編寫初步的需求報告，提供給開發(fā)團隊閱讀分析。需求報告的內(nèi)容是，對業(yè)務流程的描述，對業(yè)務需求的描述。需求報告的質(zhì)量往往和關鍵用戶的投入多少有較大關系，經(jīng)常在沒有面對面溝通時，關鍵用戶未必能對這份報告投入很多的時間和精力。但這是當面調(diào)研的基礎，一定要做，有粗糙疏漏的地方可以再現(xiàn)場調(diào)研時再細化。這可以再調(diào)研前就和用戶溝通，讓用戶編寫。