第一篇：需求分析報告

測試（驗收）大綱

目錄

1.引言....................................................................2 1.1 目的...................................................................2 1.2 術語...................................................................2 1.3 參照標準...............................................................2 2.測試日期安排............................................................3 3.測試小組及成員..........................................................3 4.測試具體內容............................................................3 4.1 合法性檢查.............................................................3 4.2 軟件文檔檢查...........................................................3 4.2.1 必須提供檢查的文檔...................................................3 4.2.2 其他可能需要檢查的文檔...............................................4 4.2.3 由業主確定必須檢查的其他文檔.........................................4 4.2.4 文檔質量的度量準則...................................................4 4.3 軟件代碼測試...........................................................4 4.3.1 源代碼一般性檢查.....................................................4 4.3.2 軟件一致性檢查.......................................................5 4.4 軟件系統測試...........................................................5 4.4.1 界面(外觀)測試.......................................................6 4.4.2 可用性測試...........................................................6 4.4.3 功能測試.............................................................6 4.4.4 穩定性(強度)測試.....................................................6 4.4.5 性能測試.............................................................6 4.4.6 強壯性(恢復)測試.....................................................6 4.4.7 邏輯性測試...........................................................6 4.4.8 破壞性測試...........................................................6 4.4.9 安全性測試...........................................................7 5.測試結果交付方式........................................................7

1.引言

1.1 目的

為了盡可能的找出軟件的不足，提高軟件的質量，促進軟件的成功驗收，專門制定了本大綱。其主要目的在于為所要進行的測試工作制定各種必要的準則和規范，以及在有關方面協議的基礎上對測試工作進行合理組織與管理。

1.2 術語

本大綱所提及的術語，其定義遵照GB/T 11457標準。

1.3 參照標準

● GB/T 11457—1995 軟件工程術語

● GB 8566—1995；

信息技術軟件生存期過程 ● OGB8567—1988* 計算機軟件產品開發文件編制指南 ● GB 9385* 計算機軟件需求說明編制指南 ● GB 9386—1988* 計算機軟件測試文件編制指南 ● GB/T 12504—1990 計算機軟件質量保證計劃規范 ● OGB/T 12505—1990 計算機軟件配置管理計劃規范 ● OGB/T 14079—1993 軟件維護指南

● OGB/T 14394—1993 計算機軟件可靠性和可維護性管理 ● GB/T 16680一1996 軟件文檔管理指南 ● 開發者企業規范

軟件開發者有關軟件工程的規范 ● 其它文件

例如：合同書等，法律文件中的有關規定。

說明：（1）應該遵循自頂而下、就嚴不就寬的原則，除非合同書等法律文件中另有規定。

（2）標記（*）號的標準為推薦標準。

2.測試日期安排

開發方如期交付軟件的基礎上，由業主審核確定具體日期安排。

3.測試小組及成員

由業主聘請具有一定的分析、設計、編程和軟件測試經驗的測試組長和其他專業人員組成。測試組設組長一名(可設有副組長)，負責整個測試的計劃、組織工作。

或委托具有國家認可測試資質的第三方進行測試。

4.測試具體內容

測試內容應該包括：合法性檢查、文檔檢查、軟件一致性檢查、軟件系統測試與測試結果評審等幾項工作。

4.1 合法性檢查

檢查開發者在開發本軟件時，使用的開發工具是否合法。對在編程中使用的一些非本單位自己開發的，也不是由開發工具提供的控件、組件、函數庫等，檢查其是否有合法的發布許可。

4.2 軟件文檔檢查

4.2.1 必須提供檢查的文檔

● 項目實施計劃； ● 詳細技術方案；

● 軟件需求規格說明書(STP)(含數據字典)； ● 概要設計說明書(PDD)；

● 詳細設計說明書(DDD)(含數據庫設計說明書)； ● 軟件測試計劃(STP)(含測試用例)； ● 軟件測試報告(STR)；

● 用戶手冊(SUM)(含操作、使用、維護、應急處理手冊)； ● 源程序(SCL)(不可修改的電子文檔)； ● 項目實施計劃(PIP)； ● 項目開發總結(PDS)；

● 軟件質量保證計劃(SQAP)；

4.2.2 其他可能需要檢查的文檔

● 軟件配置計劃(SCMPP)； ● 項目進展報表(PPR)； ● 階段評審報表(PRR)； 4.2.3 由建設方確定必須檢查的其他文檔

說明：如果建設方認為4.1.1節和4.1.2節所列文檔之外，還需要檢查其它文檔，則在此列出文檔名稱；如果業主認為不需要進行額外的文檔檢查，則本部分無內容。4.2.4 文檔質量的度量準則

文檔是軟件的重要組成都分，是軟件生存周期各個不同階段的產品描述。文檔質量的度量準則就是要評審各階段文檔的合適性。主要有以下六條：

● 完備性

開發方必須按照GB 8567(計算機軟件產品開發文件編制指南)的規定編制相應的 文檔，以保證在開發階段結束時其文檔是齊全的?！?正確性

在軟件開發各個階段所編寫的文檔的內容，必須真實的反映階段的工作且與該階 段的需求相一致?！?簡明性

在軟件開發各個階段所編寫的各種文檔的語言表達應該清晰、準確簡練，適合各 種文檔的特定讀者。● 可追蹤性

在軟件開發各個階段所編寫的各種文檔應該具有良好的可追蹤性。文檔的可追蹤 性包括橫向可追蹤性和縱向可追蹤性兩個方面。前者是指在不同的文檔的相關內 容之間相互檢索的難易程序；后者是指確定同一文檔某一內容在本文檔范圍中檢 索的難易程度?！?自說明性

在軟件開發各個階段所編寫的各種文檔應該具有較好的自說明性。文檔的自說明 性是指在軟件開發各個階段中，不同文檔能夠獨立表達，該軟件在其相應階段的 階段成果的能力?！?規范性

在軟件開發各個階段所編寫的各種文檔應該具有良好的規范性。文檔的規范性是 指文檔的封面、大綱、術語的含義以及圖示符號等符合有關規范的規定。

4.3 軟件代碼測試

4.3.1 源代碼一般性檢查

僅對系統關鍵模塊的源代碼進行抽查，檢查模塊代碼編寫的規范性，批注的準確性，是否存在潛在性錯誤，以及代碼的可維護性。

● 命名規范檢查

檢查源代碼中的變量、函數、對象、過程等的命名是否符合約定規范，該規范可 以由開發方在軟件工程文檔規范中單方面約定。

● 注釋檢查

檢查程序中的注釋是否規范，注釋量是否達到約定要求，例如：要求注釋量達到 30％左右。● 接口檢查

檢查數據庫接口等外部接口是否符合要求，各程序模塊使用的接口方式是否一 致，特定的外部接口協議是否符合?！?數據類型檢查

源代碼中涉及的金額的常量、變量及數據集和數據庫中涉及金額的數據類型是否 采用貨幣類型，以防止在特定條件下產生較大的誤差而影響統計結果。● 限制性檢查

對一些程序中使用到的、具有使用限制的命令、事件、方法、過程、函數、對象、控件等進行檢查。檢查在長時間運行時，有無可能接近或者達到限制條件，這里考慮的系統運行時間可能長達數年。

4.3.2 軟件一致性檢查

● 編譯檢查

要求提交的源代碼在其規定的編譯環境中，能夠重新編譯無錯誤，并且能夠完成 相應的功能，從而確定移交的確實是正確的源代碼。● 安裝／卸載檢查

在新系統上用交付的軟件安裝盤重新安裝各個模塊，并且通過運行這些軟件模 塊，能否完成相應的功能，從而確定移交的確實是正確的軟件安裝盤。在安裝后立即卸載所安裝的模塊，并且檢查是否能夠做到徹底卸載?！?運行模塊檢查

將新安裝的軟件模塊與現場運行模塊用軟件工具抽樣比較，確認交付的軟件安裝 盤與現場運行軟件一致。

抽查數處現場運行模塊用軟件工具比較，確認現場運行軟件一致。

4.4 軟件系統測試

軟件系統測試不僅是檢測軟件的整體行為表現，從另一個側面看，也是對軟件開發設計的再確認。

進行軟件系統測試工作時，具體的測試用例是由開發方提供，并由測試方和用戶共同補充制定的。在開發方做完功能演示后，可以進行下列測試：

● 界面(外觀)測試； ● 可用性測試； ● 功能測試；

● 穩定性(強度)測試； ● 性能測試；

● 強壯性(恢復)測試； ● 邏輯性測試； ● 破壞性測試； ● 安全性測試。說明：實際進行的測試內容有測試方法和業主根據具體情況共同確定，并非文中所列測試內容都必須進行測試。

4.4.1 界面(外觀)測試

對照界面規范(在軟件需求規格說明書中規定，或者由軟件工程規范中給出)和界面表(在概要設計中給出)，檢查各界面設計是否規范，包括：界面風格、表現形式、組件用法、字體選擇、字號選擇、色彩搭配、日期表現、計時方法、時間格式、對齊方式等等，是否符合規范、是否協調一致、是否便于操作。4.4.2 可用性測試

測試操作是否方便，用戶界面是否友好等。測試系統是否有影響操作流程的界面Bug和功能Bug，紀錄具體Bug的數量、出現頻率和嚴重程度。4.4.3 功能測試

檢查數據在流程中各個階段的準確性。對系統中每一模塊利用實際數據運行，將其結果與同樣數據環境下應該得出的結果相比較，或與軟件需求規格說明書中要求的結果進行比較，如有偏差，則功能測試不能通過。

檢查軟件需求規格說明書中描述的需求是否都得到滿足；系統是否缺乏軟件需求規格說明書中規定的重要功能；以及系統實際使用中不可缺少而軟件需求規格說明書中沒有規定的功能。

如果存在遺產數據，應該檢查遺產數據轉換是否正確。4.4.4 穩定性(強度)測試

測試系統的能力最高實際限度，即檢查軟件在一些超負荷情況下，功能實現的情況。例如：要求軟件進行某一行為的大量重復、輸入大量的數據或大數值數據、對數據庫進行大量復雜的查詢等。

利用邊界測試(最大值、最小值、N次循環)對系統進行模擬運行測試，觀察其是否處于穩定狀態。4.4.5 性能測試

根據系統設計指標，或者對被測軟件提出的性能指標，測試軟件的運行性能，例如：傳輸連接最長時限、傳輸錯誤率、計算精度、記錄精度、響應時限和恢復時限等。4.4.6 強壯性(恢復)測試

采用人工的干擾使應用軟件、平臺軟件或者系統硬件出錯，中斷正常使用，檢測系統的恢復能力。進行強壯性測試時，應該參考性能測試相關的測試指標。4.4.7 邏輯性測試

根據系統的功能邏輯圖，測試軟件是否按規定的邏輯路徑運行，選擇一些極限數據判斷軟件運行是否存在錯誤或非法路徑，從而發現系統的邏輯錯誤或非法后門。4.4.8 破壞性測試

輸入錯誤的或非法的數據(類型)，檢查系統的報錯糾錯的能力及穩定性。并測試可連續使用多長時間而系統不崩潰。

4.4.9 安全性測試

驗證安裝在系統內的保護機構確實能夠對系統進行保護，使之不受各種非常的干擾，安全測試時需要設計一些測試用例試圖突破系統的安全保密措施，檢驗系統是否有安全保密的漏洞。

說明：進行安全測試時，必須遵循相關的安全規定，并且有業主派員參加。

5.測試結果交付方式

測試結束后，由測試組填寫軟件測試報告，并將測試報告與全部測試材料一并交給業主。具體交付方式，由業主和測試方雙方協商確定。測試報告包括下列內容：

● 軟件測試計劃 ● 軟件測試日志 ● 軟件文檔檢查報告 ● 軟件代碼測試報告 ● 軟件系統測試報告 ● 測試總結報告

● 測試人員簽字登記表

第二篇：需求分析報告

。

需求分析報告

**系統需求分析報告

目錄

一、項目概述篇............................................................................................................1 引 言................................................................................................................1 2 項目背景（包括行業背景、企業基本情況、項目可行性等）..................2 3 項目意義..........................................................................................................3 4 項目總體需求..................................................................................................4 5 項目總論..........................................................................................................4

5.1 預期目標................................................................................................4 5.2 項目預期安排........................................................................................4 5.3 項目范圍................................................................................................5 6 方案概要..........................................................................................................6

6.1 業務需求................................................................................................6 6.2 功能分析................................................................................................6 6.3 系統設計................................................................................................6 6.4 安全策略................................................................................................6 6.5 項目亮點................................................................................................7

二、業務需求分析篇....................................................................................................9 行政審批系統業務分析................................................................................11

1.1 收件業務..............................................................................................11

三、功能分析篇..........................................................................................................14 行政審批系統功能分析................................................................................15

1.1 總體需求..............................................................................................15 1.2 功能模塊劃分......................................................................................17 1.3 功能需求描述......................................................................................17

四、技術分析篇..........................................................................................................19 系統總體設計思路........................................................................................21

1.1 技術及功能要求..................................................................................21 1.2 技術特點（以下為示例）..................................................................21 2 總體架構........................................................................................................22

2.1 系統技術架構......................................................................................22 2.2 系統平臺架構......................................................................................22 3 服務器與系統部署策略................................................................................23

3.1 應用服務器選型..................................................................................23 3.2 數據庫選型..........................................................................................23 3.3 操作系統選型......................................................................................23

五、系統安全策略篇..................................................................................................24 系統安全保障................................................................................................25 2 權限控制管理................................................................................................25

2.1 權限模型的實現..................................................................................25 2.2 應用權限的實現..................................................................................25 2.3 數據權限的實現..................................................................................25

**系統需求分析報告 數據傳輸安全性............................................................................................25

3.1 數據加密..............................................................................................25 3.2 數據傳輸..............................................................................................25 4 防火墻系統....................................................................................................2

5**系統需求分析報告、項目概述篇

一

**系統需求分析報告 引 言

進入到二十一世紀，伴隨信息技術的發展，圍繞Internet的技術日漸成熟，信息技術的應用已經滲透到社會生活的各個層面，成為一種生活方式，吸引了社會大眾廣泛參與。信息技術是當今最具潛力的新興生產力，已成為衡量一個國家、一個地區生產力發展水平的最重要標志。

以知識經濟為特點的網絡時代的到來，推動了社會信息化和經濟信息化的快速發展，也給國家政府部門的工作提出了更快捷、高效的信息化要求。對于政府來講，互聯網絡不僅是一種有效的通訊手段，更是一座溝通政府與社會各界的橋梁。從全球范圍來看，推動政府部門管理工作的信息化，實現信息共享已是大勢所趨，在世界各國積極倡導的“信息高速公路”的5個應用領域中，電子政務被列為第一位，這也標志了電子政務進入啟動期。

電子政務的啟動帶來了政府管理決策機制的巨大轉變，使得政府更能貼近社會公眾，從滿足公眾需求出發，建立更好的服務體系。同時，網絡技術的成熟和網絡經濟的實踐探索，也為電子政務的發展打破了許多技術和應用等層面的壁壘。政府在信息化的主導推動地位日益增強，與以往不同的是，這種地位更多地體現在改革內部工作流程以更好地服務于公眾。所以，在電子政務的啟動期，政府起到了從“主演”到“導演”的角色轉變。這也意味著電子政務的發展極大地推動了全社會信息化。

黨的十六大報告中關于建設電子政務的闡述，為我國電子政務的發展指明了方向：“進一步轉變政府職能，改進管理方式，推行電子政務，提高行政效率，降低行政成本，形成行為規范、運轉協調、公正透明、廉潔高效的行政管理體制”。

**系統需求分析報告 項目背景（包括行業背景、企業基本情況、項目可行性等）

**系統需求分析報告 項目意義

隨著信息技術和網絡經濟的崛起，信息產業己成為當今世界經濟與社會發展最主要的驅動力之一。政府行政管理信息化可簡稱為政務信息化，實現政務信息化的重要手段是電子政務的發展。電子政務是政府機構應用現代信息和通信技術，將管理和服務通過網絡技術進行集成，在互聯網上實現政府組織結構和工作流程的優化重組。電子政務在世界許多國家得到迅速的發展，主要在于它具有不可替代的特殊功能。電子政務的功能是：借助現代信息技術的力量，全面提高政府管理的效能，全面提高政府公共服務的水平和政府競爭力。具體體現如下：

? 加強政府公眾關系：政府主要職能是對公眾服務，電子政務推動了政府職能的變革，實現了政府的職能由管理型向服務型的轉化。將CRM模式在客戶服務領域的相關思想和方法用于電子政務領域，能使政府更好地了解公眾需求，不斷提高政府服務的質量，提升公眾的滿意度和擁護度，取得更大的社會效益和經濟效益。因此，電子政務要借鑒電子商務的成功經驗，積極主動地實施客戶關系管理戰略。? 促進政府流程再造：電子政務不僅僅將現有的政府業務流程進行電子化，而更重要的是對現有的政府進行業務流程的改造。電子政務要求政府機關各職能部門打破固有的工作模式，以事務為中心。電子政務能有效降低政府成本。流程優化精簡政府機構、減少管理層次和中間控制環節、擴大管理幅度、精簡政府冗員，降低管理成本；政府的網上采購，實現公開公平競爭；政府部門之間跨部門、跨地區的公文電子化處理，實現 “無紙化”辦公，可以減少行政辦公費用和公文處理的費用，降低政府的辦公成本。因此，電子政務環境下的政府行政流程再造是以提高行政效率為目的，通過消除政府管理與服務的間斷和空白點，實現政府運行的協調性。

? 促成政務公開機制：電子政務的實施使得政府辦公更為透明，從而使得信息傳遞渠道更為暢通。電子政務可以防止信息被少數人壟斷或者選擇性的公開，可以防止信息被更改、掩蓋，可以建立一套相對嚴格的制度，將信息交給計算機處理，防止人為的干預。同時，電子政務中的信息管理系統可以對任何人的任何行為進行監控，從而增加政府辦事的透明度，增加腐敗的機會成本。電子政務在推動政府縮小貧富差距和反腐敗方面發揮著重要作用。

? 改善政府績效評估：績評估對于提高政府績效管理有直接的促進功能，是整個績效管理體系的基礎環節和核心功能。完善的電子政務績效評估應該綜合 “產出”、“結果”和 “影響”三個層次。通過電子政務績效評估，有利于切實改善政府績效，有利于有效抵御電子政務建設風險，有利于培養政府績效文化。

**系統需求分析報告 項目總體需求

? 系統硬件：通過本項目對搭建**公司行政管理信息化平臺所需要的設備進行采購，改進和完善**公司現有的內部和外部網絡系統，為信息的傳遞鋪平“道路”，為城市建設與環境的管理打下基礎。

? 系統軟件：系統的軟件分為三部分，第一部分為系統基礎軟件如：操作系統，數據庫等，通過本項目進行采購；第二部分為各科室已有的專業業務處理軟件，通過整合使這些系統的業務數據為系統數據庫提供數據來源；第三部分為通過本項目新開發的各個子系統。

? 系統網絡：系統的網絡由政務內網和政務外網兩部分組成。政務內網是**公司各部門內部辦公業務網；政務外網是全區建設部門的對外業務專網和信息發布平臺。

? 信息安全：通過建立健全的管理措施和安全設備采購相結合的方法，在管理和技術兩個方面加強信息網絡資源的安全保障和保密，增強網絡的可靠性、安區性、保密性和穩定性。項目總論 5.1 預期目標

通過本項目將達到如下四項主要技術指標：

? 到2010年末實現建設項目可以通過信息化平臺審批。

? 辦公效率全面提高，建設項目在**公司審批的總時限縮短30％以上。? 實現**公司日常辦公費用降低30％以上。? 全面實現**公司信息發布的網絡化。

5.2 項目預期安排

? 2009年2月－2009年12月，完成重慶市**公司信息化平臺建設所需要實現的建設項目管理系統、行政審批子系統、內部行政OA子系統、觸摸屏系統及LED電子屏顯示、信息發布子系統和資源整合與共享子系統的開發和完善。

2009年2月25日－4月15日，完成重慶市**公司信息化平臺建設所需要實現的建設項目管理系統、行政審批子系統、行政辦公OA子系統、信息發布子系統和資源整合與共享子系統的需求分析，提出系統建設方案。

2009年4月16日－5月31日，完成重慶市**公司區建設信息化平臺的整個系統框架搭建，形成系統展示主頁面。

2009年6月1日－10月1日，行政審批子系統開發工作量完成一半，完成 4

**系統需求分析報告

內部行政OA子系統及對外宣傳信息。

2009年10月2日－12月31日，完成行政審批子系統。

? 2010日1月－2010年12月，依托信息化平臺建設，**公司逐步建成集數據信息的采集、存儲、加工、交換和發布為一體的信息中心。通過對信息資源的整合，達到信息資源的綜合利用，實現高效、快捷、準確的信息傳遞和行政管理效率與效能全面提升。

? 2010年7月－2010年12月，充分利用信息化平臺中積存的歷史數據，利用先進的數據挖掘技術，對各類建設數據進行再加工和處理，確保信息化平臺實現顯著的社會效益和經濟效益，建立完善的信息安全審計系統和績效考核系統，并在重慶與西部地區推廣該項目的經驗。

5.3 項目范圍

5.3.1 應用系統的開發與建設

包括行政審批系統，具體內容包括：可以實現行政審批的電子政務、建設項目過程控制及監管、內部辦公自動化及網絡共享、對外信息發布、建設相關企業及工程師管理以及資源整合與共享。

5.3.2 網絡基礎設施建設以及網絡軟、硬件平臺建設 5.3.3 門戶網站建設

**公司門戶網站要建成集信息服務和網上辦公為一體的多功能網站，并實現綜合信息集中發布，部門網站統一導航。

5.3.4 安全保密體系建設

建立安全認證和授權體系，為**公司工作人員提供證書服務；部署入侵檢測、漏洞掃描、防病毒等安全措施，初步建立**公司電子政務網的安全保密體系，有效保證系統的安全性。

**系統需求分析報告 方案概要 6.1 業務需求

本篇分為行政審批業務需求分析

對每個業務進行了業務描述、審查依據、申報條件、輸入數據、輸出數據、業務處理過程、處理時限、業務指導科室和業務流程圖的梳理和確認。對項目動態管理過程進行了階段劃分和描述。

這部分主要是對現階段**公司工作的調研工作的展示，引導接下來功能設計、初步設計。

6.2 功能分析

對系統主要功能進行描述。

6.3 系統設計

本篇首先給出了系統的整體設計思路，對各個系統進行了功能模塊分析。并對整個系統進行了整體架構，**公司信息平臺的整體構架采用SOA的體系構架，以松散耦合的方式公開業務服務，使**公司的各個業務單元輕松地使用和組合這些業務服務。本架構設計方法論采用SunTone 3D 架構方法論，SunTone 3D 架構方法論是Sun公司推出的一套成熟的系統架構分析設計的方法和標準。SunTone 3D架構方法論從列（Tier），層(Layer)和系統質量(System Quality)三維的角度來分析一個完整的系統。技術路線是參考目標系統的靜態和動態特性分析，為架構設計設定的高層技術方案選擇范圍。整個架構方案的設計圍繞選定的技術路線，并以之作為各項系統機制實現的技術基礎。本系統的軟件架構設計在技術路線選擇時綜合考慮運行效率、開發效率以及隨需應變能力的平衡能力。

6.4 安全策略

整個**公司行政辦公信息平臺是一個統一的整體結構，使用統一的安全體系結構來配置資源。主要包括以下幾個方面：

? 系統日志管理：功能日志、系統日志； ? 信息傳輸安全：數據加密、網絡分段；

? 信息存儲安全：服務器安全、數據備份和恢復、異地容災； ? 信息訪問安全：防火墻、身份認證、漏洞掃描、入侵檢測； ? 系統環境安全：操作系統安全、防病毒體系。

? 應用系統安全：CA身份認證、用戶權限管理、安全配置管理； 在采用安全設備及安全技術的同時，還需要制定嚴密的安全管理體制和安全 6

**系統需求分析報告

管理制度共同構建系統安全體系。

6.5 項目亮點

? 實現信息共享，信息整合，能隨時獲取項目審批狀態的信息； ? 方便的流程管理和流程定制，兼顧了行政審批流程變動（如大部委制）帶來的變動需求；

? 靈活的網站信息發布方式及管理；

? 統一身份認證及統一授權，操作方便，安全及權威得到保障。

**系統需求分析報告、業務需求分析篇9 二

**系統需求分析報告 行政審批系統業務分析 1.1 收件業務

1.1.1 業務描述

對報建單位提交的相關資料進行清點，齊全填寫受理通知單后將資料移交下一受理環節，否則退件。

1.1.2 輸入數據

1.1.2.1 內部已有數據（以后環節需要的數據）

各審查環節資料目錄信息

1.1.2.2 手工錄入數據（本環節新增加的數據）

（1）接發件備查表（包括以下信息）：接件日期、工程名稱、工程地址、建設單位、聯系人、電話、審批類型、是否退件；

（2）受理通知單；（3）工作受理單。

1.1.3 輸出數據

1.1.3.1 內部流轉數據（以后環節需要的數據）

（1）接發件備查表（包括以下信息）：接件日期、工程名稱、工程地址、建設單位、聯系人、電話、審批類型、是否退件；

（2）工作受理單。

1.1.3.2 外部數據（打印或顯示輸出的數據）

（1）受理通知單；（2）退件通知單；（3）工作受理單。

1.1.4 資料附件

1.1.4.1 報件資料（本環節需報建單位提供的資料）

根據具體審批環節提供相關材料

1.1.4.2 內部流轉資料（通過內部流轉獲取的資料）

無

1.1.4.3 發放資料（發給報建單位的資料）

（1）受理通知書；（2）退件通知書。

**系統需求分析報告

1.1.4.4 留存資料（內部留存需要存檔的資料）

1.1.5 業務處理過程

（1）報建單位通過網上報建填寫相關申請表（可選）；

（2）建設單位向接件窗口提交各種審批相關材料及相關申請表；（3）接件員核對材料后向申請人出具受理通知單或退件通知單；（4）接件員填寫工作受理單及接發件備查表；（5）接件員將相關材料遞送至**公司審批人員。

**系統需求分析報告

1.1.6 業務流程圖

圖名：發件流程圖 圖號：B00 制圖：武建軍 審核：報建單位接發件窗口審核提交報建資料新增報建資料（各環節不同）和內部發放表格判定審批環節審核新增資料F資料齊全或加急T受理通知單收審核件收件整合（報建資料和內部流轉資料）整合的報建資料工作受理單報建資料移交收件整合移交相關環節技術審查退件通知單報建資料退件處理退件

**系統需求分析報告

三、功能分析篇4

1**系統需求分析報告

功能分析是在業務分析的基礎上，從軟件功能實現的角度對**公司信息化平臺進行模塊劃分，把**公司信息化平臺分為功能相對獨立但又彼此聯系的6個功能子系統，并提出各子系統的功能需要，是下一階段系統分析和設計過程的設計依據。主要包括后臺管理系統、行政審批系統、辦公自動化系統、建設項目動態管理系統、網站發布系統、資源交換與共享系統。以上功能子系統建立在統一的軟件平臺之上，軟件平臺是各子系統共同的基礎平臺，主要包括統一認證單點登錄、數據信息標準、角色權限分配等。行政審批系統功能分析

行政審批系統作為整個《**公司信息化平臺》的基礎平臺，對后期系統開發起到數據支撐；同時也是當前**公司在電子政務建設中最為迫切的部門；行政審批系統設計開發的好壞直接關系到后續系統的開發；所以對于行政審批系統要做到系統運行穩定，功能完整實用，操作方便易用，具有充分的擴展性和前瞻性。

1.1 總體需求

1.1.1 規范性

? 項目管理為主線，項目具有唯一“身份證”，每個建設項目在不同的審批業務中具有相同的項目編號，但有不同的業務編號。? 嚴格按流程進行審批，保證審批流程的透明化。? 統一**公司信息化數據標準。? 企業信息“一次性錄入，重復使用”。

? 智能業務時限預警。? 節假日設定。

1.1.2 先進性

支持系統像積木一樣隨時進行搭建和改造，根據管理的需要對系統模塊進行增加和刪除，不斷補充系統生命力，實現系統可持續發展，確保系統在較長時間內保持先進性。

1.1.3 靈活性

考慮到大部委制部門調整的要求，將來**公司的審批業務有可能增加或減少，報建資料可能由來自外部改變為內部流轉資料，對可能增加的審批業務預留接口，需要時可以隨時激活使用，并可以對審批業務的前置環節和后置環節進行動態調整。

1.1.4 易用性

? 自定義個人桌面

**系統需求分析報告

? 常用審批意見 ? 待辦提示 ? 審批進度瀏覽 ? 短信提醒

1.1.5 安全性

? 安全的數據傳輸

? 多級身份認證策略：通過用戶口令等實現用戶身份認證 ? 可集成CA身份認證 ? 可集成電子簽章

1.1.6 可持續性

? 界面可調整 ? 報表可定制 ? 流程可按需調整 ? 系統預留擴展接口

**系統需求分析報告

1.2 功能模塊劃分

企業用戶注冊項目申報項目咨詢IC卡管理網上申報子系統項目審批查詢意見反饋受理新審批項目修改項目待辦項目急辦件快速受理刪除項目在辦項目項目中止待辦事務項目報延項目催辦項目回收項目會簽在崗狀態設置項目收費管理信息發布工作移交數據導出行政審批系統項目預警項目辦結項目辦理審批業務子系統領導督辦項目退回已辦事務項目分件事務臨時授權企業信息管理手機短信通知顯示自定義項目查詢子系統項目精確查詢項目組合查詢數據統計項目模糊查詢自定義條件查詢 圖 3.1-1 功能模塊劃分

1.3 功能需求描述

1.3.1 網上申報子系統

1.3.1.1 企業用戶注冊

提供報建單位的預約注冊和正式注冊功能，企業用戶可以在網上進行預約注冊，輸入企業用戶基本信息，然后到行政大廳進行正式注冊，并辦理IC卡。注冊后可以登陸系統，登錄后對企業用戶個人信息的登記，修改，密碼的修改，用戶個性化設置，系統的在線幫助。

**系統需求分析報告

1.3.2 審批業務子系統

1.3.2.1 業務受理

由收發件窗口受理，也可以從網上申報系統受理，并自動生成項目編號及業務編號；項目資料錄入完成后可以直接進行提交到下一辦理環節；此時系統生成一個在辦項目紀錄，收發件窗口可以隨時查詢在辦項目的辦理情況；如果不進行提交而是保存的話，系統將生成一條待辦項目紀錄等待窗口人員進行提交。

1.3.3 項目查詢子系統

主要是用于業務辦理情況查詢，分為四種方式：精確查詢、模糊查詢、組合查詢、自定義條件查詢。查詢項目包括：時間查詢、業務查詢、基本信息查詢、項目查詢、人員查詢、單位查詢、辦結查詢、辦理步驟查詢、辦理時限查詢，其他自定義查詢等。

在查詢結果中的目錄列表中，系統將自動以顏色區分的方式來直觀的表示出警告件和超時件，其中警告件是黃色，超時件是顯示紅色。1.3.3.1 精確查詢

通過嚴格匹配輸入的查詢條件來快速準確的查詢某個項目。

查詢結果目錄中所顯示的信息有：項目基本信息、項目受理信息、項目辦理信息、項目申報人信息、項目辦理人信息等。

**系統需求分析報告、技術分析篇

四

**系統需求分析報告 系統總體設計思路 1.1 技術及功能要求

1.1.1 技術要求（以下為示例）

1.1.1.1 穩定可靠的數據平臺 1.1.1.2 快速準確的決策支持 1.1.1.3 很好的開放性和可擴展性

1.1.1.4 同時基于虛擬專用網及互聯網的快速實時查詢

1.1.1.5 采用方便實用的BROWSE/SERVER方式，真正實現數據的集中處理和管理

1.1.1.6 支持分級動態數據查詢、匯總及分析。

1.1.2 功能要求（以下為示例）

1.1.2.1 集中管理 1.1.2.2 流程化審批 1.1.2.3 動態匯總 1.1.2.4 動態查詢 1.1.2.5 動態適應和調整 1.1.2.6 動態分析 1.1.2.7 電子監察

1.2 技術特點（以下為示例）

1.2.1 面向服務的體系結構 1.2.2 采用中間件技術 1.2.3 動態查詢技術 1.2.4 動態匯總技術

1.2.5 基于策略的動態生成技術 1.2.6 采用大型數據庫技術

**系統需求分析報告 總體架構 2.1 系統技術架構

2.1.1 架構體系分層說明 2.1.2 系統總體技術架構圖

2.2 系統平臺架構

**系統需求分析報告 服務器與系統部署策略 3.1 應用服務器選型 3.2 數據庫選型 3.3 操作系統選型

**系統需求分析報告

五、系統安全策略篇 24

**系統需求分析報告 系統安全保障 2 權限控制管理 2.1 權限模型的實現 2.2 應用權限的實現 2.3 數據權限的實現 3 數據傳輸安全性 3.1 數據加密 3.2 數據傳輸 4 防火墻系統

第三篇：需求分析報告

需求分析

需求概述

需求分析是是指充分了解客戶情況，包括客戶生產、財務及管理流程后，與客戶一起討論對系統的具體要求，針對其現行體制中的不足及目前所需的信息，制定出一套用戶對系統的需求方案。需求分析是完全以企業的需要及實際情況為出發點，因此為企業合理地選擇系統提供了基本保證。需求分析按照由頂至低、由大到小、由粗到精的的過程來進行。需求分析是整個實施過程中至關重要的一步，是否制定出合理的客戶需求決定了以后整個系統實施的成敗。

1> 用戶分析

網上訂餐系統的使用者主要有兩種：系統管理員、客戶。

系統管理員：網上訂餐系統的系統管理者，進行系統的日常維護，進行日常管理，并按照餐廳的意愿，對菜譜和客戶的信息進行各種管理，比如添加、修改、刪除、更新等。

客戶：網上訂餐系統的主要在使用者，他們是餐廳的客戶，能進行基本功能的使用和操作，但是不能對系統進行管理。

2> 項目功能需求

管理員功能：登陸系統、查詢管理員賬戶、添加管理員賬戶、修改管理員賬號、刪除管理員賬號、查詢訂餐情況刪除訂單、打印訂單。

客戶功能：注冊賬號、登錄系統、修改密碼、修改地址、進行訂餐操作。3> 用戶界面需求

系統人機界面操作友好，本系統外界界面具有簡潔性和友好性等特點，但又不失獨特的頁面風格，界面采用引入的圖片溫馨的色調，優雅大方，系統內部結構采用框架布局，使整個系統看起來更有層次感，在用戶功能操作功能上，設計簡單方便，符合了現代管理系統的界面要求。

系統開發的可行性分析

技術可行性

ASP.NET和SQL數據庫這兩個開發工具到現在已經運用了很多少年了，它們的技術到現在已經相當成熟。

本系統所要設計的功能難度不大，加上有指導老師的指導和查找相關參考文獻，各功能模塊在技術上完全是可以的實現。就開發的實際情況來看，技術上市可行的。

經濟可行性

本訂餐系統所需要的硬件和軟件都是目前廣泛使用的，如軟件運行環境windows98以上系統、數據庫SQL Server 2005、編程語言C#等等，都可以通過網上、圖書館等各種渠道得到，不需要再花費大量的資金去購買高成本的設備，大大提高了在設計過程中的工作效率，且投入使用后，便于后期工作的維護，因此，本系統在經濟上是可行的。

社會可行性

該系統符合現有的法律、法規和政策方面的限制，沒違法當今社會的道德標準，社會可行性通過。

運行環境

處理器為酷睿系列、AMD 3200+以上PC臺式機或便攜式電腦；

運行時占用內存：＜100MB；

所需硬盤空間：＜100MB；

軟件平臺：中文WindowsXP系統；

開發環境和相關技術

.NET開發平臺

.NET框架是Microsoft公司推出的一種全新的開發平臺,提供了統一的、面向對象并且可以擴展的編程類庫和完善的集成開發環境,大大簡化了應用程序的開發過程,并且具有良好的移植性和安全性。ASP.NET是建立在公共語言運行庫上的Web編程框架，相對于ASP而言，ASP.NET提供了更強的性能、更方便的工具支持、更好的平臺支持和靈活性。其一大革命性進步是可以將應用程序邏輯與表示代碼清楚地分開，這樣一來Web應用程序的開發人員可以使用和Windows桌面程序開發類似的編程模型，從而大大降低了開發難度 [5]。

同時，ASP.NET在進行用戶界面開發和基礎程序結構生成時具有很多優勢。首先，ASP.NET是一個已編譯的、基于.NET的開發環境，利用整個.NET框架，開發人員可以方便的進行程序開發；其次，ASP.NET可以無縫地與其它HTML編輯器及其編程工具一起工作，使得Web開發更加方便；再次，在ASP.NET中利

用.NET框架中的ADO.NET的強大功能，可以高效便捷的訪問數據庫，ASP.NET提供了簡單的模型，該模型使開發人員能夠編寫應用程序的運行邏輯，并且保留了會話狀態功能；最后，.NET框架和ASP.NET中提供了默認授權和驗證方案，可以根據需要方便地移除、添加或者替換這些方案。

ASP.Net2.0是把基于通用語言的程序在服務器上運行。不像以前的ASP即時解釋程序，而是將程序在服務器端首次運行時進行編譯。ASP.Net2.0構架是可以用Microsoft（R> 公司最新的產品 Visual Studio.net開發環境進行開發，WYSIWYG（What You See Is What You Get所見即為所得> 的編輯。這些僅是ASP.Net2.0強大化軟件支持的一小部分 [6]。

因為ASP.Net2.0是基于通用語言的編譯運行的程序，所以它的強大性和適應性，可以使它運行在Web應用軟件開發者的幾乎全部的平臺上。通用語言的基本庫，消息機制，數據接口的處理都能無縫的整合到ASP.Net2.0的Web應用中。ASP.Net2.0同時也是language-independent語言獨立化的，所以，你可以選擇一種最適合你的語言來編寫你的程序，或者把你的程序用很多種語言來寫，現在已經支持的有C#（C++和Java的結合體>，VB，Jscript。將來，這樣的多種程序語言協同工作的能力保護您現在的基于COM+開發的程序，能夠完整的移植向ASP.Net2.0。

ASP.NET的優點主要體現在效率高、可重用性高、代碼量少這三方面。在使用ASP進行程序設計的時候，由于ASP使用的是腳本語言，所有的代碼都嵌入到HTML代碼中，所以當編制功能復雜的網頁時，就需要編寫大量的代碼，而且會導致程序代碼的可讀性差的問題。另外，由于所有的代碼都是解釋執行的，所以相對速度較慢，并且無法有效地利用機器硬件的各種性能。ASP.NET與ASP相比較效率更高，提供了很高的可重用性，對于實現同樣功能的程序，ASP.NET使用的代碼量比ASP要少得多。ASP.NET采用全新的編程環境，代表了技術發展的主流方向。

ASP.NET的工作原理是：首先，有一個HTTP請求發送到Web服務器要求訪問一個Web網頁。Web服務器通過分析客戶的HTTP請求來定位所請求網頁的位置。如果所請求的網頁的文件名的后綴是aspx，那么就把這個文件傳送到aspnet_isapi.dll進行處理，由aspnet_isapi.dll把ASP.NET代碼提交給CLR。如果以前沒有執行過這個程序，那么就由CLR編譯并執行，得到純HTML結果；如果已經執行過這個程序，那么就直接執行編譯好的程序并得到純HTML結果。最后把這些純HTML結果傳回瀏覽器作為HTTP響應。瀏覽器收到這個響應之后，就可以顯示Web網頁。

ASP.Net2.0使用一種字符基礎的，分級的配置系統，使你服務器環境和應用程序的設置更加簡單。因為配置信息都保存在簡單文本中，新的設置有可能都

不需要啟動本地的管理員工具就可以實現。這種被稱為“Zero Local Administration”的哲學觀念使ASP.Net2.0的基于應用的開發更加具體，和快捷。一個ASP.Net2.0的應用程序在一臺服務器系統的安裝只需要簡單的拷貝一些必須得文件，不需要系統的重新啟動，一切就是這么簡單。

ASP.Net2.0已經被刻意設計成為一種可以用于多處理器的開發工具，它在多處理器的環境下用特殊的無縫連接技術，將很大的提高運行速度。即使你現在的ASP.Net2.0應用軟件是為一個處理器開發的，將來多處理器運行時不需要任何改變都能提高他們的效能，但現在的ASP確做不到這一點 [8]。

Microsoft SQL Server 2005介紹

Microsoft SQL Server 2005 是Microsoft公司繼sql server6.5、sql server7.0和SQL Server 2000以后，在新年推出的又一改進的新版關系型數據管理系統。她能使用戶快捷地管理數據庫和開發應用程序。Sql server 2005使用了先進的數據庫結構，與windows DNA 緊密集成，具有強大的Web功能，它可以利用高端硬件平臺以及最新網絡和儲存技術，可以為最大的Web站點和企業應用提供優良的擴展性和可靠性，使用戶能夠在Internet領域快速建立服務系統，為占領市場贏得寶貴的時間。同時，sql server 2005還為用戶提供重要的安全性功能的增強，為用戶的數據安全提供了可靠的保證。另外，sql server 2005 在數據庫服務器自動管理技術方面處于數據庫領域的領先地位，它可以使用戶免去繁瑣復雜的工作量，從而有精力處理更為重要的問題，使用系統在商業戰略上占得先機。

SQL Server 2005系統之間之所以成為目前流行的大型商用數據庫系統，有著其深刻的內在因素，這與它鮮明的特點十分不開的：

1> 與Internet的高度集成SQL Server 2005與其他Microsoft Back Office 產品緊密集成，在安全、時間瀏覽、Windows NT 服務程序、性能監視器。多處理器支持、索引服務器等方面充分利用了他們的長處，形成了自己獨特的優勢。

SQL Server 2005數據庫索引擎提供完整的XML支持。它還具有構成最大的Web站點的資料存儲組件所需的可伸展性、可用性和安全功能。

2>高伸縮性和適應性

同一SQL Server 2005數據庫引擎運行在、Windows XP Professional、Windows vista Professional、Windows 2000 Professional、windows 2000 Server和windows 2000 Advanced server。

SQL Server 2005 關系數據庫引擎支持當今苛刻的數據處理環境所需的功能。數據庫引擎充分保護資料的完整性，同時將管理上千個并發的修改數據庫的用戶的開銷減到最小。

3>易于安裝和使用

SQL Server 2005 中包括一系列管理和開發工具，這些工具可改進在多個站點上安裝、部署、管理和使用SQL Server 的過程。SQL Server 2005 還支持基于標準的、與Windows DNA集成的程序設計模型，使SQL Server 2000 數據庫和資料倉庫的使用成為生成強大的可伸縮系統的無縫部分。

第四篇：需求分析報告

需求分析報告

綜合要求

一、功能需求

1.1 功能劃分

（1）“衣”子系統

（2）“食”子系統

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

1.2 功能描述

（1）“衣”子系統

實現功能：

1）用戶服裝信息的管理

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

（2）“食”子系統

實現功能：

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

（3）“住”子系統

實現功能：

1）自動調整屋內溫度、濕度、光線和家具（沙發、床）的軟硬程度

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

實現功能：

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

無車用戶：

１）鏈接打車軟件

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

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精度

·對于溫度，濕度要求精確到小數點后兩位。對于能見度等問題需要精確到誤差在３米之內

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）用戶與開發人員很難進行交

（2）用戶的需求是動態變化的（3）系統變更的代價呈非線性增長

二、為什么要需求分析

需求分析具有決策性，方向性，策略性的作用。在軟件分開發過程中具有舉足輕重的作用，大家一定要對需求分析具有足夠重視！

三、需求分析的任務

需求分析的任務就是解決“做什么”的問題，就是要全面地理解用戶的各項要求，并準確的的表達用戶的需求。

四、需求分析的過程

需求分析的階段工作可以分為四個方面：問題識別、分析與綜合、制定規格說明、評審。

主要代碼：

using System;using System.Collections.Generic;using System.ComponentModel;using System.Data;using System.Drawing;using System.Linq;using System.Text;using System.Windows.Forms;

namespace 擲骰子

{public partial class Form1 : Form{public Form1(){InitializeComponent();}

private void btnbegin_Click(object sender, EventArgs e){if(txtname1.Text == “" || txtname2.Text == ”“){MessageBox.Show(”請輸入名字“);

return;}

Random ran1 = new Random(unchecked((int)DateTime.Now.Ticks));int i1 = ran1.Next(1, 7);txtdot1.Text = Convert.ToString(i1);Random ran2 = new Random();int i2 = ran2.Next(1, 7);txtdot2.Text = Convert.ToString(i2);if(i1 == i2){txtresult.Text = ”一樣大“;

}if(i1 > i2){txtresult.Text = txtname1.Text+”大“;

}if(i1 < i2){txtresult.Text = txtname2.Text + ”大";

}}

}