需求分析調研報告 篇1
1、對投標人的要求
投標人必須認真閱讀以下內容，以免造成投標失敗。
1）投標人必須保證所提供的產品貨真價實，所有產品均提交原始設備生產廠商證明。
2）設標人對招標人提出的需親自到現場解決的問題能保障4小時內的回響，諮詢應及時相應。
3）投標人應本著認真負責的態度組織技術隊伍，並做好投標的整體方案並提出長期保修、維護、服務以及今後技術支持的措施計畫和承諾。
4）自系統建設工作一開始，投標人就應允許招標人的工作人員參與系統的安裝、測試、診斷及解決問題等各項工作。
5）投標人必須提供系統建設的工作內容、工作日程表，日程表內容至少應包括到貨日期、驗貨日期、驗貨人員、現場安裝、系統聯調、系統試運行、集成驗收、套用系統運行、技術培訓等。
6）投標人必須保證有能力進行對設備（套用系統、材料）生產廠商的簽約、督導和工作協調。
7）投標人應對滿足規定指標的設備及軟體供貨商的在資信和信譽進行認真考核並對招標人負責。
8）投標人應將招標人標書中所有設備、軟體。及與有關生產廠商簽約和有關技術合作、維護、服務等檔案以副本形式提供給招標人以份。
9）投標人應負責在項目完成時將系統的'全部有關技術檔案、資料及測試、驗收報告等文檔匯集成冊交付招標人。
10）投標人應對招標人標書中所列內容全部驗收後方為該項目的建設工作完成。
11）投標人和產品供貨商對提供的產品保證的技術支持售後服務，保證的產品免費維修服務。
2、對於投標書的要求
1）投標人必須滿足標書的要求，否則投標人的投標書將被拒絕並認作沒有回答。
2）投標人必須審閱相關技術手冊以便準備投標檔案和技術部分，提供一個準確的陳述。對每個單項產品，投標人必須提供原廠商的正式技術指標說明材料。
3）在投標書中建議的每個硬體和軟體的型號部件逐一說明。
4）投標人的投標檔案需將技術部分和商務部分嚴格分離，分別封裝，否則將可能影響評價結果。
3、對招標書的說明
1）投標人須提供詳細外網建設方案。
2）必須按招標人提供的網路設備、軟體、連線件進行設計。若有特殊情況無法滿足系統方案及系統運行要求的，投標人應主動提出來，並以書面的形式告知招標人，待招標人確認後才進行修改。
需求分析調研報告 篇2
一、引言
1.1編寫目的對產品或項目進行定義，包括修正或發行版本號。如果這個軟體需求規格說明只與整個系統的一部分有關係，那么只定義文檔中要說明的部分或子系統。
1.2背景說明
說明項目或模組開發背景。
1.3預期讀者和閱讀建議
列舉軟體需求規格說明書所針對的不同讀者，如用戶、設計人員、編程人員、測試人員、項目經理、市場人員等。指出最適合於每一類型讀者閱讀文檔的建議。
1.4術語定義
解釋需求說明書中的術語、名詞、簡稱及縮寫等等。
1.5參考文獻
列出所有參考資料、參照的軟體名稱，包括標題名稱、作者、版本號、日期、出版單位或資料來源，以方便讀者查閱這些文獻。
二、任務概述
2.1目標
描述項目或業務模組要達到的目標。
2.2用戶特點
描述主要的用戶及其特點（教育水平、經驗、計算機水平等）。確定可能使用該產品的不同用戶類別並描述它們的特徵。有些需求可能只與特定的用戶類相關。將該產品的重要用戶類與那些不太重要的用戶類區分開。
2.3假定和約束
一般約束、假設及對用戶的要求。
三、業務功能概要描述
3.1現有系統分析
對現有系統（包括自動或人工的）進行簡要分析。
3.2業務描述
描述實際業務的過程和特點，即業務建模。
3.3系統角色
畫出系統中的角色，並用文字進行說明。
3.4主題描述（或：系統用例視圖）
畫出主題圖，描述主題內的業務和主題間的業務。
或用UML語言描繪系統總的用例視圖。
3.5業務流程圖
用UML的活動圖描繪系統總的業務流程。
3.6業務接口
3.6.1外部業務接口
描述與其它項目或業務模組的功能接口。例如：工資模組與考勤、考核、任免、職稱等模組的功能接口描述。
3.6.2內部業務接口
描述各個主題之間的業務接口。
四、業務功能詳細描述
用語言和圖對每個子系統、主題或業務模組要完成的`功能進行完整詳細的描述。即功能建模。
4.1子系統（模組一）
4.1.1業務功能描述
用文字語言描述子系統、主題或業務模組要完成的功能。
4.1.2業務流程圖
用UML的活動圖描繪子系統或業務模組的業務流程，在活動圖中標註用到的或輸入輸出的表格、資料。注意，這裡的活動圖描述的是該子模組的業務流程。
4.1.3主題描述及用例視圖
若主題下面還含有子主題，則畫出主題圖，描述主題內的業務和主題間的業務；並且接著畫出子系統或業務模組的詳細用例視圖。
若主題下面不含子主題，則直接畫出子系統或業務模組的詳細用例視圖。
4.1.4用例描述
對全部用例或主要的用例用文字進行詳細描述。
4.1.4.1用例名稱一
【用例功能說明】
用文字詳細描述該用例的目的、功能。
【操作描述】
用文字描述子系統或業務模組中主要用例的操作流程和要求。
【活動圖、順序圖或協同圖】（可選內容）用UML的順序圖或協同圖描述該用例的操作流程。
【界面原型】（可選內容）
描繪用戶所希望的圖形用戶界面標準或風格，包括大致的螢幕布局、功能選單、標準按鈕、快捷鍵、出錯信息顯示標準等。
4.1.4.2用例名稱二
【用例功能說明】
用文字詳細描述該用例的目的、功能。
【操作描述】
用文字描述子系統或業務模組中主要用例的操作流程和要求。
【活動圖、順序圖或協同圖】（可選內容）用UML的順序圖或協同圖描述該用例的操作流程。
【界面原型】（可選內容）
描繪用戶所希望的圖形用戶界面標準或風格，包括大致的螢幕布局、功能選單、標準按鈕、快捷鍵、出錯信息顯示標準等。
4.1.4.3用例名稱三
4.1.5信息項描述
採集子系統或業務模組中用到的信息項，對於非國標、部標的指標項要給予具體解釋和規範建議。
推薦描述形式如下：
信息集名稱：
4.2子系統（模組二）
4.3子系統（模組三）
五、性能要求
5.1用戶數要求
5.2業務方面的並發要求
5.3正常和極端情況下的時間要求
5.4容錯要求
5.5許可權要求
5.6靈活性要求
當需求發生變化時的適應能力要求。
5.7使用頻度要求
日常使用或定期使用等的描述。
六、其它需求
詳細描述本產品/項目必需滿足的法令法規、行業規範、契約/標書中的其它要求、以往類似設計中的適用信息以及本公司對此項目附加的其它需求等。
七、附錄
對本需求有說明意義的資料：文檔、數據、表格、樣張等等。
附註：
用例視圖、活動圖（業務流程圖）、主題圖、對象圖、狀態圖採用UML標準符號繪製。推薦使用CASE工具如：RitionalRose畫好後再貼上到Word文檔中。
如果時間充裕的話，應在輔助工具中進行業務建模，將非功能需求以及資料部分做為單獨文檔連線到模型中。
需求分析調研報告 篇3
一、網路套用需求。
1、校園網與Internet連線，使師生可通過網際網路獲取資源和信息。
2、建設學校網站，實現學校的對外宣傳以及發布學校內部信息。
3、在校園網內實現檔案傳輸共享。
4、實現學校行政、教師的無紙化辦公。
5、學生個人信息管理與查詢系統。
6、圖書館電子化，實現圖書信息搜尋。
7、校園生活電子化（包括如：一卡通消費，轉帳交納網費、電費、水費，個人帳戶網上管理和查詢）。
8、校區域網路絡輔助教育教學（如：廣播、組播，上機考試等）。
9、電子郵件系統。
二、安全需求。
1、校園網接入Internet，應使用防火牆的過濾功能來防止網路黑客和其他非法入侵者入侵網路系統，並對接入Internet用戶進行許可權控制。
2、設定用戶許可權，對不同用戶分組進行許可權限制。
三、技術需求。
1、為確保校園網的性能及安全需求，採用100/1000Mbps光釺乙太網作為校園網的'主幹。主幹網承擔了整個學校網路包交換、子網劃分、網路管理等重要任務，應採用具有三層路由功能、包交換性能高的交換機作為主幹網的節點機，分布在網路中心、圖書館、教學樓、實訓樓、食堂，教師公寓和學生公寓。
2、設立一個網路中心，配置相應的伺服器及路由交換等設備。網路中心可對整個校園網進行管理，並作為校內連線Internet的網路關口，承擔防禦過濾等安全功能。對校內各網路節點進行監控，防止病毒的傳播。
3、校園的主要建築有圖書館、教學樓、實訓樓、食堂，教師公寓、學生公寓，必須在這些建築物內安裝足夠信息點以及信息終端以滿足用戶的需求。
4、布線系統採用星形分散式拓撲結構，分為工作區子系統、水平子系統、管理子系統、垂直幹線子系統、建築群子系統、設備間子系統。
5、以學生公寓為例，每幢學生公寓有6層，每層有12間宿舍，每間宿舍須設4個信息點。據此應該在每層設集線箱，每幢公寓有一個管理間，管理間內設二層交換設備。
6、網路中心應相應的配置有E-Mail伺服器、FTP伺服器、WEB伺服器及防火牆等設備。
7、整個校園為一個虛擬區域網路，為管理不同性質用戶應劃分不同子網，進行IP位址分配以及相應的路由配置。針對我校有兩個校區的情況，可通過公共網路採用V將兩個校區連在同一虛擬區域網路。
四、安全需求。
1、按照相應標準進行區域網路的建設，確保物理層安全。
2、採用主機訪問控制手段加強對主機的訪問控制。
3、劃分安全子網，加強網路邊界的訪問控制，防止內外的攻擊威脅，定期進行網路安全檢測，建立網路防病毒系統。
4、建立身份認證系統，對各套用系統本身進行加固。
五、其他需求。
1、在圖書館、自習室建設無線網路，以滿足學習需要。
2、做好應急設備的準備，相應應有備用設備以確保緊急情況下的網路保障。