第一篇：項目開發規范報告

項目開發報告

一、報告的目的

通過反映此次項目開發中各層面存在的問題，以及對項目開發中造成的影響，來反映項目開發中規范化的必要性，以及開發文檔的重要性。規范化軟件開發流程控制是為了使整個軟件產品在開發各個階段清晰、要求明確、任務具體，便于規范化、系統化及工程化，利于提高軟件生命周期的控制及管理，提高所開發軟件的質量，縮短開發時間，減少開發和維護的費用，使軟件開發活動更科學、更成效。

二、存在的問題

1.委托開發合同上的不足：

1）開發合同上本次項目開發的要求不明確。一般項目開發前應確認包括項目目標和技術方案。項目目標是指項目應達到業務需求、項目目的、以及解決什么樣的問題；技術方案是指描述開發軟件的主要技術內容，可以以附件的形式詳細描述技術方案，并作為合同的組成部分。

2）沒有明確的開發計劃說明、每個階段需要提交文檔及代碼以及驗收標準（測試文檔）。開發計劃一般要包含如下內容：需求分析階段，設計實現階段，初驗階段，試運行階段，終驗階段，質保期階段（維護）。

3）合同雙方就此次軟件開發中的分工界面不明確，不能清晰界定雙方的責權利。分工界面是指甲乙雙方在此次項目開發過程中各自扮演的角色，以及在整個開發中的具體工作界定。如：委托方提供需求文檔等相關資料，開發方制定開發規范、詳細開發計劃、以及開發里程碑，甲乙雙方成立項目負責組監管開發過程等。

4）項目開發交付內容不明確。就試運行標準沒有達成共識，一般試運行應該是在委托方收到開發方出具的項目初驗報告以后，根據初驗報告驗收標準判斷是否達到試運行標準后，再同意試運行才是試運行的標志。

5）驗收內容和標準不詳，沒有一套完整的驗收流程。在整個項目開發中各個階段最好都要由開發方提起申請，委托方給予答復這樣一個流程來監管和規范項目的開發，使項目能穩定規范的進行。

6）最終交付產品和版權不明確。注明是否需要源代碼以及說明版權歸屬方。

2.開發流程上的缺陷

1）項目開發各個階段都應該有完整的開發計劃和開發流程。為了保證項目在開發過程中不至于無序而使開發陷入混亂甚至僵死的狀態，明確各階段的任務、標準和流程是相當重要的。

2）首先要由項目負責人制定項目開發計劃。在項目計劃中要對項目的目標和時間要求給出明確的定義，要規定項目的組織和管理規則，項目的開發過程和輸出要求，項目對資源的需求和分配等。

3）由項目負責人要組織編寫《XXX系統開發規范》（此規范可以在項目開發過程中進行完善，但是必須雙方認可），其中包括：

a.闡述項目采用的技術路線； b.c.采用的軟件開發方法和使用的軟件輔助開發工具；

制定需求分析階段，設計階段，編程階段中文檔編寫規則，模型表示規則，命名約定等在開發過程中需協調一致的規則。

4）需求分析階段：需求分析員應通過各種方式收集和獲得所開發項目的業務需求，并對獲取的需求和系統應具有的隱含需求進行分析，以建立系統的軟件需求。必須編寫《軟件需求說明書》，最好編寫初步的《系統指南》。該《軟件需求說明書》得到用戶確認后，需提交評審。

5）概要設計階段：系統設計員應建立一個高層的軟件體系結構，該體系結構應體現系統的需求。該體系結構應描述軟件的頂層結構和定義其主要部分。必須編寫《概要設計說明書》和《數據庫設計說明書》，最后修改完善《系統指南》并將《概要設計說明書》和《數據庫設計說明書》提交評審。

6）詳細設計階段：系統設計人員要深刻理解《概要設計說明書》，保證詳細設計與概要設計相一致，為編碼提供詳盡的依據。細化和描述每一個功能模塊，確定實現各個模塊功能的具體算法、內部數據結構和外部接口方式。若功能模塊涉及到用戶界面，還要具體描繪出用戶界面以及操作流程。必須編寫《詳細設計說明書》，最后修改完善《系統指南》并提交詳細設計評審。

7）設計實現階段：程序員應嚴格按照詳細設計的說明，保證最終程序與詳細設計相一致。編碼過程中應遵循《XXX系統開發規范》的命名規則和注釋等規定保證程序的清晰、易讀。要對編寫的程序進行調試，使程序不僅通過編譯的語法檢查，而且在功能和性能等方面達到設計的要求。必須編寫《用戶操作手冊》，最后修改《系統指南》。由系統設計員最終完成《系統指南》。

8）內部測試階段：項目負責人應組織系統的內部測試，內部測試由項目組內包括單元測試，集成測試和構造測試。項目組內的測試員負責編寫系統內部測試的《測試計劃》和《測試實例》，實施測試，填寫《測試報告》。最后由測試部提供支持。

9）系統測試階段：項目負責人應向測試部提請系統測試。測試部負責編寫系統測試的《測試計劃》，《測試實例》，實施測試，填寫《測試報告》。由項目測試員提供配合。10）初驗階段：驗收小組需要根據驗收內容逐項進行相關驗收。軟件功能的驗收：由軟件使用部門根據需求或驗收內容和標準，對軟件系統功能進行詳細驗證測試，驗收小組監督和匯總測試情況。軟件性能的驗收：由信息技術部從技術的角度，對系統進行性能等技術測試，驗收小組監督和匯總測試情況。開發資料文檔的驗收：由驗收小組根據驗收準備階段的要求逐項核對資料的提交情況，資料包括合同中要求的程序源代碼、操作手冊、培訓資料、測試報告、過程數據等。最后驗收小組將根據綜合評議情況，判斷是否驗收合格，對于不合格的部分提出整改意見。如果本次驗收通過，驗收小組將檢驗初步驗收涉及的各階段驗收是否完成，如果初步驗收完成，將進入正式運行階段； 11）終驗階段：當系統運行一段時間（一般在合同中明確）后，驗收小組將匯總各使用部門的驗證情況或驗收小組組織全面的驗收，將根據驗收情況出具驗收結論。不合格則提出整改意見，合格則進入最后報告總結。驗收小組將根據驗收情況撰寫驗收報告，驗收報告不僅需要包括本次項目驗收的情況總結，也需要總結本次驗收工作的得與失。最后領導審批，歸檔。

3.人員的缺失（需要有明確的工作職責為整個項目負責）：

1）項目負責人：負責制訂《項目計劃》、協調項目內外各方的關系、控制項目進度并保證項目計劃的實施和完成。2）需求分析員：作為開發方的代表，負責溝通用戶和開發人員的認識和見解，明確及準確地編寫《軟件需求說明書》和初步的《系統指南》。

3）系統設計員：負責把軟件需求變換成可表示的可實現的軟件形式，為設計實現提供可行的依據。并在設計過程中要負責編寫《概要設計說明書》、《數據庫設計說明書》、《詳細設計說明書》，完成《系統指南》的編寫。

4）程序員：按設計要求把軟件的詳細設計變換成可執行的源程序，進行調試。完成相應的文檔，編寫《用戶操作手冊》。5）測試人員：負責制定測試計劃，設計測試方案，測試用例，并實施測試。

6）配置管理人員：負責對開發庫中軟件配置項的管理和維護。

7）監管人員：開發雙方包括客戶方負責整個開發項目過程中各個階段的規范和督導。

4．標準規范的缺失（主要體現在需求文檔里面，下面幾點不是所有項目都有，可以根據項目的規模范圍來調整）：

1）功能需求：描述軟件系統必須實現的業務流程（使用實例），以及根據每個業務流程分解出來的詳細的功能需求。2）性能需求：軟件性能需求通常包括以下方面：

i.同時支持的最大用戶數、同時支持操作的個數、某時刻能承受的最大數據量、數據最大存儲量、對系統運行時允許占用的系統資源要求；

ii.系統持續運行時間、響應時間、數據更新處理時間、數據間的轉換和傳輸時間、界面刷新處理時間的要求； iii.在不同安裝/運行環境、不同操作方式下，或者與其它子系統接口發生改變時，某些數據和參數可以允許的變化范圍。

3）系統安全：說明與系統安全性、完整性和保密性相關的需求，明確產品必須滿足的安全保密策略。

4）質量要求：可靠性（軟件能夠無故障的運行一段時間的概率）、可維護性（對軟件進行修改的難易程度——修改所用時間、修復的比率）、有效性（軟件正常運行時間/總時間）、可用性（掌握軟件操作的難易程度）、重用性、可測試性（查找缺陷的難易程度）、可移植性等。

5）安全和保密：說明與系統安全性、完整性和保密性相關的需求，明確產品必須滿足的安全保密策略。

6）需求變更：需要有變更控制，版本控制，需求跟蹤，狀態跟蹤等規范，明確產品的基線、復審對基線的變更、最后批準、否決變更或延期執行的控制。

7）網絡要求：描述與本軟件所使用的通信功能相關的需求。電子郵件、Web 瀏覽器、網絡通信標準或協議及電子表格等等。包括對消息格式、通信安全或加密問題、數據傳輸速率和同步通信機制等要求。

8）接口要求：對本軟件與其它系統軟件的每個接口進行描述，包括軟件之間的交換數據或信息及其作用（注意說明哪些是共享數據）、需要的服務、內部通信性質。9）其他要求：安裝與操作，維護等。

5.需求變更管理的不足：

需求調研分析過程是一個由粗到細、漸進明晰、持續完善的過程。在指導后面系統設計，編碼階段時都應當不斷完善修改需求文檔，因此需求管理非常重要。需求管理包括在工程進展過程中維持需求約定集成型和精確性的所有活動：

（1）定義需求基線（需求文檔的主體）；

（2）評審提出的需求變更申請、評估每項變更可能的影響，從而決定是否實施變更；

（3）以一種可控的方式將需求變更融入到項目中；（4）使當前的項目計劃與需求保持一致；

（5）分析變更所產生的影響并在此基礎上協商出新的約定；（6）使每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤；

（7）在整個項目過程中跟蹤需求狀態及其變更情況。

6.開發文檔和報告的缺失（不一定全部都需要可以根據實際開發來調整）: 因為沒有指明負責人，所以各個階段沒有形成申請、報告、匯報和變更等文檔。沒有數據庫數據字典文檔，沒有測試計劃文檔，沒有驗收文檔等。一般文檔應該包括(因項目開發的不同部分文檔可以沒有)：《XXX系統開發規范》《軟件需求說明書》《概要設計說明書》《數據庫設計說明書》《詳細設計說明書》《系統指南》《用戶操作手冊》

三、軟件開發的重點

一個軟件開發項目的進行，一般需要在人力和自動化資源等方面作重大的投資。為了保證項目開發的順利進行與成功，最經濟地花費這些投資，并且便于運行和維護，在開發工作的每一個階段都需要編制一定的文檔。這些文檔連同計算機程序及數據一起才算是構成整個計算機的軟件。文檔的作用是相當重要的，是整個開發流程中規范化進行的重要保障。文檔還有其他很多作用：

1）作為開發人員在一定階段內的工作成果和結束標

志。

2）向管理人員提供軟件開發過程中的進展和情況，把軟件開發過程中的一些“不可見的”事物轉 換成“可見的”文字資料。以便管理人員在各個階段檢查開發計劃的實施進展，使之能夠判斷原定目標是 否已達到，還將繼續耗用資源的種類和數量。

3）記錄開發過程中的技術信息，便于協調以后的軟

件開發、使用和修改；

4）提供對軟件的有關運行、維護和培訓的信息，便

于管理人員、開發人員、操作人員和用戶之間相互了解彼此的工作； 5）向潛在用戶報導軟件的功能和性能，使他們能判

定該軟件能否服務于自己的需要。

另外文檔模板有很多可以根據開發項目的總體要求來選擇合適的文檔制定要求來規范文檔，使在整個開發中能更好的詮釋項目，保障項目的順利進行。

四、關于績效考核軟件開發的匯報

開發人員在整個開發過程中盡職盡責，經常加班，為整個項目開發盡了全力。項目開發中出現了一些問題，導致開發延后，其中最主要的原因有兩點：第一，項目開發過程中客戶方因為工作人事的變動，調整了績效考核負責人，從而在項目功能上的需求變動比較大，而且客戶方在細節功能需求上一直沒有一個明確的定性要求。第二，項目從開始制定實施以來，沒有完善的一套開發流程控制計劃，最重要的是在合同上的很多不足，使整個開發沒有可控性和規范化。雖然經過開發人員一段時間的努力，最終完成了整個項目的開發，但是由于各個文檔的不足，軟件還有些不足的地方，在今后的客戶試用中還會出現一些問題，可以讓開發方負責整改。為了以后更多軟件項目能更高效，順利的進展，希望能有自己的監管部門或者人員參與到整個項目中來，從頭到尾的協助開發人員進行項目規范化進行，監管、申請、審批、文檔都是必不可少的部分。

第二篇：附錄H項目開發總結報告規范

附錄 H項目開發總結報告規范

對項目開發的整個過程以及經驗和教訓等方面進行概括和總結，從而為今后的項目開發工作提供重要參考。

1.引言

1.1編寫目的說明編寫項目開發總結報告的目的，指出預期的讀者對象。

1.2背景

闡明本項目的名稱和所開發出來的軟件系統的名稱。說明項目的來源或任務提出者、開發者、用戶。

1.3定義

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

1.4 參考資料

列出要用到的參考資料，如：

?本項目的已核準的計劃任務書或合同、上級機關的批文。

?屬于本項目的其他已發表的文件。

?本文件中各處所引用的文件、資料，包括所要用到的軟件開發標準。列出這些文件的標題、文件編號、發表日期和出版單位,說明能夠得到這些文件資料的來源。

?本報告引用的其他資料、采用的開象標準或開發規范。

2-實際開發結果

2.1產品

說明最終制成的產品,包括：

?程序系統中各個程序的名字，它們之間的層次關系，源程序行數（包括注釋行）以千字節為單位的各個程序的程序量，存儲媒體的形式和數量。

?程序系統共有哪幾個版本，各自的版本號及它們之間的區別。

?產品文檔名稱

?所建立的每個數據庫。如果開發中制定過配置管理計劃，要同這個計劃相比較。

2.2主要功能和性能

逐項列出本軟件產品所實際具有的主要功能和性能，對照可行性研究報告、項目開發計劃、功能需求說明書的有關內容，說明原定的開發目標是達到了、未完全達到或超過了。

2.3基本流程

用圖給出本程序系統的實際的基本的處理流程。

2.4進度

列出原定的進度與使勁進度的對比，明確說明實際進度是提前了，還是延遲了，分析主要原因。

2.5費用

列出原地計劃費用與實際支出得用的對比，包括：

?工時，以人月為單位，并按不同級別統計。

?計算機的使用時間，區別cpu時間及其他設備時間。

?物料消耗、出差費等其他支出。

?明確說明經費是超出了，還是節余了，分析主要原因。

2.6所用工時

按人員的不同層次分別計時。

2.7所用機時

按所用計算機機型分別計時。

3.開發工作評價

3.1對生產效率的評價

給出實際生產效率，包括：

?程序的平均生產效率，即每人月生產的行數。

?文件的平均生產效率，即每人月生產的簽字千字數。

?并列出原定計劃數作為對比。

3.2對產品質量的評價

說明在測試中檢查出來的程序編制中的錯誤發生率，即沒千條指令（或語句）中的錯誤指令數（或語句數）。如果開發中制定過質量保證計劃或配置管理計劃，要同這些計劃相比較。3.3對技術方法的評價

給出堆在開發中所使用的技術、方法、工具、手段的評價。.經驗與教訓

列出從這項開發工作中所得到的最主要的經驗與教訓及對今后的項目開發工作的建議。

第三篇：農業綜合開發項目內業規范

農業綜合開發項目內業規范

1、農開項目可研報告、實施計劃等相關資料；

2、農開項目上報省市項目相關文件；

3、農開項目批復、變更、調整文件；

4、土地治理項目區示意圖、規劃圖、竣工圖；

5、土地治理項目井、橋等水利工程卡片；

6、產業化項目建設前的圖片或影像資料，項目竣工驗收后的圖片或影像資料；

7、產業化貸款貼息項目企業申報的利息支出單復印件；

8、產業化貸款貼息項目銀行貸款合同、借款借據復印件；

9、農業綜合開發財政補助項目資金輔助備查賬；

10、農開項目全部招投標資料（包括招投書、全部投標單位的投標書、評標資料等），競爭性談判資料或詢價資料；

11、農開項目全部合同及協議（包括施工合同、采購合同、勘察設計合同、監理合同、技術咨詢服務合同、科技推廣服務合同等）；

12、農開項目工程施工資料，包括施工圖、竣工圖、工程簽證、工程索賠及工程價款結算資料；

13、土地治理項目林業措施、科技措施的全部資料；

14、土地治理項目監理資料；

15、農開項目竣工決算資料、驗收資料及項目移交資料；

16、土地治理項目投勞折資臺賬等相關資料；

17、上級農發機構竣工項目驗收及審計提出的整改意見落實情況；

18、項目實施及資金使用的財務資料，包括報賬手續、賬簿、憑證及明細表和銀行對賬單等；

19、上級單位下達的資金計劃文件、縣級財政安排配套資金 的文件；

20、當及當年科目匯總表（至最末級科目的發生額及余額）；

21、當年自驗報告及驗收材料匯編；

22、當年簡報及在國家、省、市新聞媒體發表和播出的資料；

23、當年開發圖片（或版面、或錄像）；

第四篇：如何規范農業綜合開發項目工程招投標

如何規范農業綜合開發項目工程招投標

近幾年來，各地農業開發系統認真貫徹國家招標投標有關政策、法規，農業綜合開發項目工程招投標工作不斷完善。但由于國家對農業綜合開發項目工程招投標工作沒有系統、可操作的規定；加之，具體從事此項工作的同志沒有經過系統培訓，對招投標有關政策、法規理解不全、不深，知識陳舊、老化，在具體工作中不規范現象時有發生。本文根據國家有關政策、法規，就規范農發項目工程招投標工作做一些探討。

關于招標代理

目前，在農發工程招標代理中存在的問題：一是縣級招標中心或采購中心強制指定代理；二是代理費支付不合規，由中標單位支付。

根據《中華人民共和國招標投標法》（下稱《招標投標法》）第12條規定：“招標人自行選擇招標代理機構，委托其辦理招標事宜。任何單位和個人不得以任何方式為招標人指定招標代理機構。招標人具有編制招標文件和組織評標能力的，可以自行辦理招標事宜。任何單位和個人不得強制其委托招標代理機構辦理招標事宜。依法必須進行招標的項目，招標人自行辦理招標事宜的，應當向有關行政監察部門備案。”《工程建設項目自行招標試行辦法》（國家發展計劃委員會第5令）第4條規定：“招標人自行辦理招標事宜，應當具有編制招標文件和組織評標的能力，具體包括：1.具有項目法人資格（或者法人資格）；2.具有與招標項目規模和復雜程度相適應的工程技術、概預算、財務和工程管理等方面專業技術力量；3.有從事同類工程建設項目招標的經驗；4.設有專門的招標機構或者擁有3名以上專職招標業務人員；5.熟悉和掌握招標投標法及有關法規規章。”從上述規定可知，只要具備上述規定能力的縣級農發部門完全可以自行組織農發項目工程招標。即使不能組織的，其他任何單位和個人也不得以任何方式為農發項目工程招標指定招標代理機構。按照國家發展計劃委員會制訂的《招標代理服務收費管理暫行辦法》（計價格【2002】1980號）第10條規定，招標代理服務實行“誰委托、誰付費”，農發項目工程招標代理費應由農發部門在管理費中列支。

關于工程標段劃分

標段劃分合理與否直接影響到工程建設成本、進度乃至質量，同時也與施工單位的施工成本息息相關。目前，農發項目工程招標標段劃分存在的問題主要有兩個：一是標段劃分過于細小。雖然能夠吸引眾多投標人投標，保證工期，但不便于施工管理。二是標段劃分人為化。在同一個縣內標段劃分標準不統一。有時以投資額大小劃分標段，有時以項目鄉鎮劃分標段，有時以工程類型劃分標段。如甲項目鄉鎮投資在100萬元左右，則所有工程劃為一個標段；乙項目鄉鎮投資在300萬元左右，有的則再按村劃分標段，有的則按工程類型劃分標段。

根據目前農發項目工程建設實際情況，從節約工程投資、保證工期和工程質量、便于施工管理角度出發，在標段劃分時，應綜合考慮投資額、工程地點、工程類型、工期要求和潛在投標人等因素，以項目鄉鎮或跨鄉鎮連片為單位，按照工程類別劃分標段，每一標段估算

金額在150萬元左右為宜，而且全縣應該統一劃分標準。既可使工程地點相對集中，又可使合同金額適中，有助于吸引更多的承包商參與競爭，提高競爭性招標的經濟性，同時也有利于合同的實施與管理。如果每個項目鄉鎮投資都在150萬元左右的，且工程類型差別不的，一個項目鄉鎮就可以劃分一個標段，但如果工程類型差別大的，在一個項目鄉鎮內可以分為兩個標段，與相鄰鄉鎮的同類工程劃分為一個標段。如果單個項目鄉鎮投資在500萬元以上的，應該考慮以工程類型劃分標段，排灌站、防滲渠及其配套建筑物、低壓灌溉、噴滴灌、道路、其它配套建筑物可分別劃分為一個標段，如某一標段過小、應與相鄰鄉鎮的同類工程劃分為一個標段。

關于投標人資格要求及審查方式

投標人資格要求主要包括兩個方面：一是投標人的法律地位，二是投標人的專業技術能力。對投標人的資格要求應適當，既不能過高也不能過低。資格要求過高，會讓多數中小型承包商失去競爭機會，導致招標的競爭性下降；資格要求過低，將無法保證工程的建設標準和施工質量。目前，在農發項目工程招標中，有的地方過分強調要求投標單位必須具備水利水電資質三級以上才能投標。由于大多數縣具有水利水電資質三級的施工企業只有一個，結果造成借資質投標，有資質單位中標后再將工程分包、轉包給鄉鎮水利站或其他施工單位施工（雖然招標文件規定不允許分包、轉包），收取5-10%的管理費。鑒于農發工程絕大部分是技術要求不高的小型農田水利工程，在進行這類性質工程招標時，應主要考慮投標人的專業技術水平、施工機械配備及施工經驗等情況，《水利工程建設項目招標投標管理規定》(2001年水利部令第14號)第26條也規定：“投標人必須具備水利工程建設項目所需的資質（資格）。”因此，應該允許具有農田水利工程施工能力、且有一定農田水利工程施工經驗的非水利水電施工資質三級以上(含三級)的施工企業參予農發工程招標投標；同時，考慮到農發工程施工地點分散，與農戶協調矛盾多，對具有一定實力并能夠滿足招標工程建設要求的鄉鎮水利站也允許參予投標。

資格審查有預審和后審兩種方式。凡是大型復雜的土建工程、大型成套復雜設備或特殊服務，在正式組織招標之前一般進行資格預審。雖然審查投標人的投標資格是招標人的一項權利，但由于資格審查的結果直接導致潛在投標人或預選中標人投標或中標權利的得失，因此，如果招標人濫用這一權利，將會直接侵害潛在投標人的合法權益，影響招標的公開、公平、公正，從而違背了招標交易的本性。從法律上講，農發工程招標完全可以進行資格預審，但問題是目前有的地方限制或排斥潛在投標人，對潛在投標人實行歧視待遇等現象時常發生。如有的不公開資格預審程序或標準，或沒有嚴格執行資格預審程序、方法、原則等一系列要求，暗箱操作，僅是經辦人員看一看資格材料或資質證書等，或者請幾個人打一打分就決定誰資格預審合格、誰不合格；有的甚至規定一個潛在投標人只能購買一個標段或部分標段標書；有的在招標預審文件中規定對本地的潛在投標人和其它地區的投標人適用不同的資格評審標準，造成對其它地區投標人的歧視待遇，使投標人公平競爭的權利難以得到保護。這些都是招標人濫用資格審查權的表現，嚴重違反招標投標法的基本原則，不利于形成充分競爭的市場環境，結果是每個標段投標人都是3-4個。從國際上看，世界銀行不鼓勵資格預審，擔心通過預審的投標人串通，或是招標人有意排斥潛在投標人。因此，為了減少腐敗產生，考慮到農發工程大多是技術不復雜的小型工程，我們認為招標時不必進行資格預審，重

點是把好資格后審關，在開標后對投標人的資格進行詳細審查。如果進行資格前審的，則要嚴格按照國家有規定執行，而不能簡單、輕易地下結論。

關于招標文件編制

招標文件是招標投標活動中最重要的法律文件。其編制得好，不但可以降低投標報價，而且可以保證工期和質量。如果編制漏洞百出，不但會給招標、評標和簽訂合同造成困難，而且還有可能使項目單位或投標人蒙受經濟損失。因此，必須十分重視招標文件的編寫工作。目前，農發工程招標文件編制存在的問題：一是使用的商務部分范本不統一。有的使用水利水電的，有的使用工民建的，有的使用世界銀行的，有的甚至是幾個范本的拼湊；二是技術規格、技術規范不明確，或制定得不全面，圖紙深度不夠，工程量清單不實。

針對上述問題，一是全面推行使用國家制定的范本。2007年，國家發展和改革委員會、財政部、建設部、鐵道部、交通部、信息產業部、水利部、民用航空總局、廣播電影電視總局聯合編制了《標準施工招標資格預審文件》和《標準施工招標文件》（2007年國家發展和改革委員會令第56號）并要求兩個《標準文件》自2008年5月1日起在政府投資項目中試行。農發項目作為政府投資項目應該優先使用該范本，既符合規范，又減少了工作量。二是加強工程設計，做實工程量清單。所有工程設計圖紙都必須達到施工圖階段要求，除較大工程可實行二階段設計外，一般工程要設計一次性達到施工圖水準。對于工程結構相對復雜、投資額比較高的工程應采取單座工程設計（即一座工程一套圖紙），如排灌站、中溝以上橋梁、水閘等。采用定型（典型）工程設計時，設計圖紙上要注明適用地形、地質情況，標注變化部位的尺寸范圍，同時要列出不同規格工程的工作量。

關于評標方法

評標方法選擇和確定既要考慮到公平公正，又要考慮招標工程的具體情況。它是招標的關鍵。如果評標方法不科學合理，則其它一切都是形式。目前，農發工程招標評標中存在的問題：一是采用的方法不統一，叫法也是“五花八門”。有的是綜合評分法，有的叫綜合評估法，有的采用最低評標價法，有的叫經評審的最低投標價法，有的叫合理低價法，有的說復合標底法等等。二是評標標準和方法不公開，沒有在招標文件中詳細載明評標標準和方法。三是評標時，人為因素大。有的把投標人投標時承諾的工程優良、提前完成工期都作為加分因素，甚至還采用已被國家禁止的把獲得本地區、本系統獎項作為加分條件或中標條件。

關于評標辦法，《中華人民共和國招標投標法》沒有作出具體規定，只是第41條提出了中標條件：“中標人的投標應當符合下列條件之一：1.能夠最大限度地滿足招標文件中規定的各項綜合評價標準；2.能夠滿足招標文件的實質性要求，并且經評審的投標價格最低；但是投標價格低于成本的除外。”從2001年7月5日起施行的，由 國家發展計劃委員會、建設部、水利部制定的《評標委員會和評標方法暫行規定》（第12號令）第29條對評標辦法作了明確規定：“評標方法包括經評審的最低投標價法、綜合評估法或者法律、行政法律允許的其他評標方法。”第30條規定：“經評審的最低投標價法一般適用于具有通用技術、性能標準或者招標人對其技術、性能沒有特殊要求的招標項目。”雖然《水利工程建設項目招標投標管理規定》第35條規定：“評標方法可采用綜合評分法、綜合最低評標價法、合理最低投標價法、綜合評議法及兩階段評標法。”但由于此規定是水利部一個部門制定的，法律效力明顯低于三個部委制定的《評標委員會和評標方法暫行規定》因此，我們認為目前比較規范的評標辦法應該是兩種，即經評審的最低投標價法、綜合評估法。從實際來看，我們在實施利用世行貸款加強灌溉農業二、三期項目中，無論國際、國內貨物招標，還是國內小型土建工程招標、貨物詢價采購，都采用最低評標價法（相當于經評審的最低投標價法），都取得了令人滿意的效果。因此，農發工程招標評標應該全部采用經評審的最低投標價法，而且按《標準施工招標文件》第三章要求詳細說明。

經評審的最低投標價并不一定是最低投標價。只有在技術和商務部分完全滿足招標文件要求，對招標文件中的條款、條件及技術規格無實質性偏離或保留情況下，最低投標價才是經評審的最低投標價。經評審的最低投標價也不是按照社會平均成本計算的合理低價，而是投標人的理性報價。該辦法抓住了招標的核心，符合市場經濟競爭法則，能夠充分發揮市場機制的作用，而且減少了評標的工作量，最大限度減少了評標工作中的人為因素，有利于促進投標人提高管理水平和工藝水平，降低生產成本。

很多人認為經評審的最低投標價中標必然不能保證質量，投標價越高，工程質量越好。其實，質量與管理密切相關，而與價格沒有必然的聯系。追求利潤最大化是投標人的天性。誠然，合理的利潤是保證質量的前提，但有合理的利潤甚至是高額利潤卻并不一定能保證質量。報價與工程質量有關系，但沒有必然關系。質量是嚴格管理和監督出來的。市場經濟成熟的歐美國家都是采用最低評標價法評標，但其工程質量卻很好，這與嚴格的工程監管分不開的。反觀，近年來，我國工程建設領域不斷發生的質量事故，以血的教訓告訴我們，沒有嚴格的管理和監督，價格再高，也不能保證質量。因此，不只是在招標環節，而是在整個采購過程中，都要圍繞項目質量管理這個中心，落實措施，強化責任，使質量管理落到實處。

關于標底

目前，在農發工程招投標工作中，一方面過于夸大標底在評標中的作用，不僅要求每個標段都編制標底，在綜合評分法中還計算出復合標底，而且往往以高于或底于標底一定幅度作為廢標的理由；另一方面，標底編制不規范。往往由縣農業開發局業務人員編制，既不夠科學合理，又難以保密。

《招標投標法》第22條規定：“招標人設有標底的，標底必須保密。”第40條規定：“評標時，設有標底的，應當參考標底。”《工程建設項目施工招標投標辦法》第34條規定：“招標人可根據項目特點決定是否編制標底。編制標底的，標底編制過程和標底必須保密。招標項目編制標底的，應根據批準的初步設計、投資概算，依據有關計價辦法，參照有關工程定額，結合市場供求狀況，綜合考慮投資、工期和質量等方面的因素合理確定。標底由招標人自行編制或委托中介機構編制。一個工程只能編制一個標底。任何單位和個人不得強制招標人編制或報審標底，或干預其確定標底。招標項目可以不設標底，進行無標底招標。”

第55條規定：“招標人設有標底的，標底在評標中應當作為參考，但不得作為評標的唯一依據。”因此，從法律上講，農發工程由于施工技術要求不高，完全可以進行無標底招標，而且在評標時特別是采用綜合評估法評標時，不能輕率地以高于或底于標底一定幅度作為廢標的理由。至于標底何時公布，法規未作具體規定，但按照第56號令要求，在開標時公布，并在開標記錄上注明。

關于中標人確定

目前，在農發工程招標中標人確定過程中，存在最大的問題是所謂“中一不中二”，即當一個投標人經評審后中了2個以上標段時，招標人以所謂的“中一不中二”理由，或者以建設部《關于加強房屋建筑和市政基礎設施工程項目施工招標投標行政監督工作的若干意見》（建市【2005】208號）“一個項目經理（建造師）只宜擔任一個施工項目的管理工作”（2001年規定每個項目經理原則上不得同時負責兩個以上工程項目的管理）為理由，讓中標人只能中一個標。這種做法明顯與公開招標的本質相違背，也不符合國家有關招投標法律、法規。作為在同一個鄉鎮內的兩個標段的農發工程，一個項目經理完全可以勝任兩個標段管理工作，而且可以降低施工成本。

其次，對中招人確定方式存在誤區。有人認為評標委員會只能推薦第一、二、三名中標候選人，不能最終確定中標人，中標人只能由縣級農發部門確立。其實，《評標委員會和評標方法暫行規定》第48條和《工程建設項目施工招標投標辦法》第58條都明確規定，確定中標人既可以是招標人，也可以由招標人授權評標委員會直接確定中標人。

第三，在評標委員會依法推薦的中標候選人以外確定中標人。這是違反國家招投標法的。法律規定此種情況下，中標無效，并處以罰款，對單位直接負責的主管人員和直接責任人依法給予處分。

關于招投標中幾個費用管理

目前，在農發工程招標中，幾個費用管理存在以下問題：一是招標文件售價太高，大大超過編制成本，有的甚至以營利為目的，影響了合格投標人的投標積極性。二是要求投標保證金提交金額過高或過低，而且退還時間不符合要求，有的在未簽訂合同就退還未中標人保證金，有的則超過投標保證金有效期才退還。三是要求履約保金提交金額過高或過低，有的未提交就簽訂合同。四是在中標人未提供預付款保函情況下，農發部門支付預付款。

根據國家有關規定，招標文件售價不能過高，應只反應其印刷和遞交給預期投標人的成本。投標保金一般不得超過投標總價的2%，但最高不得超過80萬元。由于以報價的一定比例作為投標保證金額有可能會導致泄漏報價，因此，較理想的辦法是規定固定的投標保證金金額。投標保證金可采用現金、支票、銀行匯票，也可以是銀行出具的銀行保函、不可撤銷信用證。投標保證金的有效期應當超過投標有效期30天。當與中標人簽訂合同后5個工作日，應當向未中標和中標的投標人退還其保證金。投標人在規定的投標有效期內撤銷或修改其投標文件投標保證金將不予退還。中標通知書發出后，中標人放棄中標項目的，無正當理由不簽訂合同的，在簽訂合同時提出附加條件或更改合同實質性內容的，或拒不提交履約保金的，可取消中標資格，并沒收投標保證金，給招標人的損失超過投標保證金數額的，對超過部分予以賠償。履約保證金是履約擔保的一種，是招標人要求投標人在接到中標通知后，提交的保證履行合同各項義務的擔保。其目的是為了保護業主的利益，避免或減輕由于中標商違約而給業主造成的損失。履約保證金保證的期限一般到合同規定的維修期結束。提交方式及金額一般有以下兩種：一種是用信用證或銀行保函或現金方式提交者，其履約保證金為合同價的10%；另一種是用擔保書提交的履約保證金為合同價的30%。以上兩種，投標人可任選一種。中標人拒絕提交的，視為放棄中標項目。不履行合同的，履約保證金不予退回，給招標人的損失超過其數額的，對超過部分予以賠償。在中標人未提供預付款保函情況下，不得支付預款。

關于法律責任

在目前農發工程招投標中，違反國家政策、法規的事時有發生，但大家都沒有依法辦事，聽之任之，以致一錯再錯。

比如保密問題，《招標投標法》第52條規定：招標人向他人透露已獲取招標文件的潛在投標人的名稱、數量或者可能影響公平競爭的有關招標投標的其他情況的，或者泄露標底的，給予警告，可以并處1萬元以上10萬元以下的罰款；對單位直接負責的主管人員和其他直接責任人員依法給予處分；構成犯罪的，依法追究刑事責任。其行為影響中標結果的，中標無效。

如借資質投標問題，第54條規定：投標人以他人名義投標或者以其他方式弄虛作假，騙取中標的，中標無效，給招標人造成損失的，依法承擔賠償責任；構成犯罪的，依法追究刑事責任。

又如串標問題，第53條規定：投標人相互串通投標或者與招標人串通投標的，投標人以向招標人或者評標委員會成員行賄的手段謀取中標的，中標無效，處中標項目金額千分之五以上千分之十以下的罰款，對單位直接負責的主管人員和其他直接責任人員處單位罰款數額百分之五以上百分之十以下的罰款；有違法所得的，并處沒收違法所得；情節嚴重的，取消其一年至二年內參加依法必須進行招標的項目的投標資格并予以公告，直至由工商行政管理機關吊銷營業執照；構成犯罪的，依法追究刑事責任。給他人造成損失的，依法承擔賠償責任。

再如非法轉包、分包問題，第58條作了明確的處罰規定。

關于行政監督和行政監察

目前，在農發項目工程招投標中，行政監督和行政監察明顯不到位，在開標時雖然邀請人大、政協、紀檢、監察、公證部門人員參加，但各自監督的范圍、職責都不清楚，無法實施監督。根據我國有關法律、法規規定，行使農發工程招投標行政監督權的應該是招標投標行政主管部門，行使農發工程招投標行政監察權的應該是農發行政監察部門。上級農發行政監察部門可以指導和督查下級行政監察部門的招標投標行政監察工作。目前，由于缺乏有關農發項目工程招投標行政監察具體規定，各地農發項目招標投標行政監察工作無法規范開展，因此，建議國家盡快出臺農發項目工程招投標行政監察具體辦法。在目前情況下，農發行政監察部門可以對招標投標活動進行全過程監察，也可以對重要環節和關鍵程序進行現場監察，并加強與招標投標行政主管部門的溝通，保證農發項目工程招投標工作規范開展。

第五篇：軟件項目開發需求報告

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

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

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

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

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

1.4 參考資料：可包括

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

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

● 列出這些資料的作者、標題、編號、發表日期、出版單位或資料來源 2 任務概述 2.1 目標 2.2 運行環境 2.3 條件與限制 3 數據描述 3.1 表態數據

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

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

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

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

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

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

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

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

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

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

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

3）運行要求

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

開發軟件的開發工具清單。是否需要外部存儲器和數據通信接口。

4）升級要求

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

5）對應關系

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

2．數據要求： 項目 說明 備注

1）數據輸入

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

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

輸出的數據可以修改，如：1米=100厘米=1000毫米，將100厘米改為90厘米時，相應的1米就自動改為0.9米，1000毫米變為900毫米。

3）數據存儲 最大存儲量

4）數據的安全性 訪問的權限

5）數據備份 能否導入和導出

可以將輸出的數據保存為文本格式

6）數據流圖

在分析過程中得出的數據流圖

7）數據篩選

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

8）主要算法

簡要描述軟件的主要算法

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

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

2）功能模塊

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

3）顏色

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

4）字體

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

5）按鈕

顏色、字型、大小、樣式

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

1）功能描述

能實現，不能實現什么需求 應用范圍。什么人員可以使用

2）性能描述

最低配置，操作系統，需要安裝什么輔助軟件

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

4）用戶責任

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

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

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

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

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

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

1.2背景 說明：

a． 待開發的軟件系統的名稱； b． 本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；

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

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

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

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

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

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

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

1.4參考資料

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

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

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

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

圖1.該系統的組成同其他各部分的聯系和接口）

2.2用戶的特點

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

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

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

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

2.3假定和約束

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

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

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

表

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

3.2對性能的規定 3.2.1精度

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

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

3.2.2時間特性要求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4數據管理能力要求

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

詞典xx xx xxxx 并行執行，其大小依據實際xx大文本而增長）

3.5故障處理要求

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

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

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

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

4運行環境規定 4.1設備

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

a． 處理器型號及內存容量；

b． 外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量；

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

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

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

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

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

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

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

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

xxx模塊 xxx xxx調用 Xxx模塊)