產品需求調研分析報告【多篇】

需求分析 篇一

1、對投標人的要求

投標人必須認真閲讀以下內容 ，以免造成投標失敗。

1）投標人必須保證所提供的產品貨真價實，所有產品均提交原始設備生產廠商證明。

2）設標人對招標人提出的需親自到現場解決的問題能保障4小時內的響應，諮詢應及時相應。

3）投標人應本着認真負責的態度組織技術隊伍，並做好投標的整體方案並提出長期保修、維護、服務以及今後技術支持的措施計劃和承諾。

4）自系統建設工作一開始，投標人就應允許招標人的工作人員參與系統的安裝、測試、診斷及解決問題等各項工作。

5）投標人必須提供系統建設的工作內容、工作日程表，日程表內容至少應包括到貨日期、驗貨日期、驗貨人員、現場安裝、系統聯調、系統試運行、集成驗收、應用系統運行、技術培訓等。

6）投標人必須保證有能力進行對設備（應用系統、材料）生產廠商的簽約、督導和工作協調。

7）投標人應對滿足規定指標的設備及軟件供貨商的在資信和信譽進行認真考核並對招標人負責。

8）投標人應將招標人標書中所有設備、軟件。及與有關生產廠商簽約和有關技術合作、維護、服務等文件以副本形式提供給招標人以份。

9）投標人應負責在項目完成時將系統的全部有關技術文件、資料及測試、驗收報告等文檔彙集成冊交付招標人。

10） 投標人應對招標人標書中所列內容全部驗收後方為該項目的建設工作完成。

11） 投標人和產品供貨商對提供的產品保證的技術支持售後服務，保證的產品免費維修服務。

2、對於投標書的要求

1）投標人必須滿足標書的要求，否則投標人的投標書將被拒絕並認作沒有回答。

2）投標人必須審閲相關技術手冊以便準備投標文件和技術部分，提供一個準確的陳述。對每個單項產品，投標人必須提供原廠商的正式技術指標説明材料。

3）在投標書中建議的每個硬件和軟件的型號部件逐一説明。

4）投標人的投標文件需將技術部分和商務部分嚴格分離，分別封裝，否則將可能影響評價結果。

3、對招標書的説明

1）投標人須提供詳細外網建設方案。

2）必須按招標人提供的網絡設備、軟件、連接件進行設計。若有特殊情況無法滿足系統方案及系統運行要求的，投標人應主動提出來，並以書面的形式告知招標人，待招標人確認後才進行修改。

一、建設的總體要求

南充市電子政務外網按照中共中央辦公廳、國務院辦公廳轉發的《國家信息化領導小組關於電子政務建設指導意見》（中辦發[2002]7號文件）的要求進行建設。電子政務外網與互聯網邏輯隔離。縱向與中央、省、縣、鄉各級黨政機關相連，橫向與各級部門相連。本次建設要求市政府、市委、人大、政

協通過光纜連接，不在光纜覆蓋範圍內的部門通過租用電信營業運營商的線路輸入，機房（設備間）設在南充市順慶區清泉城市政府辦公大樓。

二、建設的詳細要求

（一）南充市電子政務外網平台建設工程項目。

1、網絡建設的目標

採用千兆以太網技術，建成以千兆光纖（主幹）+非屏蔽雙絞線為主要傳輸介質的計算機通信網絡。計算機網絡設備的配置須滿足南充市電子政務外網需求。符合中辦發[2002]17號文件要求能適應2-3年內的業務增長和突發性事件的需要。確保系統的可擴展性和先進性，並注意設備的宂餘設計以及網絡的負載均衡。

2、網絡平台的建設

政務外網是政府的業務專網，與互聯網之間邏輯隔離，主要運行政務部門面向社會的專業性服務業務和不需要在內網上運行的業務。建設電子政務外網平台的目的是促進各個業務系統的互聯、資源共享。

物理鏈路：市級匯接中心與各縣（市區）匯接中心相連，實現上下之間、縱橫之間的信息、文件的相互傳輸。設置支持多層交換和千兆的網絡核心；採用具有千兆上連能力的10/100M自適應交換機作為訪問層交換機；新區1、2、3號辦公樓的計算機用户直接與本樓交換機相連訪問政務外網。

傳輸介質：選擇光纖作為網絡主幹（市政府至市委、人大、政協；1號樓至2號樓、3號樓）傳輸介質，其他採用非屏蔽超五類雙絞線作為傳輸介質。

網絡操作系統：Windows NT/2000 Server或UNIX或LINUX。

網絡協議：TCP/IP。

網絡應用平台：應用系統採用符合“建立統一的信息應用平台”進行設計和開發。應用系統的建設可根據各應用系統的特點，選用C/S或B/S模式，也可以採用兩種模式相結合的方式。

3、數據中心建設

數據中心彙集電子政務外網的所有服務器系統和應用系統，是開展各種應用和服務的統一電子政務平台，是網絡的運行管理中心。

4、網絡安全建設

1）網絡隔離

充分利用交換機的交換路由功能，根據業務管理需要劃分VLAN

2）防火牆技術

3）虛擬專用網絡（VPN）技術；

4）病毒防治技術

5、應用系統建設

電子政務網絡平台的建設目的是應用，進行應用系統的建設是電子政務建設的核心內容，是電子政務建設的重中之重。

本次應用系統建設的重點是：

1）辦公自動化系統

辦公自動化系統建設的重點是市委辦系統和市政府辦系統。辦公自動化系統常規技術要求：

 統一平台

系統要求基於Lotus Domino平台的開發，同時還將第三方開發工具

（Java、VC++）用於辦公系統的底層開發，通過控件技術實現了手寫批示、工作流定義、統計分析、個性化界面設計等，提供一套完整的基於Lotus Domino的辦公自動化系統。

要求在Windows 2000NT 、Linux等平台上實施基於Lotus Domino的辦公系統。須購買相應的正版軟件。

 支持B/S模式

辦公系統支持B/S方式運行。

 工作即時提醒

工作即時提醒通過對服務器端個人信息的定時監測實待辦事宜、郵件、便籤信息及時提醒，以免耽誤工作。提供常規的計算機提醒和擴展的手機或呼機提醒的組合。

 電子/手工並行支持

 辦公系統在電子方式初期運轉時特別注意到與紙質文件並行的支持因此

在每一個環節要求設置打印功能，部分環節還要設置掃描輸入功能。  流程定義

（1） 能提供完整的流程自定義：用户既可以選擇預先配置好的流程模板收

發公文，又可以根據自己的意圖，很方便地創建、修改流程無需編程。圖形化的流程定製界面。

（2） 能對整個工作流程進行實時跟蹤監控並及時記錄審核修改信息。能夠

按照辦公有關規定顯示公文在其辦理過程中所處的地點、狀態，以便

採取相應的統計、分析、催辦等處理措施。

（3） 可以根據實際工作需要和各類辦公業務的環節來定義任務停留時間，系統定時檢測，超時催辦提醒。當用户有新的任務需要處理時，系統

提供視覺和聽覺的提醒功能。

 人員權限集中設置

（1） 權限設置

開發與辦公系統配套的權限設置控件，與系統配置集成在一起，便於系統管理員行使管理職責。

（2） 工作流調整

工作流調整通過工作流定製平台實現，在工作流屬性中可以調整

辦理流程的管理員、閲讀者、時間控制、歸檔等。

（3） 辦公系統羣組授權

在處理屬性中可調整辦理人員、辦理權限、處理的時間設置、域

值設置、分發設置、自動代理、讀者控制、代辦轉辦設置等。

（3） 工作流中的人員調整

工作流中各個辦理節點的辦理人員要求支持角色（崗位）和人員

兩種命名方式。

角色（崗位）是相對固定的，當針對某崗位的具體人員發生工作

調動、職務變更調離等變化時，管理員以最簡單的方法發出變更

指令，調整角色（崗位）和具體人員的對應關係即可完成系統的調整角色（崗位）與具體人員對應關係在系統配置的人員管理中

實現。

 多種公文處理方式

文件修改支持鍵盤輸入和手寫批示，圖像格式保存保證清晰，支持公文掃描輸入系統初始化時可以自動檢測文件掃描輸入程序。能實現自動無損數據壓縮。手寫筆採用漢王手寫識別筆或類似功能手寫筆。能提供各種公文格式模板，簡單易操作。

 手寫控件痕跡保留

在辦公自動化系統使用過程中，很多環節需要領導親筆簽名，為了解決這一問題，很多常規的辦公自動化系統只好將文件打印出來，請領導親筆簽名。不僅學雜費紙，而且祕書的工作量也加大了。

在辦公自動化系統中的任何需要領導親筆簽名的應用數據庫中都可以方便地設置並使用。支持針對WORD格式文檔批註，有選擇地查看批註的筆跡；可清除未確認前批註的筆跡（分單筆劃清除和全部清除，確認後不能清除）

 容錯與糾錯的能力

系統要充分考慮容錯和糾錯能力，以防止數據誤操作而導致數據丟失。  系統操作安全日誌

系統要求具有詳細的系統日誌功能，如：用户登錄、數據庫訪問、郵件路由、數據複製、記賬信息（已用時間、已讀文檔、寫入文檔、網絡端口、網絡使用、傳送處理量）、中繼連接等信息。

同時，管理員還要求能夠對日誌信息庫進行維護操作。

 系統管理分級機制

辦公系統涉及到單位內部大多數用户，因此辦公系統管理工作量較大而且繁雜，因此辦公系統管理分為系統管理員和應用管理員。

系統管理員負現：系統管理，包括驗證字維護、用户人員維護、系統日誌跟蹤、辦公數據備份、主從服務器複製（數據傳輸）設置；

應用管理負責：功能模塊存取權限設置、流程定製、應用能數據初始化（關鍵字維護）等；

 應用系統監控

辦公系統服務器保證管理員可隨時查看、服務器資料。

 授權與代理人

待辦事宜授予權。

2）政府門户信息網站

政府肩並肩信息網站是一個面向企業事業單位及公眾用户的窗口。通過網站，可以樹立南充市政府的形象，方便機關、企事業單位瞭解政府概況、行政審批、資格認證等相關事項；保證以最快捷的方式在最大的範圍內讓企事業單位瞭解最關心的政府信息。

a) 網站設計原則

 整體設計分步實施

門户信息網站的設計不應該是一個孤立的網站，在設計上， 應考慮它與政務辦公系統相關，同時考慮今後的變動和擴展；

 穩定安全性

信息安全是政府信息網實施的第一要素，網站系統不但要能夠實現功能，更重要的是要穩定安全。否則，會影響政府形象。

 整合性

門户信息網站的建設應能實現內部辦公事務和外部事務處理的整合，通

過建立政務辦公信息流和事務信息流的平滑對接，提高信息流的效率。同時，能夠實現多種溝通模式的整合，通過通訊平台的多樣化優勢，提高門户信息網站系統的覆蓋能力。

 可擴展性

政府信息化建設是一個分階段的長期過程，南充市外部信息網的構造具有高度的庶民性，以降低系統擴充的調入成本，並滿足信息技術高速發展的需要。

 示範性

門户信息網站的建設所採用的技術和產品應對社會具有廣泛的示範性和引導性，網站的總體結構應依據國家電子政務安全規範和國家電子政務標準技術參考模型設計。

 技術先進成熟性

門户信息網站應採用大型關係數據庫、模塊化等先進成熟的技術方法在給用户提供了極大的靈活性的同時，也有效地保證了系統的可靠性。  系統的易管理維護性

系統符合用户的使用習慣，並滿足系統的各項要求，操作方便靈活，系統的實用性是新建系統的關鍵。

 系統的容錯性

網站系統在實施之前經過了嚴格和多角度的測試，系統可對日常工作中的某些誤操作應有防止功能，以保證整個系統的容錯與糾錯能力。

b) 網站建設目標

建立一個開放的、基於標準的電子政務統一應用平台，實現信息交換和資源共享面向公眾提供服務，增強各部門工作的透明度。

逐步支持數據、主意和視頻業務，運行各部門的業務系統，實現各網間的信息交換和資源共享，同時建立完善的信息安全體系和相應的備份系統。 c) 網站功能

 遠程數據維護

對數據庫中的和户信息，可直接通過網絡進行遠程操作，用户只需進行管理員身份確認，即可對遠程數據進行維護管理。管理員有權力對數據進行修改、添加、刪除、分類等。

 身份安全確認

對遠程數據庫管理員的確認，保證數據安全性。

 信息調查

對網站相關的信息或者其他需要調查的信息進行定製問卷式調查，網站會自動統計不同選項的數據，以圖形的方式表現出來。

 全文搜索：對本網站相關的信息進行搜索

 友情鏈接：可以進行一些比較好的網站進行鏈接，可以進行分類鏈接。  網站地圖

 最新活動：實時的對各種大事進行發佈，動態更新。

 會員註冊

上網的用户可以進行動態註冊，然後經過系統工程管理員進行確認的權限分本，可以進行相關內容的管理。普通註冊的用户只可能管理自己要管理的信息，而網站管理員可以管理整個網站。

 滾動信息

以滾動的方式動態顯示一條重要信息，可以隨時進行替換更改。

 網站信息內容的自動控制更新

網站所有的內容都江堰市是動態顯示，隨時發佈、隨時更新。用户隨時都江堰市可以看到最新網站內容。

 數據交換站

註冊用户，經過管理員授權後，可以向指定目錄上傳文件或下載文件。權限控制枱在管理系統中實現。

 留言板

為報名者設立的一個提問版塊，用户可把在報名過程中遇到的所有問題進行提問，管理員將會以最快速度回答所有問題。瀏覽留言無需權限限制。

 市長信箱

3）電子郵件系統

支持5000用户，能夠定製包過濾和別名服務，備份服務等。

4）應用交換平台系統

在電子政務應用交換台平台系統建設中，採用XML和J2EE（java 2 Enterprise Edition）技術實現。

6、信息資源建設

根據中辦發[2002]17號文精神，信息資源建設的重點是抓基礎性的全局性的戰略性的重點數據庫的建設。在堅持統籌、標準統

一、整體協調的前提下，結合實際情況，本次重點進行以下數據庫的建立；

1）文件資料數據庫

將要對公眾公佈的有關文件夾資料，建立相應的數據庫系統，為南充市領導決策提供支持，為南充公眾提供服務，從而促進南充經濟和社會發展。應保證以前的數據庫能名平滑地過渡到現在的系統中。

2）地方法規數據庫。應保證以前的數據能夠平滑地過渡到現在的系統

中。

需求分析 篇二

需求性分析

（網絡書店管理系統）

一、概述

隨着網絡通訊技術的發展，網上書店作為出版社一種全新的銷售手段，越來越受到人們的關注。它打破了傳統銷售模式在時間、空間上的限制，採用了先進的銷售手段和銷售方法，大大提高了經濟效益和資源利用率，使商務活動上了一個新台階。它可以使顧客足不出户，就能通過網絡選購商品，並由相應的網絡經銷商送貨上門。本系統的好處就是不僅能讓消費者可以方便地得到所需商品，而且還能有效的減少銷售環節，從而最大限度地降低了商品的最終價格。本項目所用的操作系統是windows 7，開發系統是Visual Studio 2008，數據庫採用SQL Sever 2005。

三、數據字典

編號名稱類型説明

1書籍信息數據存儲書籍信息=書名+作者+年代+編號+採編人員

2會員信息數據存儲會員信息=姓名+性別+出生日期+住址+聯繫電話

3圖書細目數據存儲圖書細目=編號+購買記錄

關於需求分析的總結報告 篇三

關於需求分析的總結報告 在學習了第四章的需求獲取之後做出以下總結 這部分主要強調了在優秀的軟件工程中抽象和建模的關鍵原則。使用模型來從已有的需求中梳理出誤解和遺漏的的細節並與他人溝通需求。討論了需求的不同資源和不同類型功能需求VS質量需求VS設計約束解釋如何編寫易測試的需求並描如何解決衝突。討論需求引出、需求文檔、需求評審、需求質量及度量以及如何選擇一個規格説明方法的示例。 為了開發出真正滿足用户需求的軟件產品首先必須知道用户的需求。對軟件需求的深入理解是軟件開發工作獲得成功的前提條件不論人們把設計和編碼工作做得如何出色不能真正滿足用户需求的程序任然是失敗的程序。 那麼這些工作需要在編碼前進行細緻的安排包括 一需求分析任務的建立 1 確定對系統任務的綜合要求 ○1功能需求指定系統必須提供的服務通過需求分析應該劃分出系統必須完成的所有功能 ○2性能需求指定系統必須滿足的定時約束和容量約束 ○3可靠性和可行性需求定量的指定系統的可靠性 ○4出錯處理需求説明系統對於環境錯誤應該怎樣響應 ○5接口需求描述應用系統與它的環境通信的格式 ○6約束設計約束或實現約束描述在設計或實現應用系統時應遵守的限制條件 2 分析系統的數據要求 軟件系統本質都是信息處理系統系統必須處理的信息和系統應該產生的信息在很大程度上決定了系統的面貌對軟件設計有深遠影響 3 到處系統的邏輯模型 4 修正系統開發計劃 二與用户溝通獲取需求的方法 分析員提出一些事先準備好的具體問題例如詢問客户公司銷售的商品種類、僱傭的銷售人員數目以及信息反饋時間應該多快等在非正式訪談中分析員提出一些用户可以自由回答的開性問題以鼓勵被訪問人員説出自己的想法例如詢問用户對目前正在使用的系統有哪些不滿意的地方。 在訪問用户的過程中使用情景分析技術往往非常有效。 三分析建模與規格説明 1 分析建模 2 軟件需求規格説明 通常使用自然語言完整、準確、具體地描述系統的數據要求、功能需求、性能需求、可靠性和可用性要求、出錯處理需求、接口需求、約束、逆向需求以及將來可能提出的要求。 四實體——聯繫圖 五數據規範化 六狀態轉換圖 七驗證軟件需求 1 從哪些方面驗證軟件需求的正確性包括一致性、完整性、現實性、有效性 2 驗證軟件需求的方法○1驗證需求的一致性○2驗證需求的現現實性○3驗證需求的完整性和有效性 為了詳細的瞭解並正確的解用户的需求必須使用適當方法與用户溝通訪談是與用户最基本的溝通。為了提高軟件需求精確度快速建立軟件原型是最準確最有效和最強大的需求分析技術。快速原型應該具備的基本特徵是“快速”和“容易修改”。為了跟好的理解問題常常採用建模的方法結構化分析實質就是一種建模活動除了創建分析模型之外在需求分析階段還應該寫出軟件需求規格説明書經過嚴格評審並得到用户確認後才能作為這階段的最終成果。通常要從一致性完整性現實性和有效性四個方面複審軟件需求規格説明書。 通過做一些小項目我更深體會發到對於軟件的需求分析一旦分析失誤或者不能很好的滿足用户的要求都將是一項失敗的項目。如果是大項目將給公司帶來不可估量的損失。特別是書寫需求規格説明書除了與用户進行很好溝通外自己要梳理出很清晰的思路這樣才能很好的按照需求進行編碼。

需求分析報告 篇四

需求分析報告

綜合要求

一、功能需求

1.1 功能劃分

（1）“衣”子系統

（2）“食”子系統

（3）“住”子系統 （4）“行”子系統

1.2 功能描述

（1）“衣”子系統

實現功能：

1）用户服裝信息的管理

2）通過當時外界環境和現有服裝進行實時推薦

（2）“食”子系統

實現功能：

1）根據用户地理位置（家or餐館）推送用户當前應攝入的健康食物 。

（3）“住”子系統

實現功能：

1）自動調整屋內温度、濕度、光線和傢俱（沙發、牀）的軟硬程度

2）通過無線遙控對各智能終端進一步調節 （4）“行”子系統

實現功能：

有車用户：結合用户對於出行成本的選擇（最省時，最省油，折中），給出最優的出行路線。

無車用户：

1）鏈接打車軟件

2）通過連接“車來了”等軟件給用户提供建議

1.3系統功能

（1）設計不同用户的操作權限和登錄方法。

（2）通過傳感器獲得周圍環境的温度，濕度並將其錄入數據庫。

（3）通過網絡信息抓取以及衞星定位獲得必要信息（車流量）並將其錄入數據庫。 （4）實時獲得用户身體健康係數及其飲食喜好並將其錄入數據庫。 （5）獲得附近餐館和菜品的信息並將其錄入數據庫。

（6）根據車載傳感器獲得車距和能見度等信息，並將其錄入數據庫。 （7）實現語音錄入當前用户的代辦適宜。 （8）通過消息推送，實現智能辦公。

二、性能需求

2.1 數據精確度 該系統對精度要求高，確保數據一致性，確保數據轉換的及時準確，確保更新數據的及時準確。

2.2 系統特性

·系統的高速性，穩定性，安全性。

·移動端（安卓／ios 內存2Ｇ 容量16Ｇ 分辨率320*480） ·反映時間：10ms – 100ms ·信息量速率：500bit/s或bps ·數據庫容量：500Ｔ

三、可靠性和可用性需求

3.1 穩定性

·對於用户比較繁忙的時候，系統信息就會存在數百甚至數千上萬的併發量，系統對於高併發應有相應的負載均衡機制，對所有請求進行優先排隊，滿足高運行情況下的穩定性和可靠性。

3.2可靠性

·對於遭受網絡攻擊，或者服務器硬件異常等意外情況，要有意外處理機制，需要系 統能夠保證定時備份數據信息，保證在服務器異常的情況下能及時啟動應急機制。保證系統的正常訪問。

3.3 安全性

·提高安全保密機制，保證數據可靠安全

·對不同用户分配不同的權限

·用户只能操作相應權限的信息，如查看，刪除信息等

·要保證用户信息的安全性，保證管理員和開發者不能夠隨意的查閲改動用户信息

3.4完整性

·提高數據完整性，參照完整性等

3.5 易用性

·提高使用性，便於用户操作，提高用户滿意度。

3.6可複用性

·保證代碼可複用，方便操作

3.7 可維護性

·提高程序健壯性，保證程序的後期可維護性

3.8 可移植性

·提高代碼使用次數，提高利用率，保證代碼可移植性

3.9 可測試性

·保證程序可測試，便於後期操作

四。出錯處理需求

4.1格式要求

·給每一個信息的格式都要注意其形式。格式不對的自動重新測試，以及自動把情況反饋給管理員。

4.2信息保存

·對於外來攻擊導致系統崩潰情況，需要及時保留用户當前所有的信息。

五、接口需求

5.1 用户接口

·把用户提交的賬號密碼，在數據庫中進行搜索查詢進行驗證。

5.2硬件接口

·温度傳感器接口，空氣濕度傳感器接口

5.3 軟件接口

·實現衣食住行模塊和數據庫之間相互傳輸信息

5.4 通信需求接口

·實現衞星以及車載傳感器把測的數據進行傳輸。

六、約束

6.1精度

·對於温度，濕度要求精確到小數點後兩位。對於能見度等問題需要精確到誤差在3米之內

6.2語言約束

·英語和漢語結合。

6.3設計約束

·全部過程需要從整體，平衡出發。不要僅僅開發完一個在區開發另外一個。

6.4使用標準

·全部的標準使用國際標準。

6.5硬件平台

·台式機為xp/win7系統。移動端為android/ios。

七、逆向需求

基於互聯網的“懶人系統”目前能夠完成生活許多方面的推薦以及收集測試信息等。但是尚且不能人性化的代替擁護進行決定。

八．系統用例圖

服裝推薦傳感器食物推薦用户家居調節因特網出行推薦登陸

九．系統數據需求分析

9.1系統的E-R圖

服裝餐廳服裝推薦食物推薦用户家居調節出行推薦家居用品道路

9.2數據需求

（1）穿衣子系統

（衣櫥統計，氣象監控，期刊統計，用户喜好） 説明：

衣櫥統計：記錄用户當前擁有的服飾，需要用户自行更新。

氣象監控：記錄實時的天氣情況，從互聯網獲取當前温度氣象信息。

期刊統計：統計當前時尚期刊中出現頻率較高的服飾搭配信息，以便向用户推送。 用户喜好：統計用户的穿衣習慣，找出並記錄用户喜歡的搭配風格，以便系統進行比較。 （2）飲食子系統

（飲食記錄，飲食統計，飯店信息） 説明：

飲食記錄：記錄用户日常的一日三餐情況。 飲食統計：根據飲食記錄中的信息，分析出用户偏好並記錄。

飯店信息：儲存用户周邊飲食信息，根據系統分析，為用户推薦適合的餐飲建議。 （3）住宿子系統 （傢俱信息統計） 説明：

此係統主要負責管理用户生活起居，所含數據包括： 室內温度，家電狀態（如電視開閉，空調開閉），照明系統，窗簾控制 （4）出行子系統

（地圖信息，公交信息，票務信息，記事本） 説明：

地圖信息：主要供導航軟件調用，並按時進行更新。

公交信息：儲存用户周邊的公共交通信息，方便用户乘坐公交車。

十．系統邏輯模型

10.1數據流圖 衣： 1層：

温度傳感器温度日期因特網流行服裝信息流行服裝信息用户瀏覽習慣信息用户瀏覽習慣信息温度日期日期温度1採集信息服裝推薦子系統的信息流行服裝信息用户瀏覽習慣信息服裝推薦子系統的信息服裝推薦子系統的信息現有服裝信息出席場合信息用户2執行服裝推薦算法推薦的服裝信息3輸出推薦的服裝推薦的服裝信息推薦的服裝信息推薦的服裝信息 2層： 温度傳感器因特網温度日期流行服裝用户瀏覽信息習慣信息用户瀏覽習慣信息用户瀏覽習慣信息1.6接收用户瀏覽習慣信息温度日期流行服裝信息温度日期流行服裝信息1.5接收流行服裝信息1.3温度1.4接收日期温度日期流行服裝信息用户瀏覽習慣信息採集信息服裝需求信息1.1接收服裝需求信息現有服裝信息1.2接收現有服裝信息現有服裝信息服裝需求信息用户

服裝推薦子系統服裝推薦子系統的信息的信息2.1整理信息正確格式的信息2.2“標籤”算法推薦的服裝推薦的服裝

食： 1層：

傳感器身體狀況信息身體狀況信息身體狀況信息因特網餐廳菜品信息餐廳菜品信息餐廳菜品信息食物推薦子系統的信息1採集信息食物推薦子系統的信息食物推薦子系統的信息飲食喜好用户2執行食物推薦算法推薦的菜品信息3輸出推薦的菜品信息推薦的菜品信息推薦的菜品信息推薦的菜品信息 2層：

傳感器因特網身體狀況信息餐廳菜品信息身體狀況信息餐廳菜品信息身體狀況信息1.2接受身體狀況信息餐廳菜品信息1.3餐廳菜品信息身體狀況信息餐廳菜品信息採集信息飲食需求信息1.1接收飲食喜好信息飲食喜好信息用户 食物推薦子系統食物推薦子系統的信息的信息2.1整理信息正確格式的信息2.2“標籤”算法推薦的菜品推薦的菜品

住： 1層：

傳感器用户體徵信息温度信息光線信息用户體徵信息用户體徵信息温度信息温度信息濕度信息濕度信息濕度信息家居調節子系統的信息家居調節子系統的信息家居調節子系統的信息光線信息光線信息1採集信息用户習慣的環境信息用户3執行調節方案2執行家居調節算法調節方案調節方案調節方案温度濕度信息信息亮度信息窗簾位置信息空調電燈窗簾

2層：

傳感器温度信息光線信息濕度信息温度信息温度信息1.2接收温度信息光線信息光線信息1.3接收光線信息濕度信息濕度信息1.4接收濕度信息温度信息光線信息濕度信息採集信息用户習慣的環境信息1.1接收用户習慣的環境信息用户習慣的環境信息用户 家居調節子系統家居調節子系統的信息的信息2.1整理信息正確格式的信息2.2“選路”算法調節方案調節方案

調解方案温度信息濕度信息亮度信息窗簾位置信息3.1發送温度信息3.2發送濕度信息3.3發送亮度信息3.4發送位置信息温度信息濕度信息亮度信息位置信息空調電燈窗簾

行： 1層：

傳感器用户位置信息用户位置信息因特網道路信息道路信息出行推薦子系統的信息用户位置信息道路信息出行推薦子系統的信息出行推薦子系統的信息1採集信息時間金錢需求信息目的地信息用户2執行出行推薦算法推薦方案推薦方案推薦方案3輸出推薦方案推薦方案

2層： 傳感器用户位置信息用户位置信息用户位置信息2.3接收用户位置信息道路信息道路信息2.4接收道路信息道路信息因特網用户位置信息道路信息採集信息時間金錢需求信息2.1接收時間金錢需求信息目的地信息2.2接收目的地信息時間金錢需求信息目的地信息用户

出行推薦子系統出行推薦子系統的信息的信息2.1整理信息正確格式的信息2.2“標籤”算法出行方案出行方案

10.2相應的數據字典 衣： 數據流 數據流名：出席場合信息 説明：用户希望服裝推薦系統針對不同的場合幫助其選擇合適的服裝，服裝推薦系統會在用户已有衣服的基礎上提供給用户合適的服裝搭配方案 數據流來源：用户

數據流去向：採集信息

定義：出席的場合={學校，辦公室，聚會，典禮}

數據流名：温度

説明：記錄室內外温度，幫助用户選擇合適厚度的衣服 數據流來源：温度傳感器 數據流去向：採集信息 定義：温度=-40.。40

數據流名：現有服裝信息 説明：記錄用户已有服裝，服裝推薦系統在已有服裝基礎上提供給用户合適的服裝搭配方案

數據流來源：用户

數據流去向：採集信息 定義：已有服裝信息=服裝編號+服裝名稱+品牌+尺寸+顏色+款式+材質+服裝圖片索引

數據流名：日期

説明：記錄當前日期，幫助用户選擇合適季節的衣服 數據流來源：因特網

數據流去向：採集信息（數據存儲） 定義：日期=年＋月＋日

數據流名：流行服裝信息

説明：獲得當下的流行風尚，幫助服裝推薦系統和已有服裝進行對比，從而給出符合當下流行的服裝搭配 數據流來源：互聯網

數據流去向：採集信息（數據存儲） 定義：流行服裝信息=服裝編號+服裝名稱+品牌+尺寸+顏色+款式+材質+服裝圖片索引

數據流名：用户瀏覽習慣信息

説明：記錄用户經常瀏覽的服裝，將信息發送給服裝推薦系統，服裝推薦系統由此分析用户的穿衣喜好，從而推薦給用户符合其穿衣品味的服裝 數據流來源：互聯網

數據流去向：採集信息（數據存儲） 定義：服裝編號+瀏覽次數

數據流名：推薦的服裝 説明：服裝推薦系統根據對採集的參數進行智能處理，最後得到合適的服裝搭配信息

數據流來源：智能服裝推薦程序

數據流去向：推薦的服裝信息（數據存儲） 定義：推薦的服裝=服裝編號+服裝圖片索引 數據加工

加工名：採集信息 加工編號：1 簡要描述：採集服裝推薦算法需要的信息

輸入數據流：出席場合信息，温度，現有服裝信息，日期，流行服裝信息，用户喜好信息

輸出數據流：服裝推薦算法的信息

加工邏輯：採集出席場合信息，傳感器信息，因特網信息。

加工名：執行服裝推薦算法 加工編號：2 簡要描述：處理正確格式的信息，把信息與數據庫中的解決方案相匹配，得到解決方案。

輸入數據流：服裝推薦子系統的信息 輸出數據流：推薦的服裝 加工邏輯：“標籤”算法的本質是專家系統，數據庫有1萬條用户在各種情況下的解決方案（1萬條記錄），用户在界面上選擇的標籤會變成另一張二維表中的記錄，“標籤”算法會將用户的選擇（記錄）和數據庫1萬條記錄比照，匹配項最多的記錄的解決方案會成為最後的推薦方案。 加工名：輸出推薦的服裝 加工編號：3 簡要描述：顯示推薦的服裝信息 輸入數據流：推薦的服裝信息 輸出數據流：推薦的服裝信息 加工邏輯：顯示推薦的服裝信息

數據文件名：温度

簡述：存放的是温度信息 輸入數據：温度 輸出數據：温度

數據文件組成：温度

數據存儲

數據文件名：現有服裝信息 簡述：存放已有服裝信息

輸入數據：服裝編號，顏色，尺碼，類型，條形碼 輸出數據：服裝編號

數據文件組成：服裝編號，顏色，尺碼，類型，條形碼

數據文件名：日期 簡述：存放當前的日期 輸入數據：年+月+日 輸出數據：年+月+日 數據文件組成：年+月+日

數據文件名：流行服裝信息 簡述：存放當時流行的服裝款式

輸入數據：顏色，尺碼，類型，條形碼 輸出數據：條形碼

數據文件組成：顏色，尺碼，類型，條形碼

數據文件名：用户瀏覽習慣信息

簡述：存放用户在各大網站查詢的服裝信息 輸入數據：用户瀏覽習慣信息 輸出數據：用户瀏覽習慣信息

數據文件組成：服裝編號，瀏覽次數

食： 數據流

數據流名：飲食喜好

説明：用户希望飲食推薦系統推薦一些餐飲信息，以供選擇，飲食推薦系統會根據用户的飲食習慣，偏好，營養均衡等多種因素結合為用户推薦健康可口的食物。 數據流來源：用户

數據流去向：採集信息 定義：飲食喜好={甜，鹹}

數據流名：身體狀況信息

説明：系統通過記錄或探測，用户的基本生命體徵如心率，血壓，血糖等，為推薦飲食提供參考信息。

數據流來源：傳感器，因特網 數據流去向：採集信息

定義：身體狀況信息=心率+血壓+血糖

數據流名：餐廳菜品信息

説明：系統通過存儲並及時更新餐廳菜單，為推薦飲食提供參考信息。 數據流來源：因特網 數據流去向：採集信息

定義：餐廳菜品信息=餐廳名+餐廳編號+菜名名+菜品編號+菜品營養+菜品口味、

數據流名：推薦的菜品信息

説明：食物推薦算法處理食物推薦子系統信息產生的結果。 數據流來源：執行食物推薦算法 數據流去向：輸出推薦的菜品信息

定義：餐廳菜品信息=餐廳名+餐廳編號+菜名名+菜品編號+菜品營養+菜品口味、數據加工：

加工名:採集信息 加工編號：1 簡要描述：採集食物推薦子系統所需數據

輸入數據流：身體狀況信息，餐廳菜品信息，飲食喜好 輸出數據流：食物推薦子系統的信息

加工邏輯：從互聯網，用户輸入，傳感器接受信息

加工名：執行食物推薦算法 加工編號：2 簡要描述：處理正確格式的信息，把信息與數據庫中的解決方案相匹配，得到解決方案。

輸入數據流：食物推薦子系統的信息 輸出數據流：推薦的菜品 加工邏輯：“標籤”算法的本質是專家系統，數據庫有1萬條用户在各種情況下的解決方案（1萬條記錄），用户在界面上選擇的標籤會變成另一張二維表中的記錄，“標籤”算法會將用户的選擇（記錄）和數據庫1萬條記錄比照，匹配項最多的記錄的解決方案會成為最後的推薦方案。

加工名：輸出推薦的菜品 加工編號：3 簡要描述：顯示推薦的菜品信息 輸入數據流：推薦的菜品信息 輸出數據流：推薦的菜品信息 加工邏輯：顯示推薦的菜品信息

數據存儲：

數據文件名：身體狀況信息

簡述：存放身體狀況信息，如體重，血壓，心率等 輸入數據：身體狀況信息 輸出數據：身體狀況信息

數據文件組成：體重，血壓，心率

數據文件名：餐廳菜品信息 簡述：存放餐廳菜單 輸入數據：餐廳菜品信息 輸出數據：餐廳菜品信息

數據文件組成：餐廳名，餐廳編號，菜名名，菜品編號，菜品營養，菜品口味、

數據文件名：推薦的菜品信息 簡述：存放推薦的菜品信息 輸入數據：推薦的菜品信息 輸出數據：推薦的菜品信息

數據文件組成：餐廳名，餐廳編號，菜名名，菜品編號，菜品營養，菜品口味、

住： 數據流

數據流名：温度信息 説明：採集室內的温度信息，反饋給用户，或者系統根據温度自動採取相應措施，調節室內温度。

數據流來源：温度傳感器

數據流去向：採集家居控制系統的參數 定義：温度=-40-40攝氏度

數據流名：光線信息 説明：採集室內的光線信息，反饋給用户，或者系統根據温度自動採取相應措施，調節室內光照強度。 數據流來源：光敏傳感器

數據流去向：採集家居控制系統的參數 定義：光照強度=0-180流明

數據流名：濕度信息 説明：採集室內的濕度信息，反饋給用户，或者系統根據温度自動採取相應措施，調節室內濕度。

數據流來源：濕度傳感器

數據流去向：採集家居控制系統的參數 定義：濕度=10%-80%

數據流名：用户習慣的環境信息

説明：採集用户習慣的温度信息，光線信息，濕度信息 數據流來源：用户

數據流去向：採集信息

定義：用户習慣的環境信息=温度+光線+濕度

數據加工

加工名：採集信息 加工編號：1 簡要描述：採集智能控制系統需要的參數

輸入數據流：温度，濕度，光照強度，温度請求，濕度請求，光照請求 輸出數據流：智能家居控制系統的參數

加工邏輯：從各個傳感器接受信息，並與用户設置進行對比，得出相應操作發送給控制器實施。

加工名：執行家居調節算法 加工編號：2 簡要描述：處理正確格式的信息，把信息與數據庫中的解決方案相匹配，得到解決方案。

輸入數據流：家居調節子系統的信息 輸出數據流：調解方案 加工邏輯：“選路”算法本質是基於條件判斷的數據處理系統。該處理系統自身包含多個IF語句對用户需求進行判斷分支執行。從而得到最後的推薦方案。

加工名：執行調節方案 加工編號：3 簡要描述：把温度，濕度，亮度，窗簾的位置信息傳遞給空調，電燈，窗簾 輸入數據流：調節方案

輸出數據流：温度，濕度，亮度，窗簾的位置信息 加工邏輯：對傳感器傳遞信息

數據存儲

數據文件名：温度信息 簡述：存放的是温度信息 輸入數據：温度信息 輸出數據：温度信息 數據文件組成：温度

數據文件名：濕度信息 簡述：存放的是濕度信息 輸入數據：濕度信息 輸出數據：濕度信息 數據文件組成：濕度

數據文件名：亮度信息

簡述：存放的是光照強度信息 輸入數據：亮度信息 輸出數據：亮度信息 數據文件組成：亮度信息

行： 數據流

數據流名：用户位置信息 説明：藉助通信運營商來獲取用户詳細位置，出行管理系統會利用該位置信息提供導航，或叫車服務。 數據流來源：通信運營商

數據流去向：採集出行管理系統的參數 定義：用户位置信息=經度+緯度

數據流名：道路信息

説明：將街道信息儲存到客户端，，並定期進行更新，出行管理系統會利用該道路信息提供導航服務。 數據流來源：互聯網

數據流去向：採集出行管理系統的參數 定義：道路信息={繁忙，暢通}

數據流名：目的地信息

説明：用户想要到達的目的地信息 數據流來源：用户

數據流去向：採集信息

定義：目的地信息=目的地信息

數據流名：時間金錢需求信息 説明：用户對於時間，金錢的要求 數據流來源：用户

數據流去向：採集信息

定義：時間金錢需求信息=時間+金錢

數據加工

加工名：採集信息 加工編號：1 簡要描述：採集出行推薦子系統需要的信息

輸入數據流：用户位置信息，道路信息，目的地信息，時間金錢需求信息 輸出數據流：出行推薦子系統的信息 加工邏輯：從用户和互聯網接收信息。

加工名：執行出行推薦算法 加工編號：2 簡要描述：處理正確格式的信息，把信息與數據庫中的解決方案相匹配，得到解決方案。

輸入數據流：出行推薦子系統的信息 輸出數據流：推薦方案 加工邏輯：“標籤”算法的本質是專家系統，數據庫有1萬條用户在各種情況下的解決方案（1萬條記錄），用户在界面上選擇的標籤會變成另一張二維表中的記錄，“標籤”算法會將用户的選擇（記錄）和數據庫1萬條記錄比照，匹配項最多的記錄的解決方案會成為最後的推薦方案。

加工名：輸出推薦方案 加工編號：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地址分配以及相應的路由配置。針對我校有兩個校區的情況，可通過公共網絡採用Vxx將兩個校區連在同一虛擬局域網。

四、安全需求。

1、按照相應標準進行局域網的建設，確保物理層安全。

2、採用主機訪問控制手段加強對主機的訪問控制。

3、劃分安全子網，加強網絡邊界的訪問控制，防止內外的攻擊威脅，定期進行網絡安全檢測，建立網絡防病毒系統。

4、建立身份認證系統，對各應用系統本身進行加固。

五、其他需求。

1、在圖書館、自習室建設無線網絡，以滿足學習需要。

2、做好應急設備的準備，相應應有備用設備以確保緊急情況下的網絡保障。

需求分析報告怎麼寫(總結報告格式要求 篇六

需求分析報告

版本：1.0.0

編者年月日 審核年月日 批准年月日

XXX

二〇一四年五月

一、引言

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 用例描述

對全部用例或主要的用例用文字進行詳細描述。

用例名稱一

【用例功能説明】

用文字詳細描述該用例的目的、功能。

【操作描述】

用文字描述子系統或業務模塊中主要用例的操作流程和要求。

【活動圖、順序圖或協同圖】 （可選內容） 用UML的順序圖或協同圖描述該用例的操作流程。

【界面原型】 （可選內容）

描繪用户所希望的圖形用户界面標準或風格，包括大致的屏幕布局、功能菜單、標準按鈕、快捷鍵、出錯信息顯示標準等。

用例名稱二

【用例功能説明】

用文字詳細描述該用例的目的、功能。

【操作描述】

用文字描述子系統或業務模塊中主要用例的操作流程和要求。

【活動圖、順序圖或協同圖】 （可選內容） 用UML的順序圖或協同圖描述該用例的操作流程。

【界面原型】（可選內容）

描繪用户所希望的圖形用户界面標準或風格，包括大致的屏幕布局、功能菜單、標準按鈕、快捷鍵、出錯信息顯示標準等。

用例名稱三

。.。 。.。4.1.5 信息項描述

採集子系統或業務模塊中用到的信息項，對於非國標、部標的指標項要給予具體解釋和規範建議。

推薦描述形式如下：

信息集名稱：********

4.2 子系統（模塊二）

4.3 子系統（模塊三）

五、性能要求

5.1 用户數要求

5.2 業務方面的併發要求

5.3 正常和極端情況下的時間要求

5.4 容錯要求

5.5 權限要求

5.6 靈活性要求

當需求發生變化時的適應能力要求。

5.7 使用頻度要求

日常使用或定期使用等的描述。

六、其它需求

詳細描述本產品/項目必需滿足的法令法規、行業規範、合同/標書中的其它要求、以往類似設計中的適用信息以及本公司對此項目附加的其它需求等。

七、附錄

對本需求有説明意義的資料：文檔、數據、表格、樣張等等。

附註：

用例視圖、活動圖（業務流程圖）、主題圖、對象圖、狀態圖採用UML標準符號繪製。推薦使用CASE工具如：Ritional Rose畫好後再粘貼到Word文檔中。

如果時間充裕的話，應在輔助工具中進行業務建模，將非功能需求以及資料部分做為單獨文檔連接到模型中。