『壹』 物流公共信息平台的作用是什麼功能需求是什麼
公共物流信息平台的建設目的主要在於滿足物流系統中各個環節的不同層次的信源伏息需求和功能需求，這就要求信息平台不僅要滿足貨主、物流企業等對物流過程的查詢、設計、監控等直接需求，還要滿足他們對來自於政府管理部門、政府職能部門、工商企業等與自身物流過程直接相關的信息需求。公共物流雹核攜信息平台在通過對物流公共數據的採集、處理和公共信息交換為企業物流信息系統完成各類功能提供支撐的同時，還起到為政府相關職能部門信息溝通的樞紐作用，從而為政府的宏觀規劃與決策提供信息支持。一個有效集成的公共物流信息平台，應該能夠為物流服務提供商、貨主/製造商、交通、銀行及海關、稅務等政氏鋒府相關部門提供一個統一高效的溝通界面，為客戶提供完整、綜合的供應鏈解決方案。
『貳』 如何推進社區公共服務綜合信息平台建設
三、推進社區公共服務綜合信息平台建設的重點任務
（一）建設社區公共服務信息系統。各地應結合實際，以街道（鄉鎮）為基本單元，應用功能集成、界面規范、部署集中的社區公共服務信息系統，確有需要的可依管理幅度和服務半徑向所轄社區延伸。社區公共服務信息系統應兼具政務事項辦理和基礎信息採集功能，實行「前台一口受理、後台分工協同」的運行模式。統一設立電子政務辦理界面，通過與人口、法人單位等國家基礎信息資源庫的信息共享，建立以公民身份號碼、組織機構代碼等基礎信息為索引的社區公共服務信息管理機制，實現居民身份證辦事「一證通」。按照不同業務的具體需要優化電子政務流程，建立政府主動公開信息、政務辦理痕跡信息和公共管理狀態信息的實時共享機制，實現社區公共服務的跨部門業務協同。積極開發網上咨詢辦理、服務熱線呼叫、現場自助查詢等系統功能，為居民群眾提供網路、電話和窗口服務關聯組合的一體化社區公共服務，為政府決策提供科學依據。
（二）整合社區公共服務信息資源。各地應依託社區公共服務信息系統，加快統籌社區公共服務網路和喊岩信息資源，原則上凡涉及社區居民的公共服務事項，均要逐步納入社區公共服務綜合信息平台集中辦理。加快社區信息系統集約化建設，推動部署在不同層級、不同部門、分散孤立、用途單一的各類社區信息系統向社區公共服務綜合信息平台遷移或集成，最大限度精簡基層業務應用系統、服務終端和管理台帳。在保證數據交換共享安全性的前提下，促進社區公共服務綜合信息平台與現有部門業務應用系統實現互聯互通。推動政府職能部門向基層轉移職能，規范社區公共服務綜合信息平台的信息共享范圍、共享方式和共享標准，逐步豐富社區公共服務綜合信息平台的基本公共服務項目和服務信息，不斷擴大社區政務事項的跨區域通辦范圍。
（三）完善社區公共服務綜合信息平台規劃布局。各地要充分發揮市（地、州、盟）層級電子政務公共平台作用，集中建設社區公共服務綜合信息平台和綜合信息庫，為街道（鄉鎮）及社區開展服務提供便捷渠道和技術支持。支持依託街道（鄉鎮）社區綜合服務設施，建設社區公共服務「一站式」服務機構，統一提供社區基本公共服務的咨詢、辦理和反饋服務。「一站式」服務機構的設施建設或改造應合理布局、科學分區、完善功能，方便居民群眾辦事。根據需要可以依託社區級綜合服務設施，為社區居民提供委託代辦服務，增強社區公共服務的便捷性。
（四）加強社區公共服務綜合信息平台運行管理。各地要建立健全社區公共服務綜合信息平台運行管理機制，明確管理主體和責任，原則上實行平台獨立運行、業務歸口指導的管理模式。制定完善信息採集制度，加強社區信息資源規劃，明確社區信息採集標准，將社區場所、人員、事件御滲磨等信息納入採集范圍，按照一數一源、集中採集、共享校核、及時更新的原則，實現「數據一次採集，資源多方共享」。整合街道、社區層面管理服務力量，加強社區公共服務隊伍建設，實行統一考核、調配和管理，實現同工同酬。強化服務隊伍教育培訓，提高業務素質和服務能力，能夠較好地勝任「綜合服務」的要求，推動服務隊伍的專業化和職業化。建立健全首問負責、限時辦結、績效考核和群眾監督機制，積極引入服務對象滿意度評價和第三方評估，切實提高管理水平和服務質量。
有條件的地區，可以在社區公共服務綜合信息平台基礎上，進一步拓展服務領域和功能，優先發展針對老年人、未成年人、殘疾人、困難群體的系統應用，創新開發針對艾滋病人、精神病人、吸毒人員等特殊人群的特色服務。廣泛吸納社區社會組織、社區服務企業信息資源，促進社區公共服務、便民利民服務、志願互助服務的有機融合和系統集成。完善社區服務信息推送機制，主動及時地為社區居民提供各類公共服務信息和生活服務信息。加強多種網路接入手段間的結合和轉換，大力發展各類信息服務載體和信息服務終端，為社區居民提供「一網式」、「一線式」的綜合服務。
四、推進社區公共服務綜合信息平台建設的保障措施
（一）加強組織領導。在各級黨委政府重視支持下，建立健全社區公共服務綜合信息平台建設協調機制，鎮斗加強與相關部門的溝通協調，形成整體合力。各級民政部門要會同發展改革、公安、工業和信息化、財政等部門做好社區公共服務綜合信息平台建設的統籌規劃、資源整合、設施布局和運行管理等工作，各級工業和信息化部門要指導協調利用各級電子政務公共平台開展社區公共服務應用的頂層設計、平台構建、技術保障和評測評估等工作。
（二）完善籌資機制。建立社區信息化建設多元化籌資機制，加快實施《社區服務體系建設規劃（2011-2015年）》。各地應根據經濟社會發展水平等實際情況，整合政府各部門信息化建設資金項目，逐步提高社區信息裝備條件和社區服務信息化水平，採取財政補助等方式解決社區公共服務信息平台建設經費。鼓勵社會力量參與社區信息化建設，發揮通信運營商、信息服務商和軟硬體供應商在技術、人才、資金和信息基礎設施等方面的優勢，降低社區公共服務綜合信息平台建設和維護成本，支持科研機構和企業研發適合社區需求的信息系統及終端產品。
（三）健全制度標准。加快制定全國社區公共服務綜合信息平台建設標准，規范社區公共服務綜合信息平台設施建設、技術支撐、運行管理和監督考核，切實提高社區公共服務綜合信息平台建設的質量。研究制定全國社區公共服務標准體系，規范社區公共服務項目、服務流程、服務方式、服務質量和服務評價，切實提高服務社區居民的能力和水平。建立健全社區公共服務綜合信息平台居民滿意度評價體系，推動社區信息化建設健康快速發展。及時清理不利於社區公共服務綜合信息平台建設的規章制度，逐步實現社區公共服務的電子化辦理。
（四）強化信息安全。增強社區公共服務綜合信息平台網路、綜合信息庫和各部門業務信息系統的安全防護能力建設，充分利用依法設立的電子認證服務機構，實現面向電子政務內外網與各級各類業務應用的身份認證、訪問授權和責任認定等安全管理，為跨部門、跨區域的業務協同提供安全保障。制定實施與系統應用緊密結合、技術上自主可控的信息安全和保密解決方案，加大安全可靠軟硬體產品應用力度，配備相關技術力量，定期組織開展信息安全風險評估，確保社區公共服務綜合信息平台信息安全。加大對違章違法泄密行為的責任追究和懲罰力度，保護國家和公民的信息安全。
（五）堅持試點推進。健全社區公共服務綜合信息平台長效運行機制，以社區居民最關心和最急需的公共服務為抓手，依託信息惠民國家示範省市建設開展社區公共服務綜合信息平台建設試點工作，著力推進體制機製革新和制度標准創新。在總結試點經驗的基礎上，加大推廣力度，逐步擴大社區公共服務綜合信息平台建設地域覆蓋和項目覆蓋，將社區居民全員納入社區公共服務綜合信息平台服務范圍。全國社區管理和服務創新實驗區、全國和諧社區建設示範單位要率先開展社區公共服務綜合信息平台建設工作。
『叄』 作為客戶,要委託建立一個平台網站,如何提需求
一、建設網站前的市場分析
二、建設網站目的
整合公司資源，確定網站功能。根據公司的需要和計劃，確定網站的功能：產品宣傳型、網上營銷型、客戶服務型、電子商務型等。
根據網站功能，確定網站應達到的目的作用。
三、網站技術解決方案
根據網站的功能確定網站技敗汪術解決方案。
1、採用租用虛擬主機。分析投入成本、功能、開發、穩定性和安全性等。
3、採用系統性的解決方案（如IBM,HP）等公司提供的企業上網方案、電子商務解決方案？還是自己開發。
4、網站安全性措施，防黑、防病毒方案。
5、相關程序開發。如網頁程序ASP、JSP、CGI、資料庫程序等。
四、網站內容策劃
1、根據網站的目的和功能策劃網站內容，一般企業網站應包括：公司簡介、產品介紹、服務內容、價格信息、聯系方式、網上定單等基本內容。
2、電子商務類網站要提供會員注冊、詳細的商品服務信息、信息搜索查詢、定單確認襪漏、付款、個人信息保密措施、相關幫助等。
3、如果網站欄目比較多，則考慮採用網站編程專人負責相關內容。注意：網站內容是網站吸引瀏覽者最重要的因素，無內容或不實用的信息不會吸引匆匆瀏覽的訪客。可事先對人們希望閱讀的信息進行調查，並在網站發布後調查人們對網站內容的滿意度，以及時調整網站內容。
五、網頁設計
1、網頁設計美術設計要求，網頁美術設計一般要與企業整體形象一致，要符合CI規范。要注意網頁色彩、圖片的應用及版面策劃，保持網頁的整體一致性。
2、在新技術的採用上要考慮主要目標訪問群體的分布地域、年齡階層、網路速度、閱讀習慣等。
3、制定網頁改版計劃，如半年到一年時間進行較大規模改版等。
六、網站維護
1、伺服器及相關軟硬體的維護，對可能出現的問題進行評估，制定響應時間。
2、資料庫維護，有效地利用數據是網站維護的重要內容，因此資料庫的維護要受到重視。
3、內容的更新、調整等。
4、制定相關網站維護的規定，將網站維護制度化、規范化。
七、網站測試
網站發布前要進行細致周密的測試，以保證正常瀏覽和使用。主要測試內容：
1、伺服器穩定性、安全性。
2、程序及資料庫測試。
3、網頁兼容性測試，如瀏覽器、顯示器。
4、根據需要的其他測試。
八、網站發布與推廣
1、網站測試後進行發布的公關，廣告活動。
2、搜索引掣登記等。
九、網站建設日程表
各項策劃任務的開始完成時間，負告枯爛責人等。
十、費用明細
---以前網上摘下來作為作業的模板，下面是自己的看法
專業網站設計的人和一般人在功能需求上在溝通上有困難，所以還是找個懂點的人去跟設計人員描述功能，功能主要有：動態新聞發布，留言板，在線咨詢，BBS，上傳下載，再一些顯示日期時間，顯示訪問量什麼
雙方寫合同的時候更要說明白
『肆』 如何對需求進行分析，從哪方面對需求進行分析
需求分析就是對客戶提出的「要求」或者「需求」進行深入細致地調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼，為系統設計、系統完善和系統維護提供依據。
需求分析是項目計劃階段非常重要的環節，該環節決定了需要「實現什麼」，為下一步如何去「實現」提供了明確的方向。
進行需求分析需要做到以下幾點：
（一）需求獲取：在准備階段，我們首先要確定需求獲取的目標及范圍，根據你的目標來選擇對應的方式獲取需求。
（二）需求分類：一般情況下，我們會根據對象的不同，將需求分為業務需求、用戶需求、功能需求等。
（三）需求篩選：有些需求是偽需求，有些需求則不具備實現價值，我們可以通過真實性、價值性、可行性三個維度來篩選需求，過濾掉虛假的、不可行的、沒有價值、價值不大或投入產出比不理想的需求。
（四）需求提煉：對剩下的需求進行提煉，目的在於從獲取的表面需求中提煉出客戶的本質需求。找出「為什麼要做」比「做什麼」更重要。
（五）需求優先順序排序：挖掘到客戶的真實目的後，我們需要根據不同維度的需求歸類方法，如KANO模型分析法、投入產出比ROI等，對其進行歸納整理並排出優先順序，幫助產品有條理地安排開發秩序，避免盲目排序。
（六）產出需求文檔：通過以上的分析，我們需要將收集到的需求進行分析、匯總、歸類，輸出產出需求文檔，為接下來的工作做好鋪墊。
以上是對需求分析的一些理解和思路，做好需求分析工作之後，就可以對可實現的需求進行落地方案的跟進。
『伍』 需求分析的作用及如何進行需求分析
通過對應問題及其環境的理解與分析，為問題涉及的信息、功能及系統行為建立模型，將用戶需求精確化、完全化，最終形成需求規格說明，這一系列的活動即構成軟體開發生命周期的需求分析階段。
需求分析是介於系統分析和軟體設計階段之間的橋梁。一方面，需求分析以系統規格說明和項目規劃作為分析活動的基本出發點，並從軟體角度對它們進行檢查與調整；另一方面，需求規格說明又是軟體設計、實現、測試直至維護的主要基礎。良好的分析活動有助於避免或盡早剔除早期錯誤，從而提高軟體生產率，降低開發成本，改豎悉進軟體質量。
需求工程是隨著計算機的發展而發展的，在計算機發展的初期，軟體規模不大，軟體開發所關注的是代碼編寫，需求分析很少受到重視。後來軟體開發引入了生命周期的概念，需求分析成為其第一階段。隨著軟體系統規模的擴大，需求分析與定義在整個軟體開發與鏈悄維護過程中越來越重要，直接關繫到軟體的成功與否。人們逐漸認識到需求分析活動不再僅限於軟體開發的最初階段，它貫穿於系統開發的整個生命周期。80年代中期，形成了軟體工程的子領域——需求工程(requirementengineering,RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《RequirementsEngineering》。一些關於需求工程的工作小組也相繼成立，如歐洲的RENOIR()，並開始開展工作。
需求工程是指應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題並定義目標系統的所有外部特徵的一門學科。它通過合適的工具和記號系統地描述待開發系統及其行為特徵和相關約束，形成余喚乎需求文檔，並對用戶不斷變化的需求演進給予支持。RE可分為系統需求工程（如果是針對由軟硬體共同組成的整個系統）和軟體需求工程（如果僅是專門針對純軟體部分）。軟體需求工程是一門分析並記錄軟體需求的學科，它把系統需求分解成一些主要的子系統和任務，把這些子系統或任務分配給軟體，並通過一系列重復的分析、設計、比較研究、原型開發過程把這些系統需求轉換成軟體的需求描述和一些性能參數。
需求工程是一個不斷反復的需求定義、文檔記錄、需求演進的過程，並最終在驗證的基礎上凍結需求。80年代，HerbKrasner定義了需求工程的五階段生命周期：需求定義和分析、需求決策、形成需求規格、需求實現與驗證、需求演進管理。近來，MatthiasJarke和KlausPohl提出了三階段周期的說法：獲取、表示和驗證。
綜合了幾種觀點，可以把需求工程的活動劃分為以下5個獨立的階段：
（1）需求獲取：通過與用戶的交流，對現有系統的觀察及對任務進行分析，從而開發、捕獲和修訂用戶的需求；
（2）需求建模：為最終用戶所看到的系統建立一個概念模型，作為對需求的抽象描述，並盡可能多的捕獲現實世界的語義；
（3）形成需求規格：生成需求模型構件的精確的形式化的描述，作為用戶和開發者之間的一個協約；
（4）需求驗證：以需求規格說明為輸入，通過符號執行、模擬或快速原型等途徑，分析需求規格的正確性和可行性；
（5）需求管理：支持系統的需求演進，如需求變化和可跟蹤性問題。
『陸』 如何進行管理信息系統需求調研分析
進行管理信息系統需求分析:
1、明確系統管理目標;
2、確定信息系統總體結構;
3、明確系統的模塊構架;
4、明確系統實施方案.
『柒』 網路需求分析該怎麼做，有哪幾步
網路規劃與需求分析
需求分析從字面上的意思來理解就是找出"需"和"求"的關系,從當前業務中找出最需要重視的方面,從已經運行的網路中找出最需要改進的地方,滿足客戶提出的各種合理要求,依據客戶要求修改已經成形的方案.
本章重點
2.1需求分析的類型
2.2如何獲得需求
2.3可行性論證
2.4工程招標與投標
2.2.1應用背景分析
應用背景需求分析概括了當前網路應用的技術背景蠢緩,介紹了行業應用的方向和技術趨勢,說明本企業網路信息化的必然性.
應用背景需求分析要回答一些為什麼要實施網路集成的問題.
(1) 國外同行業的信息化程度以及取得哪些成效
(2) 國內同行業的信息化趨勢如何
(3) 本企業信息化的目的是什麼
(4) 本企業擬採用的信息化步驟如何
需求分析的類型
P33
2.2.1應用背景分析
應用背景需求分析派咐要回答一些為什麼要實施網路集成的問題.
(1) 國外同行業的信息化程度以及取得哪些成效
(2) 國內同行業的信息化趨勢如何
(3) 本企業信息化的目的是什麼
(4) 本企業擬採用的信息化步驟如何
需求分析的類型
P33
2.2.2業務需求
業務帶羨模需求分析的目標是明確企業的業務類型,應用系統軟體種類,以及它們對網路功能指標(如帶寬,服務質量QoS)的要求.
業務需求是企業建網中首要的環節,是進行網路規劃與設計的基本依據.
需求分析的類型
P33
2.2.2業務需求
通過業務需求分析要為以下方面提供決策依據:
(1) 需實現或改進的企業網路功能有那些
(2) 需要集成的企業應用有哪些
(3) 需要電子郵件服務嗎
(4) 需要Web服務嗎
(5) 需要上網嗎 帶寬是多少
(6) 需要視頻服務嗎
(7) 需要什麼樣的數據共享模式
(8) 需要多大的帶寬范圍
(9) 計劃投入的資金規模是多少
需求分析的類型
P33
2.2.3管理需求
網路的管理是企業建網不可或缺的方面,網路是否按照設計目標提供穩定的服務主要依靠有效的網路管理.高效的管理策略能提高網路的運營效率,建網之初就應該重視這些策略.
需求分析的類型
P34
2.2.3管理需求
網路管理的需求分析要回答以下類似的問題:
是否需要對網路進行遠程管理,遠程管理可以幫助網路管理員利用遠程式控制制軟體管理網路設備,使網管工作更方便,更高效.
誰來負責網路管理;
需要哪些管理功能,如需不需要計費,是否要為網路建立域,選擇什麼樣的域模式等;
需求分析的類型
P34
2.2.3管理需求
選擇哪個供應商的網管軟體,是否有詳細的評估;
選擇哪個供應商的網路設備,其可管理性如何;
需不需要跟蹤和分析處理網路運行信息;
將網管控制台配置在何處
是否採用了易於管理的設備和布線方式
需求分析的類型
P34
2.2.4安全性需求
企業安全性需求分析要明確以下幾點:
企業的敏感性數據的安全級別及其分布情況;
網路用戶的安全級別及其許可權;
可能存在的安全漏洞,這些漏洞對本系統的影響程度如何;
網路設備的安全功能要求;
需求分析的類型
P34
2.2.4安全性需求
網路系統軟體的安全評估;
應用系統安全要求;
採用什麼樣的殺毒軟體;
採用什麼樣的防火牆技術方案;
安全軟體系統的評估;
網路遵循的安全規范和達到的安全級別.
需求分析的類型
P34
2.2.5通信量需求
通信量需求是從網路應用出發,對當前技術條件下可以提供的網路帶寬做出評估.
需求分析的類型
P35
應用類型
基本帶寬需求
備注
PC連接
14.4kb/s~56kb/s
遠程連接,FTP,HTTP,E-mail
文件服務
100kb/s以上
區域網內文件共享,C/S應用,
B/S應用,在線游戲等絕大部分純文本應用
壓縮視頻
256kb/s以上
Mp3,rm等流媒體傳輸
非壓縮視頻
2Mb/s以上
Vod視頻點播,視頻會議等
表2-1 列舉常見應用對通信量的需求
2.2.5通信量需求
未來有沒有對高帶寬服務的要求;
需不需要寬頻接入方式,本地能夠提供的寬頻接入方式有哪些;
哪些用戶經常對網路訪問有特殊的要求 如行政人員經常要訪問OA伺服器,銷售人員經常要訪問ERP資料庫等.
哪些用戶需要經常訪問Internet 如客戶服務人員經常要收發E_mail.
哪些伺服器有較大的連接數
哪些網路設備能提供合適的帶寬且性價比較高.
需要使用什麼樣的傳輸介質.
伺服器和網路應用能夠支持負載均衡嗎
需求分析的類型
P35
2.2.6網路擴展性需求分析
網路的擴展性有兩層含義,其一是指新的部門能夠簡單地接入現有網路;其二是指新的應用能夠無縫地在現有網路上運行.
擴展性分析要明確以下指標:
(1) 企業需求的新增長點有哪些;
(2) 已有的網路設備和計算機資源有哪些
(3) 哪些設備需要淘汰,哪些設備還可以保留
(4) 網路節點和布線的預留比率是多少
(5) 哪些設備便於網路擴展
(6) 主機設備的升級性能
(7) 操作系統平台的升級性能
需求分析的類型
P35
2.2.7網路環境需求
網路環境需求是對企業的地理環境和人文布局進行實地勘察以確定網路規模,地理分劃,以便在拓撲結構設計和結構化綜合布線設計中做出決策.
網路環境需求分析需要明確下列指標:
(1) 園區內的建築群位置;
(2) 建築物內的弱電井位置,配電房位置等;
(3) 各部分辦公區的分布情況;
(4) 各工作區內的信息點數目和布線規模;
需求分析的類型
P36
2.3.1獲得需求信息的方法
1. 實地考察
實地考察是工程設計人員獲得第一手資料採用的最直接的方法,也是必需的步驟;
如何獲得需求
P36
2.3.1獲得需求信息的方法
2. 用戶訪談
用戶訪談要求工程設計人員與招標單位的負責人通過面談,電話交談,電子郵件等通訊方式以一問一答的形式獲得需求信
如何獲得需求
P36
2.3.1獲得需求信息的方法
3.問卷調查
問卷調查通常對數量較多的最終用戶提出,詢問其對將要建設的網路應用的要求.
如何獲得需求
P36
問卷調查的方式可以分為無記名問卷調查和記名問卷調查
2.3.1獲得需求信息的方法
4.向同行咨詢
將你獲得的需求分析中不涉及到商業機密的部分發布到專門討論網路相關技術的論壇或新聞組中,請同行給你參考你制定的設計說明書,這時候,你會發現熱心於你的方案的人們通常會給出許多中肯的建議
如何獲得需求
P36
2.3.2歸納整理需求信息
通過各種途徑獲取的需求信息通常是零散的,無序的,而且並非所有需求信息都是必要的或當前可以實現的,只有對當前系統總體設計有幫助的需求信息才應該保留下來,其他的僅作為參考或以後升級使用.
1.將需求信息用規范的語言表述出來
2.對需求信息列表
如何獲得需求
P38
2.3.2歸納整理需求信息
需求信息也可以用圖表來表示.圖表帶有一定的分析功能,常用的有柱圖,直方圖,折線圖和餅圖.
如何獲得需求
P39
2.4 可行性論證
需求分析所取得的資料經過整理後得到需求分析文檔,但這種需求分析文檔還需要經過論證後才能最終確定下來.參與論證活動的人員除了需求分析工作的負責人外,還要邀請其他部門的負責人,以及招標方的領導和專家.
可行性論證求
P40
2.4.1 可行性論證的目的
可行性論證是就工程的背景,意義,目的,目標,工程的功能,范圍,需求,可選擇的技術方案,設計要點,建設進度,工程組織,監理,經費等方面作出可行性驗證,指出工程建設中選擇軟硬體的依據,降低項目建設的總體風險.
提供正確選擇軟硬體系統的依據
驗證可行性,減少項目建設的總體風險
產生應用系統原型,積累必要的經驗
加強客戶,系統集成商,設備供應商之間的合作關系
降低後期實施的難度,提高客戶服務水平和滿意度
可行性論證求
P40
2.4.1 可行性論證的目的
在編寫可行性論證報告時,主要對下列項目逐條說明:
1.系統建設的目的
2.技術可行性
3.應用可行性
4.人員,資金可行性
5.設備可行性
6.安全可行性
可行性論證求
P40
2.5 工程招標與投標
為了保證網路工程的建設質量,網路建設方應該以公開招標的方式確定承建商.參與投標的承建商拿出各自的標書參與投標,其中標書的主要內容就來自於需求分析報告和可行性論證報告.
工程招投標是一個規范的網路工程必需的環節.
工程招標與投標
P41
2.5.1工程招標流程簡介
1.招標方聘請監理部門工作人員,根據需求分析階段提交的網路系統集成方案,編制網路工程標底;
2. 做好招標工作的前期准備,編制招標文件;
3. 發布招標通告或邀請函,負責對有關網路工程問題進行咨詢;
4. 接受投標單位遞送的標書;
5. 對投標單位資格,企業資質等進行審查.審查內容包括:企業注冊資金,網路系統集成工程案例,技術人員配置,各種網路代理資格屬實情況,各種網路資質證書的屬實情況.
工程招標與投標
P41
2.5.1工程招標流程簡介
6. 邀請計算機專家,網路專家組成評標委員會;
7. 開標,公開招標各方資料,准備評標;
8. 評標,邀請具有評標資質的專家參與評標,對參評方各項條件公平打分,選擇得分最高的系統集成商;
9. 中標,公告中標方,並與中標方簽訂正式工程合同.
工程招標與投標
P41
2.5.2工程招標
計算機網路工程招標的目的,是為了以公開,公平,公正的原則和方式,從眾多系統集成商中,選擇一個有合格資質,並能為用戶提供最佳性能價格比的集成商.
編制招標文件
招標
工程招標與投標
P41
2.5.3工程投標
投標人在索取,購買標書後,應該仔細閱讀標書的投標要求及投標須知.在同意並遵循招標文件的各項規定和要求的前提下,提出自己的投標文件.
編制投標文件
投標
1,遞交投標文件
2,評標
3,中標
4,簽訂合同
工程招標與投標
P41
標書內容
(1)參評方案一覽表
(2)參評方案價格表
(3)系統集成方案
(4)設備配置及參數一覽表
(5)公司有關計算機設備及備件報價一覽表
(6)從業人員及其技術資格一覽表
(7)公司情況一覽表,
(8)公司經營業績一覽表
(9)中標後服務計劃
(10)資格證明文件,及參評方案方認為需要加以說明的其他內容
(11)文檔資料清單
(12)參評方案保證金
『捌』 如何做好網站開發項目需求分析
從廣義上理解：需求分析包括需求的獲取、分析、規格說明、變更、驗證、管理的一系列需求工程。
狹義上理解需求分析指需求的分析、定義過程。
原因
需求分析就是分析軟體用戶的需求是什麼。如果投入大量的人力，物力、財力、時間，開發出的軟體卻沒人要，那所有的投入都是徒勞。如果費了很大的精力，開發一個軟體，最後卻不滿足用戶的要求，從而要重新開發過，這種返工是讓人痛心疾首的(相信大家都有體會)。比如：用戶需要一個forlinux的軟體，而你在軟體開發前期忽略了軟體的運行環境，忘了向用戶詢問這個問題，而想當然的認為是開發forwindows的軟體。當你千辛萬苦地開發完成向用戶提交時才發現出了問題，那時候你是欲哭無淚了，恨不得找塊豆腐一頭撞死。
需求分析之所以重要，就因為他具有決策性、方向性、策略性的作用，他在軟體開發的過程中具有舉足輕重的地位，大家一定要對需求分析具有足夠的重視。在一個大型軟體系統的開發中，他的作用要遠遠大於程序設計。
任務
簡言之，需求分析的任務就是解決「做什麼"的問題，就是要全面地理解用戶的各項要求，並准確地表達所接受的用戶需求。
過程
需求分析階段的工作,可以分為四個方面：問題識別、分析與綜合、制訂規悄枯褲格說明、評審。
問題識別：就是從系統角度來理解軟體，確定對所開發系統的綜合要求，並提出這些需求的實現條件，以及需求應該達到的標准。這些需求包括：功能需求(做什麼)、性能需求(要達到什麼指標)、環境需求(如機型、操作系統等)、可靠性需求(不發生故障的概率）、安全保密需求、用戶界面需求、資源使用需求(軟體運行是所需的內存、CPU等)、軟體成本消耗與開發進度需求、預先估計以後系統可能達到的目標。
分析與綜合：逐步細化所有的軟體功能，找出系統各元素間的聯系，介面特性和設計上的限制，分析他們是否滿足需求，剔除不合理部分，增加需要部分。最後綜合成系統的解決方案，給出要開發的系統的詳細邏輯模型(做什麼的模型)。
制訂規格說明書：即編制文檔，描述需求的文檔稱為軟體需求規格說明書。請注意，需求分析階段的成果是需求規格說明書，向下一階段提交。
評審：對功能的正確性，完整性和清晰性，以及其它需求給予評價。評審通過才可進行下一階段的工作,否則重新進行需求分析。
方法
需求分析的方法有很多，這里只強調原型化方法，其它的方法如：結構化方法、動態分析法等，從來沒用過這些方法在此不討論。
原型化方法是十分重要的，原型就是軟體的一個早期可運行的版本，它實現了目標系統的某些或全部功能。
原型化方法就是盡可能快地建造一個粗糙的系統，這系統實現了目標系統的某些或全部功能。但是這個系統可能在可靠性、界面的友好性或其他方面上存在缺陷。建造這樣一個系統的目的是為了考察某一方面的可行性，如演算法的可行性、技術的可行性或考察是否滿足用戶的需求等。如：為了考察是否滿足用戶的要求，可以用某些軟體工具快速的建造一個原型系統，這個系統只是一個界面，然後聽取用戶的意見，改進這個原型。以後的目標系統就在原型系統的基礎上開發。
原型主要有三種類型：探索型、實驗型、進化型。
探索型：目的是要弄清楚對目標系統的要求，確定所希望的特性，並探討多種方案的可行性。
實驗型：用於大規模開發和實現前，考核方案是否合適，規格說明是否可靠。
進化型：目的不在於改進規格說明，而是將系統建造得易於變化，在改進原型的過程中，逐步將原型進化成最終系統。
在使用原型化方法時有兩種不同的策略：廢棄策略、追加策略。
廢棄策略：先建造一個功能簡單而且質量要求不高的模型系統，針對這個系統反復進行修改,形成比較好啟簡的思想，據此設計出較完整、准確、一致、可靠的最終系統。系統構造完成後，原來的模型系統就被廢棄不用。探索型和實驗型屬於這種策略。
追加策略：先構造一個功能簡單而且質量要求不高的模型系統，作為最終系統的核心，然後通過不斷地擴充修改，逐步追加新要求，發展成為最終系統。進化型屬於這種策略。
需求分析20條法則
客戶與開發人員交流需要好的方法。下面建議20條法則，客戶和開發人員可以通過評審以下內容並達成共識。如果遇到分歧，將通過協商達成對各自義務的相互理解，以便減少以後敗帆的磨擦（如一方要求而另一方不願意或不能夠滿足要求）。
1、分析人員要使用符合客戶語言習慣的表達
需求討論集中於業務需求和任務，因此要使用術語。客戶應將有關術語（例如：采價、印花商品等采購術語）教給分析人員，而客戶不一定要懂得計算機行業的術語。
2、分析人員要了解客戶的業務及目標
只有分析人員更好地了解客戶的業務，才能使產品更好地滿足需要。這將有助於開發人員設計出真正滿足客戶需要並達到期望的優秀軟體。為幫助開發和分析人員，客戶可以考慮邀請他們觀察自己的工作流程。如果是切換新系統，那麼開發和分析人員應使用一下舊系統，有利於他們明白系統是怎樣工作的，其流程情況以及可供改進之處。
3、分析人員必須編寫軟體需求報告
分析人員應將從客戶那裡獲得的所有信息進行整理，以區分業務需求及規范、功能需求、質量目標、解決方法和其他信息。通過這些分析，客戶就能得到一份「需求分析報告」，此份報告使開發人員和客戶之間針對要開發的產品內容達成協議。報告應以一種客戶認為易於翻閱和理解的方式組織編寫。客戶要評審此報告，以確保報告內容准確完整地表達其需求。一份高質量的「需求分析報告」有助於開發人員開發出真正需要的產品。
4、要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性「需求分析報告」的補充說明，因為工作圖表能很清晰地描述出系統行為的某些方面，所以報告中各種圖表有著極高的價值；雖然它們不太難於理解，但是客戶可能對此並不熟悉，因此客戶可以要求分析人員解釋說明每個圖表的作用、符號的意義和需求開發工作的結果，以及怎樣檢查圖表有無錯誤及不一致等。
5、開發人員要尊重客戶的意見
如果用戶與開發人員之間不能相互理解，那關於需求的討論將會有障礙。共同合作能使大家「兼聽則明」。參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間，同樣，客戶也應對開發人員為項目成功這一共同目標所做出的努力表示尊重。
6、開發人員要對需求及產品實施提出建議和解決方案
通常客戶所說的「需求」已經是一種實際可行的實施方案，分析人員應盡力從這些解決方法中了解真正的業務需求，同時還應找出已有系統與當前業務不符之處，以確保產品不會無效或低效；在徹底弄清業務領域內的事情後，分析人員就能提出相當好的改進方法，有經驗且有創造力的分析人員還能提出增加一些用戶沒有發現的很有價值的系統特性。
7、描述產品使用特性
客戶可以要求分析人員在實現功能需求的同時還注意軟體的易用性，因為這些易用特性或質量屬性能使客戶更准確、高效地完成任務。例如：客戶有時要求產品要「界面友好」或「健壯」或「高效率」，但對於開發人員來講，太主觀了並無實用價值。正確的做法是，分析人員通過詢問和調查了解客戶所要的「友好、健壯、高效所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預期利益之間做出權衡，以確保做出合理的取捨。
8、允許重用已有的軟體組件
需求通常有一定靈活性，分析人員可能發現已有的某個軟體組件與客戶描述的需求很相符，在這種情況下，分析人員應提供一些修改需求的選擇以便開發人員能夠降低新系統的開發成本和節省時間，而不必嚴格按原有的需求說明開發。所以說，如果想在產品中使用一些已有的商業常用組件，而它們並不完全適合您所需的特性，這時一定程度上的需求靈活性就顯得極為重要了。
9、要求對變更的代價提供真實可靠的評估
有不同的選擇。而這時，對需求變更的影響進行評估從而對業務決策提供幫助，是十分必要的。所以，客戶有權利要求開發人員通過分析給出一個真實可信的評估，包括影響、成本和得失等。開發人員不能由於不想實施變更而隨意誇大評估成本。
10、獲得滿足客戶功能和質量要求的系統
每個人都希望項目成功，但這不僅要求客戶要清晰地告知開發人員關於系統「做什麼」所需的所有信息，而且還要求開發人員能通過交流了解清楚取捨與限制，一定要明確說明您的假設和潛在的期望，否則，開發人員開發出的產品很可能無法讓您滿意。
11、給分析人員講解您的業務
分析人員要依靠客戶講解業務概念及術語，但客戶不能指望分析人員會成為該領域的專家，而只能讓他們明白您的問題和目標；不要期望分析人員能把握客戶業務的細微潛在之處，他們可能不知道那些對於客戶來說理所當然的「常識」。
12、抽出時間清楚地說明並完善需求
客戶很忙，但無論如何客戶有必要抽出時間參與「頭腦高峰會議」的討論，接受采訪或其他獲取需求的活動。有些分析人員可能先明白了您的觀點，而過後發現還需要您的講解，這時請耐心對待一些需求和需求的精化工作過程中的反復，因為它是人們交流中很自然的現象，何況這對軟體產品的成功極為重要。
13、准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的。由於處理細節問題不但煩人而且耗時，因此很容易留下模糊不清的需求。但是在開發過程中，必須解決這種模糊性和不準確性，而客戶恰恰是為解決這些問題作出決定的最佳人選，否則，就只好靠開發人員去正確猜測了。
在需求分析中暫時加上「待定」標志是個方法。用該標志可指明哪些是需要進一步討論、分析或增加信息的地方，有時也可能因為某個特殊需求難以解決或沒有人願意處理它而標註上「待定」。客戶要盡量將每項需求的內容都闡述清楚，以便分析人員能准確地將它們寫進「軟體需求報告」中去。如果客戶一時不能准確表達，通常就要求用原型技術，通過原型開發，客戶可以同開發人員一起反復修改，不斷完善需求定義。
14、及時作出決定
分析人員會要求客戶作出一些選擇和決定，這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等。有權作出決定的客戶必須積極地對待這一切，盡快做處理，做決定，因為開發人員通常只有等客戶做出決定才能行動，而這種等待會延誤項目的進展。
15、尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本。客戶所希望的某些產品特性可能在技術上行不通，或者實現它要付出極高的代價，而某些需求試圖達到在操作環境中不可能達到的性能，或試圖得到一些根本得不到的數據。開發人員會對此作出負面的評價，客戶應該尊重他們的意見。
16、劃分需求的優先順序
絕大多數項目沒有足夠的時間或資源實現功能性的每個細節。決定哪些特性是必要的，哪些是重要的，是需求開發的主要部分，這只能由客戶負責設定需求優先順序，因為開發者不可能按照客戶的觀點決定需求優先順序；開發人員將為您確定優先順序提供有關每個需求的花費和風險的信息。
在時間和資源限制下，關於所需特性能否完成或完成多少應尊重開發人員的意見。盡管沒有人願意看到自己所希望的需求在項目中未被實現，但畢竟是要面對現實，業務決策有時不得不依據優先順序來縮小項目范圍或延長工期，或增加資源，或在質量上尋找折衷。
17、評審需求文檔和原型
客戶評審需求文檔，是給分析人員帶來反饋信息的一個機會。如果客戶認為編寫的「需求分析報告」不夠准確，就有必要盡早告知分析人員並為改進提供建議。更好的辦法是先為產品開發一個原型。這樣客戶就能提供更有價值的反饋信息給開發人員，使他們更好地理解您的需求；原型並非是一個實際應用產品，但開發人員能將其轉化、擴充成功能齊全的系統。
18、需求變更要立即聯系
不斷的需求變更，會給在預定計劃內完成的質量產品帶來嚴重的不利影響。變更是不可避免的，但在開發周期中，變更越在晚期出現，其影響越大；變更不僅會導致代價極高的返工，而且工期將被延誤，特別是在大體結構已完成後又需要增加新特性時。所以，一旦客戶發現需要變更需求時，請立即通知分析人員。
19、遵照開發小組處理需求變更的過程
為將變更帶來的負面影響減少到最低限度，所有參與者必須遵照項目變更控制過程。這要求不放棄所有提出的變更，對每項要求的變更進行分析、綜合考慮，最後做出合適的決策，以確定應將哪些變更引入項目中。
20、尊重開發人員採用的需求分析過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性，分析人員採用的方法有其合理性。也許客戶認為收集需求的過程不太劃算，但請相信花在需求開發上的時間是非常有價值的；如果您理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術，那麼整個過程將會更為順利。
「需求確認」意味著什麼
在「需求分析報告」上簽字確認，通常被認為是客戶同意需求分析的標志行為，然而實際操作中，客戶往往把「簽字」看作是毫無意義的事情。「他們要我在需求文檔的最後一行下面簽名，於是我就簽了，否則這些開發人員不開始編碼。」
這種態度將帶來麻煩，譬如客戶想更改需求或對產品不滿時就會說：「不錯，我是在需求分析報告上簽了字，但我並沒有時間去讀完所有的內容，我是相信你們的，是你們非讓我簽字的。」
同樣問題也會發生在僅把「簽字確認」看作是完成任務的分析人員身上，一旦有需求變更出現，他便指著「需求分析報告」說：「您已經在需求上簽字了，所以這些就是我們所開發的，如果您想要別的什麼，您應早些告訴我們。」
這兩種態度都是不對的。因為不可能在項目的早期就了解所有的需求，而且毫無疑問地需求將會出現變更，在「需求分析報告」上簽字確認是終止需求分析過程的正確方法，所以我們必須明白簽字意味著什麼。
對「需求分析報告」的簽名是建立在一個需求協議的基線上，因此我們對簽名應該這樣理解：「我同意這份需求文檔表述了我們對項目軟體需求的了解，進一步的變更可在此基線上通過項目定義的變更過程來進行。我知道變更可能會使我們重新協商成本、資源和項目階段任務等事宜。」對需求分析達成一定的共識會使雙方易於忍受將來的摩擦，這些摩擦來源於項目的改進和需求的誤差或市場和業務的新要求等。
『玖』 如何進行需求分析
項目需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造鉛岩宴成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。 在原則上，需求階段監理應尊重承建方的項目管理和項目分析能力；在具體的任務開展上，以不深入、不幹擾承建方的自主權為主，除非在項目合作過程中發現承建方的項目管理以及項目分析能力存在很大的差距和不足。 為了保證項目的成功，監理方必須加強項目管理和項目分析工作，在具體的操作上可以堅持吸收、同化、貫徹的方法和手段。其中，需求分析是一個項目的開端，也是項目建設的基石。在以往建設失敗的項目中，80％是由於需求分析的不明確而造成的。因此一個項目成功的關鍵因素之一，就是對需求分析的把握程度。而項目的整體風險往往表現在需求分析不明確、業務流程不合理，用戶不習慣或不願意去用承建方的軟體。作為第三方的監理公司，必須提醒承建方、客戶方重視需求分析的重要性，採用必要的手段和方法來進行需求調研，同時監理方也應深入具體的需求調研中去。只有這樣才能切切實實地把握用戶的需求和方向，才能在將來的功能界定、開發范圍上有發言權。 需求分析不象偵探推理那樣需從蛛絲馬跡著手，而是應該先了解宏觀的問題，再了解細節的問題。 一個應用軟體系統（記為S）的涉及面可能很廣，可以按不同的問題域（記為D）分類，每個問題域對應於一個軟體子系統。 S={D1，D2，D3，…Dn} 問題域Di由若干個問題（記為P）組成，每個問題對應於子系統中的一個軟構件。 Di={P1，P2，P3，…Pm} 問題Pj有若干個行為（或功能，記為F），每個行為對應於軟構件中的實現介面。 Pj={F1，F2，F3，…Fk} 需求說明書應該對於那些只想了解宏觀需求的領導，和需要了解細節的技術員都合適。在寫需求說明書時應該注意兩個問題： 1.最好為每個需求注釋「為什麼」，這樣可讓程序員了解需求的本質，以便選用最合適的技術來實現此需求。 2.需求說明不可有二義性，更不能前後相矛盾。如果有二義性或前後相矛盾，則要重新分析此需求。 重點監控需求分析 由於項目的特殊性和行業覆蓋的廣闊性，以及需求分析的高風險性，軟體需求分析的重要性是不言而喻的，同時需求分析又的的確確難做。其原因基本是由於以下情況造成的。 客戶說不清楚需求 有些客戶對需求只有朦朧的感覺，當然說不清楚具體的需求。例如全國各地的很多部門、機構、單位在進行應用系統以及網路建設時，客戶方的辦公人員大多不清楚計算機網路有什麼用，更缺乏IT系統建設方面的專家和知識。此時，用戶就會要求軟體系統分析人員替他們設想需求。工程的需求存在一定的主觀性，為項目未來建設埋下了潛在的風險。 需求自身經常變動 根據以往的歷史經驗，隨著客戶方對信息化建設的認識和自己業務水平的提高，他們會在不同棗物的階段和時期對項目的需求提出新的要求和需求變更。事實上，歷史上沒有一個軟體的需求改動少於三次的！所以必須接受「需求會變動」這個事實，在進行需求分析時要懂得防患於未然，盡可能地分析清楚哪些是穩定的需求，哪些是易變的需求，以便在進行系統設計時，將軟體的核心建築在穩定的需求上，同時留出變更空間。咨詢監理方在需求分析的功能界定上擔任一個中間、公平、公正的角色，所以也必須積極參與到需求分析的准備中來，以便協助客戶方和承建方來界定「做什麼」、「不做什麼」的系統功能界限。 分析人員或客戶理解有誤 軟體系統分析人員不可能都是全才，更不可能是行業方面的專家。客戶表達的需求，槐銀不同的分析人員可能有不同的理解。如果分析人員理解錯了，可能會導致以後的開發工作勞而無功。記得一則笑話，有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：「主宰地球的是汽車。它們喝汽油，靠四個輪子滾動前進，嗓門極大，雙眼在夜裡能射出強光……有趣的是，車里住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」所以分析人員知識的專一性也會造成需求分析的誤解和失敗。這時，咨詢監理公司就必須根據實際的項目需求調研計劃，提醒承建方加強業務了解程度和注重溝通技巧。 需求分析方法論 根據以往的工程經驗，需求分析工作方法，應該定位在「三個階段」（也稱「三步法」）。 第一階段：「訪談式」（Visitation） 這一階段是和具體用戶方的領導層、業務層人員的訪談式溝通，主要目的是從宏觀上把握用戶的具體需求方向和趨勢，了解現有的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體情況、客觀的信息。建立起良好的溝通渠道和方式。針對具體的職能部門以及各委辦局，最好能指定本次項目的介面人。 實現手段：訪談、調查表格 輸出成果：調查報告、業務流程報告 第二階段：「誘導式」（Incement） 這一階段是在承建方已經了解了具體用戶方的組織架構、業務流程、硬體環境、軟體環境、現有的運行系統等等具體實際、客觀的信息基礎上，結合現有的硬體、軟體實現方案，做出簡單的用戶流程頁面，同時結合以往的項目經驗對用戶採用誘導式、啟發式的調研方法和手段，和用戶一起探討業務流程設計的合理性、准確性、便易性、習慣性。用戶可以操作簡單演示的DEMO，來感受一下整個業務流程的設計合理性、准確性等等問題，及時地提出改進意見和方法。 實現手段：拜訪（誘導）、原型演示 輸出成果：調研分析報告、原型反饋報告、業務流程報告 第三階段：「確認式」（Afirm） 這一階段是在上述兩個階段成果的基礎上，進行具體的流程細化、數據項的確認階段，這個階段承建方必須提供原型系統和明確的業務流程報告、數據項表，並能清晰地向用戶描述系統的業務流設計目標。用戶方可以通過審查業務流程報告、數據項表以及操作承建方提供的DEMO系統，來提出反饋意見，並對已經可接受的報告、文檔簽字確認。 實現手段：拜訪（回顧、確認），提交業務流程報告、數據項表；原型演示系統 輸出成果：需求分析報告、數據項、業務流程報告、原型系統反饋意見（後三者可以統一歸入需求分析報告中，提交用戶方、監理方進行確認和存檔） 整體來講，需求分析的三個階段是需求調研中不可忽視一個重要的部分，三個階段或者說三步法的實施和採用，對用戶和承建方都同樣提供了項目成功的保證。當然在系統建設的過程中，特別在採用迭代法的開發模式時，需求分析的工作需一直進行下去，而在後期的需求改進中，工作則基本集中在後兩個階段中。
『拾』 如何開展信息化需求分析
需求分析是邁向信息化成功之路的第一步，也是極具認知性和創造性的活動，此階段做得好壞，是信息化成敗的關鍵。
一、 需求分析面跡皮對的困難
1、問題了解上的難度
做需求分析的人員經常是IT技術人員，他們對企業的實際生產經營情況不甚了解，然而具體生產管理人員不具備需求功能表述能力，使得信息化需要處理的內容難以確定。
2、問題本身的動態性
企業信息化的需求不是一成不變的，隨著企業的不斷發展，企業對信息化的需求也在不斷的發生變化。但對企業信息化需求產生影響的主要來自三個方面：
（1）資本結構的變化
企業在資本層面的變化，如企業並購，往往會使企業在組織結構、企業文化、業務流程等方面發生很大的變化，從而對企業信息化的需求將會產生根本的影響。
（2）組織結構的變化
組織結構的變化對信息化需求的影響也是很大的，如果企業的一把手更換了，可能整個信息化建設的思路就會發生變化。組織結構的調整也會使業務流程發生變化。
（3）業務的變化
業務的變化主要是：業務方向世州嫌的變化和業務流程的變化等方面，在這個層面的變化對信息化需搜手求的影響可能是巨大的，如：企業拓展一個全新的業務領域等。
正是由於這些變化對信息化需求的影響很大，因而從戰略層面上應該盡量把握變化的方向。另外，考慮到信息化需求的可變性，信息化規劃和實施需要一定柔性。企業對於信息化的需求，也需要根據變化進行定期的修整。
3、團隊溝通的障礙
不同層面的人員對信息化的需求是不同的，對於企業戰略層面來說，企業信息化的需求不僅僅是來源於企業目前對信息化的需求，也來源於企業未來發展的需求；對於技術層面來說信息化的需求側重於企業發展的一個支撐環境，從信息技術層面上對系統的完善、升級、集成和整合提出了需求。對於運作層面來說，側重於企業關鍵業務流程處理，確定企業在運作中存在的問題。以上三個層次所獲取的需求並不是相互孤立的，有著內在的聯系。要想把握企業對信息化建設的方向，需要不同層面的人員友好溝通，對需求進行綜合分析。