1、電子商務網上支付系統的功能有哪些
電子商務支付系統應該有以下功能：
選擇銀行卡的功能；
支持手機客戶端和電腦上都可以支付的功能；
支持付款時的安全防火牆問題等功能。
電子商務系統應具有以下各項功能：
網上訂購：可藉助Web中的郵件或表單交互傳送信息，實現網上的訂購；
貨物傳遞：於已付了款的客戶應將其訂購的貨物盡快地傳遞到他們的手中；
咨詢洽談：能藉助非實時的電子郵件、新聞組和實時的討論組來了解市場和商品信息，洽談交易事務，還可用網上的白板會議來交流即時的圖形信息等；
網上支付：要成為一個完整的過程，網上支付是重要的環節；
電子銀行：網上的支付必需要有電子金融來支持，即銀行、信用卡公司等金融單位要為金融服務提供網上操作的服務；
廣告宣傳：需要可憑借企業的Web伺服器和客戶的瀏覽，在Internet上發布各類商業信息；
意見征詢：需要能十分方便地採用網頁上的"選擇"、"填空"等格式文件來收集用戶對銷售服務的反饋意見；
業務管理：能通過數據看出用戶的需求等功能。
2、目前國內外電子商務網站採用的電子支付新技術有哪些
目前，電子商務只是在對通用方針和平台意見一致的參與者間的封閉組織內進行。例如，電子數據交換（EDI）被用來在一個機構的多個分支之間，或者在建立了契約聯系的機構之間安全地傳輸數據。而在這些早期階段，電子商務系統只處理某幾個方面的完全商務事務。
當客戶可以通過他們的Web瀏覽器來使用的第一批基於web的商店出現時，建立了電子商務的一個更全面的概念作為Internet上傳遞貨物和價格的方式。現在，大多數電子商務系統是基於web的，並且允許客戶通過他們的web瀏覽器購買貨物並用信用卡結帳。然而，基於web的應用程序的局限功能使得很難向客戶提供全范圍的服務。
未來，電子商務解決方案的需求將超過當前級別。將來的系統將必須通過多個自治的服務提供商來滿足動態開放式環境中的需求，電子商務將成為一個包含多個交易實體間復雜的交互作用的分布式過程。在一個開放式市場中，有許多獨立的貨物和服務的供應商，並且可能有通過合並第三方提供的服務來提供服務的調解者。客戶本身也可能合並隨選（on-demand）產品或者服務來實現合成包。因此，現代的電子商務系統必須能集成不同種類參與系統和不同政策領域中互相不信任的用戶。
CORBA安全服務規范提供了消息層完整性和負責者的鑒定/認可，這兩項對電子商務應用程序都很關鍵。然而，OMG的電子商務域任務組織（OMG－ECDTF）為電子商務系統識別另外幾種安全需求。CORBA規范中並沒有下面的需求，或者由於它們仍未被提出，或者由於它們超出了CORBA所能達到的范圍：
l 事務審核：CORBA安全規范提供了審核數據產生，但沒有提供所需數據和粒度。
l 基於角色的存取控制：盡管好的粒度或者靈敏的商務交易中需要單獨的存取控制，但電子商務把基於角色的存取控製作為主要形式。CORBA安全性沒有提供基於角色的存取控制。
l 認可：CORBA規定根據的生成，但是不提供存儲根據、恢復根據和確認根據的工具。電子商務所需的完全的認可功能包括根據生成、確認、存儲、恢復和遞送權力。這個服務可以提供創造、起源、接收、服從、贊成、遞送和行為的認可。
l 完整性：應該提供將數據變成完整性所保護的數據、將完整性所保護的數據轉變回原始數據、檢查是否遺失完整性的功能。另外，也需要著手一些另外的完整性問題。例如，需要有一些用來防止惡意的軟體，例如防止計算機病毒所做未驗證的修改的機制。除消息層完整性以外，CORBA沒有提供任何電子商務系統需要的其他層上的完整性功能。
l 授權：CORBA提供了使得個別責任變得容易的"扮演的授權"。然而，電子商務需要別的授權選項，例如簡易授權，復合授權，組合特權授權（不允許把這些特權來追溯回某些中間節點），和追溯授權（提供了鏈中的授權追溯）。目前，CORBA並不要求提供這些授權模式。
l 授權在安全性審核中發揮作用。它支持將一條復雜的對象請求鏈追溯回最初的用戶。
l 安全性審核庫管理：審核服務可以用來保證所有的用戶對他們發起的安全相關事項負責任，並保證建立、保持和保護安全相關事項的審核跟蹤。另外，必須提供警告設施，並且收集、剖面、過濾、分析和查詢審核數據也是可能的。CORBA目前沒有提供任何審核管理功能。
l 安全性管理：電子商務安全性管理應該關心以下三個范疇：管理功能的安全性、安全服務管理和安全機制管理。當前，CORBA並沒有提供任何安全性管理工具。
7.基於CORBA的電子商務
CORBA作為電子商務系統的底層結構有許多優點，本節概述其中幾個優點。
開放式電子商務系統的兩個主要需求是互操作性和完整性。所有的客戶和供應商應用程序都應該可以在一個靈活的、動態的、開放的框架中，越過不同平台，不同編程語言和商業布局來互操作。CORBA可以從開放的電子商務環境的復雜性中抽象出來。CORBA方便了電子商務系統和其它系統之間的交互作用，比如股票管理系統、會計系統、行銷系統等，並使得和以前的應用程序的之間集成變得容易，例如，一個舊的股票資料庫系統。
從軟體開發者的觀點來看，CORBA使得一切都變得比較簡單，尤其是如果打算進行不同的商店配置時。CORBA抽象了網路和動態的遠程商店調用，允許應用程序開發者集中精力在實際的程序上，而不是集中在底層結構的內部工作方式上。應用程序開發者可以再利用已存在系統中的部分（例如安全性系統）來開發新程序。CORBA的靈活結構也使得開發者可以實現整個商業街的一部分來迎合特殊的貿易需求，並為進一步增強系統和容易地升級這部分商業街軟體提供堅實的基礎。將來，個別基於CORBA的可定製的商業街組件就可用了，可以購買它，並可以很容易的將之即插即用進已存在的商業街中，來增強或升級商店系統，。
為了使得商店組件的動態互用性運轉起來，一套定義良好的標准服務需要在電子商務環境下可用。例如，用來描述對象（例如貨物、服務、合同、發票或帳單等）的語義需要廣泛定義。因此，OMG和商業網（CommerceNet）共同定義了一系列電子商務服務的需求，也就是說，語義數據工具，選擇/商議工具和支付服務。語義數據工具提供了對電子市場參與者之間語義信息交換的支持，商議服務提供了一組從事商業事務的參與者，在服務或工具的選擇和配置上相互協定的支持，而電子支付工具關注支付協議的調用。
實際上，CORBA還是經常被認為是一項不成熟的技術，尤其是CORBA沒有實現許多服務，例如安全性服務。除了與不成熟的ORB實現相關的問題外，軟體開發者也往往沒有完全訓練到可以熟練編寫基於CORBA的組件的地步。就本地程序來說，基於CORBA的應用程序開發幾乎與普通的應用程序開發相同，因此並沒有真正造成問題，但是例如實現一個透明的提供了ORB層安全性的安全性服務就需要專業知識。
目前，對基於CORBA的電子商務系統的評價使得這些開發足以為一些公司盈利了。例如，銀行配置基於CORBA的個人銀行業，或者股票交易系統可能因為它是顧客的最主要地邊緣技術的服務提供者而獲益。
8.結論
許多CORBA的核心概念對電子商務系統是有用的，例如，互操作性和綜合性，平台、編程語言和安全機制等的靈活性，底層組件布局和網路的抽象，安全性功能的透明性，安全性的自動增強。
然而，目前可用的CORBA實現相當不成熟，而且並沒有實現最初指出的所有的功能。例如，目前沒有一個完全的安全性服務實現是可以定製使用的。這樣把實現自定義的安全服務的工作留給了應用程序開發者，他們需要有安全性和所使用CORBA產品的內部運轉機制的專業知識。
即使是未來CORBA功能沒有消弱，也沒被別的什麼東西（例如Java RMI和COM＋）來代替，本文描述的基本概念也將成為任何電子商務中件的核心需求。如果CORBA如許多人推測，變成了電子商務的新的Internet標準的話，提供基於CORBA的商業街和服務越快的商務，獲益越多。因此，為了當分布式對象中件廣為使用時獲得競爭優勢，軟體開發者很明顯現在就得熟悉CORBA概念。
了解更多的相關專業知識上上海海淘科技網
3、建設C2C電子商務網站（包括其支付系統）
我也是剛學會做網站的，可以告訴你些經驗。
1.dreamweaver是肯定要學的，是基礎。也不是很難。
2.你的語言學的很多，說明你有基礎。是好事。所以學起ASP或者PHP很不是難事。我是用的ASP，覺得過時了，而且安全性也不算太高。最好學些新的東西吧。ASP.NET和PHP都不錯。你可以學學。
3.你可以到站長網下載些網站系統回來自己研究研究。我就是這樣的，不會的可以上網查。再根據別人的，自己試著練習。練練就會了。
4.還有黑客攻擊是有的，但是你學過語言後，你可以在代碼里加密。網上也有很多加密的方法，做完後你可以加進去。
4、電子商務系統設計
電子商務系統是互聯網時代計算機系統的主流應用，是集成了數據管理、事務處理、業務流程重組、系統安全管理等技術的復雜系統。很多企業管理者和信息系統技術負責人在被電子商務系統的廣闊前景所吸引的同時，亦為不知如何開展電子商務系統的建設而煩惱。系統集成商參與項目開發的困難更多：用戶需求不準確、經常變化，開發人員與業務人員溝通困難、誤差極大。最後上網工程變成了網頁設計大賽，花費了大量人力物力建造的網站並沒有為企業帶來預期中的收益，反而變成了一個擺設，甚至因為要不斷投入維護費用而成了企業的負擔。 本文著重討論電子商務系統工程中系統需求分析和系統概要設計的基本方法，向項目經理和技術負責人介紹如何組織電子商務項目的開展。事實上電子商務系統一方面是一個相當復雜的工程，需要科學的系統規劃和項目管理，另一方面電子商務系統也只不過是一種應用計算機的系統工程，雖然涉及的技術內容和業務因素較多，但只要遵循合理的系統工程實施方法進行，仍然可以順利地完成電子商務系統的建設。 電子商務技術可能目前世界上最令人眼花暸亂的技術領域，新名詞、新技術、新術語每天都在出現，如何建設電子商務系統，似乎有無數種可能，令人無所適從，不知如何作出正確的決策。技術本身並不能為企業帶來效益，只有合理應用技術建造的系統才能幫助企業解決業務運作中的問題，幫助企業發展業務，所以設計電子商務系統時必須堅持一個原則：企業的需求是目的，任何技術都只是實現需求的手段，建設電子商務系統不是為了應用某項新技術，而是為了解決企業的實際問題。只有堅持這個原則才能避免常見的失誤：採用了很多不成熟或者復雜的技術，工程費用超標，項目進度無法保證，應用效果未如理想等等。電子商務系統的目標可以用以下幾個問題來總結。 應用環境：系統將為哪些用戶服務？他們使用什麼平台，如何訪問企業的電子商務系統？ 系統功能：系統為用戶提供了什麼服務？哪些是已經有的，哪些要修改，哪些要重新開發？ 數據資源：為了實現這些服務功能，系統將使用哪些數據？數據量多大，如何存儲？ 安全管理：系統的安全性如何保證？系統管理如何實施？其中系統功能是范圍最廣泛的問題，從最早的信息發布到現在很流行的B2C，B2B，ASP等都是系統功能的一種，按實現這些功能的技術核心可以分為三類： 1 信息共享與數據交換
數據存儲與數據通訊技術是實現這類功能的核心技術，這類系統幫助用戶通過電子郵件、搜索引擎、數據發布技術等高效地獲得信息，提高數據交換的速度與信息共享的效率。 信息共享型的電子商務系統可以降低企業內部由於信息溝通不靈而帶來的損耗，減少日常工作的文書往來，提高工作效率，更有效地管理企業內的信息使用情況。 2 電子商務交易
以電子化的方式實現商務交易過程中的每一個步驟，能適應業務的快速發展而變化是實現這類系統的關鍵，電子商務交易系統是目前最具挑戰性的領域，技術核心是應用系統開發能力與事務處理技術，其中也包括與金融系統介面進行網上支持的SET及相關技術，目前的B2C，B2B即屬於這一類系統。 電子商務交易系統是現代企業在互聯網時代擴展新市場的重要手段，設計良好的交易系統能使企業一天24小時不停地運轉，為客戶提供優良的服務。如果能將企業核心業務系統與互聯網系統有機地集成起來，就能大大地擴展企業的運作范圍，降低經營成本和銷售成本。 3 互聯網伺服器上的應用服務
擴展互聯網伺服器的服務能力，定製滿足客戶需求的應用服務，其內容可能包含了所有電子商務系統的功能，JAVA技術與事務處理技術是這類系統的技術核心。這類系統通常指企業級的門戶網站或ASP，由於其極高的處理負載，還需要提供額外的集群技術、性能管理等復雜的技術支持。 這類系統或者是把原有的企業核心業務系統與互聯網伺服器集成起來，或者是在互聯網伺服器上開發功能完善的應用服務系統。訪問這類互聯網伺服器的客戶能得到自動更新的最新數據，獲得定製化的自助服務。訪問這類系統的客戶數極多，因此要求具有較好的可擴展能力，性能不會受客戶連接數變化的影響，一直保持良好的狀態，所以要採用連接管理技術、事務管理與資源協調等復雜的技術。 本文分三大部分，分別介紹系統需求分析與系統設計的組織方法，以及開展功能檢驗與性能測試的過程，著重介紹基本原則，並不泛及特定相關技術的細節。至於系統實施階段所採用的技術與方法，由於電子商務系統的復雜性、新技術層出不窮，實在不是用一篇文章甚至一兩本書所能涵蓋的。 系統需求分析 系統需求分析是為了系統開發人員准確地理解業務部門的目標，制定合適的實施方案，系統需求對系統實施的重要性不但應該反復強調，還應該避免收集系統需求過程中常見的幾個誤區： 1 系統需求分析不是一次性的工作，而是一個反復遞進的過程，隨著電子商務應用系統的推廣，業務部門會提出新的需求，或者改變原來的業務需求。這是允許的，而且是正常的，技術部門不能拒絕業務部門提出的新需求，而應積極配合，對原有的實施方案作相應的改變。
2 系統需求的根源是業務部門運作的需求，而不是技術部門為了實現某種先進技術而提出的需求。系統方案不能因為出現了某項新技術而作改變，畢竟，使用新技術只是手段，支持企業的商業運作才是最終目的。
3 系統需求不僅限於業務需求，還包括了客觀條件的各種限制，如項目進度的要求、與已有系統兼容的要求（如企業的所有核心數據都已經存儲在Sybase資料庫中、或者企業的舊系統留下幾千台終端必須加以利用）或其他政策法規的限制（如商業系統中使用的密碼系統必須經過政府有關部門的認證）。制定應用系統的實施方案時應把這些因素考慮在內。
收集系統需求的主要途徑是系統分析人員與最終用戶通過交談發掘搣真正攠的系統需求，獲得用戶的認同，在業務部門的幫助下准確地認識業務環境（這一點是大多數技術人員最缺乏的），收集足夠完整的信息，完成一系列文檔作為確認本階段工作的檢查標記，並作為進行下一步工作的基礎。
哪么什麼才是搣真正攠准確的系統需求，當一個客戶向系統分析人員提出要求：搣我們要建立一個網上商城，讓我們公司的客戶可以在網上直接下訂單攠，這是一個絕對真實的要求，但並不一定是一個准確的系統需求，或者說這並不一定是最適合該企業實際需求的目標。因為客戶在提出要求時，一般已經對電子商務有了一些先入為主的認識，認為電子商務就是這樣的，或者只能是這樣的，又或者同行和競爭者已經這樣做了，所以我們也要這樣做。實際上他們所真正需要的，可能比這個要求多，可能比這個要求少，甚至完全是另一個系統。這時系統分析人員就要耐心地發掘客戶的實際需求，通常是提出這樣的問題：
您希望這套電子商務應用建立起來後，能為您的企業達到以下這些目標中的哪些呢？哪些目標是您最希望達到的，您認為您的企業目前在這些方面存在什麼主要問題，您希望電子商務系統能在多大程度上解決這些問題呢？
增加客戶數量 降低企業運營成本或提高營業額
提升公司的總體形象
加快產品推向市場的速度
使企業比同行更具競爭力
縮短新產品的開發周期
改善庫存管理和采購流程管理的效率
改善企業與代理商之間的合作關系
提高客戶滿意度和客戶服務的質量
提高本企業員工的合作溝通效率
幫助企業拓展新的市場這樣的談話最好是在系統分析人員和企業的業務負責人之間進行，而不和企業的電腦部門技術負責人，只有這樣才能發掘出系統真正的需求。系統分析人員通常會從企業負責人那裡得到一些與電子商務技術完全無關的情況，例如搣客戶抱怨我們的交貨期不準時攠、搣我們的企業太大了，各部門間的合作溝通很成問題，總是左手不知道右手在做什麼攠等。這樣的交談能幫助系統分析人員准確地為電子商務系統定位，規定其功能邊界。
企業的負責人通常會更多地著眼於總體的業務規劃，負責需求分析的系統分析人員和項目經理應利用這個機會，向企業管理人員詳細地解釋幾類電子商務系統的功能和應用，啟發他們更深入地發掘企業的需求，以實踐經驗和成功案例向他們說明企業電子商務系統的預期目標，幫助他們樹立正確的期望值。多數企業都是第一次實施電子商務系統，且由於媒體的大肆宣揚等外界因素的影響,可能對系統的預期效果產生不切實際的期望，系統分析人員在需求分析階段就要准確地掌握和調整客戶的心理期望。客戶的期望值也是系統需求的一個重要因素，直接影響系統完成後的實施效果。
客戶的態度和技術水平是影響系統設計者作出方案的重要因素，也是系統需求的一部分，系統需求分析階段要和客戶一起作出充分的交流和評估。客戶的態度指企業決策者對新技術的接受程度以及願意承受風險的程度，電子商務領域的新技術層出不窮，成熟技術的功能比不上新技術，但風險卻較低，企業決策者在這方面的態度影響系統設計者設計方案時的技術選擇，如果企業決策者選擇較先進的新技術，系統分析人員有責任提醒他採用新技術可能面臨的風險：失敗的可能性較高，項目進度和開發成本可能超出預期。切勿投客戶所好，隱瞞新技術背後的不利因素。企業決策者在選擇系統集成商時也應小心，集成商的技術水平不是由掌握新技術的程度所決定，而是由他們運用技術解決實際問題的水平所反映。
中國的大多數大型企業都有專門的計算機部門，電子商務系統建成後維護管理甚至二次開發的工作都將由他們負責，方案設計時也應把客戶方技術人員的知識基礎和專業訓練程度考慮在內。系統需求分析階段最好對客戶方技術人員作一次全面的評估，考察他們對與電子商務系統相關的技術領域的掌握程度，評估的內容有：互聯網伺服器，對象技術，JAVA，應用開發工具，資料庫技術，事務處理技術，安全技術以及對工業標準的認識程度。
系統分析人員要把這些分散的需求匯總成系統的目標，製成初步系統概要需求書，准確而完整地描述企業的總體需求，再次強調系統的預期目標，並獲得企業負責人的認同，再在此基礎上作系統的初步設計。
系統需求分析的工作並未就此結束，反而才剛剛開始。項目經理應作一些准備工作，召集第一次項目會議，會議的參加者包括客戶方的業務和技術負責人，以及項目建造方的項目經理，會議的主要目的是進一步確認和細化系統概要需求書中列出的需求，確定系統建造的方向。這些會議應原則上達成下列這些目標： 1.詳細討論當前環境的情況和系統需求。2.檢討目前正在使用的應用系統，明確列出需要解決的問題。3.在適當的時候交換各自對電子商務系統所持的思路與觀點，創造較易達成共識的認知基礎。4.確定系統的主要目標，當系統需求的范圍比較廣泛，系統目標也可分為短期目標和遠期目標。5.列出為保證系統順利而要解決的主要問題，劃出最突出、最緊迫的問題，爭取客戶方的合作，在系統開始實施前即加以解決。6.向客戶解釋實施系統過程中使用的核心技術和方案的總體思路。7.基於會上達成的共識，制定各人的行動計劃表。這樣的一個會議不可能在一兩個小時內完成，可能需要幾天的時間，甚至在不同的場合下以不同的形式組織，如方案展示會、討論會、現場參觀等。在條件許可的情況下，組織項目會議成員參觀一些類似的電子商務系統，作為背景參考資料，引導項目會議成員參考成功的電子商務系統的實施經驗，對會議的成功有很大幫助。IBM在全世界各地幫助實施電子商務系統的經驗表明，這樣的項目會議對項目的成功有極其重要的意義。項目會議上技術人員與業務人員面對面地交流，節省了大量時間，技術人員能更好地理解業務人員的需求，作出切合實際的方案設計，業務人員也能更好地了解技術手段的限制，雙方的溝通還可以促進企業的業務流程向更合理、更適合計算機管理的方向改進。
實際運作中，參與項目會議的管理人員的時間相當寶貴，把所有人集中起來的機會不多，項目會議的召集人不能簡單地約定一個時間就召開會議，應該在召開會議前作認真的准備。准備工作主要有以下這些：1.確定客戶方的與會者名單，和每個與會者單獨交談，說明會議的目的，聽取他們的意見收集更細致的需求。客戶方與會者人數以四至六人為宜，太多了溝通效率就會下降。2.確定開發方的與會者名單，開發方的與會者人數以四人左右為宜，主要是項目負責人、系統設計員、開發經理和技術負責人，確定會議上討論的題目，為每個題目指定責任人向客戶說明。雙方與會總人數不宜超過十二人。3.准備需求分析文檔作為討論的基礎，這些文檔主要的內容是：
目標系統概述：目標系統的主要功能描述和運作方式。
* 系統結構：當前系統的邏輯及物理結構，正在運行的軟體及其配置圖。
* 資料庫結構：描述企業核心數據的結構，確定哪些數據將開放到互聯網伺服器上，互聯網用戶訪問數據的方式與范圍。
* 網路環境：當前系統的網路拓撲結構圖，目標系統的網路結構圖，以及網路上採用的工業標准如通訊協議、命名規則等。
* 安全性要求： 企業系統當前使用的安全管理方式，以及為適應電子商務系統的運行應作出哪些安全管理方面的改進。
* 性能要求：系統性能受很多因素的影響，性能要求分析把事務流程分解，針對每一環節討論性能要求，充分討論制約性能的不利因素，以及保證性能要求的技術手段。
系統組織結構圖：企業的人事組織結構和業務流程圖，列出為了保證電子商務系統順利運行而配置的組織結構，及每個崗位的技術素質要求。4.會議召開前公布會議的主題，以及與會者名單，附上每個人的背景材料如職位、在項目中的角色等。總之，會議前訂立明確的主題和充分的准備（包括文檔准備和會前的單獨溝通）是會議成功的基礎，作為會議召集人，要在會上以自已的技術基礎與行業知識作出方向性的指導，控制時間，及時制止會上一些不能在短期內得出結論的討論。會議的重點應放在分析系統的現狀與需求，避免過早地引入特定的技術手段，以免提前給方案的設計設下局限。系統現狀的分析除了總結與回顧在第一階段所作的系統需求的結果，還可以具體地對現有環境作技術性的分析。
系統環境的技術性分析主要有以下內容：
* 網路環境的分析：網路拓撲結構分析，當前系統的網路結構，網路上的伺服器配置等。網路流量需求分析，分析當前網路帶寬是否能滿足新系統的要求。網路系統的安全體系及安全管理策略，電子商務系統是比傳統的企業網更開放的系統，安全性要求更嚴格。
* 應用環境的分析：當前系統的軟體配置及版本，應用程序的運行模式（運行平台、是否需要實時訪問和聯機事務處理等）。資料庫結構，應用系統的核心數據模式。用戶熟悉的應用開發方式和熟練掌握的開發工具，用戶的經驗可能是寶貴的資源，能加快系統開發的進度和保證系統使用的效果，因為無需重新培訓而節省成本、降低風險；也可能是採用新技術的重大阻礙，由於習慣性心理而抗拒新的開發工具和應用運行方式，即使投入大量資源重新培訓，仍然要冒很大風險，系統維護人員可能由於不熟練而發生人為失誤，造成運行故障。這種情況在中國企業中尤其普遍，系統設計人員要以非常謹慎的態度來對待。
* 客戶運行環境的分析：電子商務系統的客戶是互聯網上使用瀏覽器或其他設備的客戶，不同於傳統的企業內部網中所有客戶運行環境都是預定定製的固定環境，系統需求列出電子商務系統支持的客戶環境要求，如瀏覽器類型，是否要支持JAVA，是否支持上網手機等。
* 其他特殊需求，如客戶的系統一定要採用Linux平台，或者有特殊的多國語言字元支持問題等。
經過詳細的分析後，項目會議最可能的結果就是聽到一大堆意見和要求。一個可控制進度與預算的項目不可能達成不受控制地產生的要求，分出輕重緩急才能簡單直接地解決問題。項目負責人先取得與會者的認同，目標太多不能在一個項目內完成，請大家先選出要在當前項目內完成的目標，然後評估這些目標的重要性。如果意見不能統一，被列為很重要的目標仍然很多，就要重新篩選這些目標。對於最後列出的目標，再次徵求大家的意見，確認這些目標已經包含了目標系統的基本功能，沒有重大的錯誤和遺漏。系統設計者對被列為很重要的目標和要求應特別重視，它們是影響系統方案的主要因素。第一次項目會議的成果是詳細而明確的系統需求，系統設計人員根據系統需求和目標進行詳細的方案設計。
5、電子商務網站設計方案？
基本功能（1）企業產品和服務項目展示。這是一個非常重要的基本功能。
（2）商品和服務訂購。它包括交易磋商、在線預訂商品、網上購物或取得網上服務的業務功能。
（3）網上支付，即通過銀行電子支付系統實現支付功能。
（4）網路客戶服務。將部分或全部傳統客戶服務功能遷移到網上進行，同時根據網路特點開發新的服務功能。
（5）發布商業信息。它包括新聞的動態更新、新聞的檢索，熱點問題追蹤，行業信息、提供信息、需求信息的發布等。
（6）客戶信息管理。這是反映網站主體能否以客戶為中心、能否充分地利用客戶信息挖掘市場潛力的有重要利用價值的功能。
（7）客戶實時互動。通過聊天室、企業社區、電子郵件等工具，與客戶實時地交流信息。
（8）銷售業務信息管理。用於使企業能夠及時地接收、處理、傳遞與利用相關的銷售業務信息資料，並使這些信息有序和有效地流動起來。
分類（1）信息服務型。信息服務型網站的設計目的在於提供各種產品信息或信息獲得方式。
（2）廣告型。廣告型網站所有技術和信息內容全部針對廣告收入。此時，消費者的注意力就成為衡量網站優劣的關鍵標准，廣告商可以對一個網站進行評估，並為其廣告定價。
（3）交易型。交易型網站的基本功能在於提供網上交易的功能，如網上商城、交易平台網站等。
（4）管理型。管理型網站是企業、公司和行政教育等機構，將傳統業務遷移到網路的應用界面，如公司、機構的辦公系統。
（5）綜合型。綜合型網站是把上述類型網站的功能綜合集成。
6、目前我國電子商務的主要電子支付系統具體有哪些？
支付寶
財富通
7、電子商務系統規劃與設計包括哪些內容?
規劃設計電子商務系統的結構化方法和面向對象的方法，企業門戶網站的設計、電子商務支付系統的設計、電子商務系統安全設計，電子商務系統的實施和維護
8、電子商務支付系統的方式有哪幾種？
有四種，分別是：第三方平台，網銀，貨到付款，銀行轉賬。
9、電子商務網站常用的系統架構哪些
前台系統包括：商品展示，內容展示，訂單確認，支付系統，用戶中心四大模塊一. 商品展示
站內搜索(搜索提示，搜索規則，搜索成功頁，搜索不成功頁，相似推薦)
導航(頻道導航，其他導航如銷售排行，廣告位，推薦位，文字鏈，also buy等)
商品分類(品牌分類，品類分類，屬性分類如剪裁形式)
登陸頁(商品列表頁，商品詳細頁，商品活動頁)
這里的訪問邏輯是：a /b/c分流消費者去往相對個性化的頁面，由登陸頁體現商家的核心訴求和價值傳遞，完成call-to-action的第一步。
二. 內容展示：內容展示較為簡單，對純購物品牌而言包括：
公告區
幫助中心
論壇(如需商城與論壇發生交互，則需自行開發，否則可集成discuz做同步登陸即可)
三. 訂單確認
訂單確認，就是幫助消費者正確提交訂單信息的環節，看似簡單，實則非常復雜，需要對很多信息邏輯判斷和處理，一般由2個部分組成：
購物車
訂單提交(返回購物車，收貨地址&地址薄，支付方式判斷，配送方式，發票，訂單標記，實付金額計算等等)
四. 支付系統
與一般的想像不同，支付系統其實並不簡單等於第三方支付工具接入：
外部支付系統(支付寶將介面，財付通介面，網銀直聯埠，信用卡分期埠)
內部支付系統(賬戶余額，積分，禮品卡，優惠券)
支付系統的邏輯設計不但需要考慮到各種極端情況的發生(如一張訂單先用禮品卡，再用積分，最後網銀支付)，還要預留財務做賬所需的相關欄位，並充分考慮訂單取消之後如何回滾各類內部賬戶。
五. 用戶中心
用戶中心的實質是用戶自助功能的dashboard，一般4個部分組成：注冊&登陸(快速注冊，完整注冊，注冊有禮，推薦注冊，密碼找回，主站id登陸，open-id登陸如qq，新浪微博等)
訂單中心(歷史訂單狀態，中間狀態訂單修改，物流追蹤)
服務中心(各類自助服務如退款申請，退換貨申請，建議與投訴等)
信息管理(用戶基本信息管理和賬戶信息管理)
一. 商品&促銷
商品管理(品類管理，品牌管理，單品管理)
促銷管理(活動管理和自定義活動模板管理)
在上述模塊中，最重要的是2個部分：單品管理中的批量產品生成的自動程序和活動管理中「共享與互斥」管理。前者用於大幅提升上新速度，後者避免促銷活動失控。
二. crm ：crm是對b2c核心資源—會員的管理，服務與再營銷系統，包括如下部分：
會員管理(會員信息的增刪改查和到其他系統的鏈接)
用戶關懷(條件觸發和人工觸發相關edm &簡訊& ob)
定向營銷(會員分組和營銷活動管理)
客服管理(內容非常多，集成所有需前台與後台交互的功能，詳情還是看圖吧)
呼叫中心(ivr，坐席管理，統計報表，參數傳遞與窗口嵌入)
值得注意的，edm和簡訊通道市面上已經有成熟的外包服務商，一般都會外包；呼叫中心和在線客服自行開發成本太高，特別是呼叫中心系統，業務初期也都是外包的。
三. 訂單處理：訂單處理是在訂單未正式進入倉儲部門處理之前，對訂單的前置性處理環節。
訂單錄入(電話訂購，網上下單，外部團購訂單，無金額訂單錄入如禮品單)
訂單審核(自動審核和人工審核)
rma處理(rma申請單和rma處理單)
四. wms(warehouse management system倉庫管理系統)
wms的流程很長，功能模塊也很多，大致分為入庫管理，庫存管理，出庫管理和票據管理4個模塊四個模塊
五. 采購管理
供應商管理(供應商信息管理，合同發票管理)
采購單管理(po單管理，負po單管理)
庫存管理(庫存查詢，庫存佔用單，庫存變動log)
六 .財務管理：b2c的財務管理，主要是對供應商，渠道和內部費用支出的成本控制。
供應商結算
渠道結算
配送結算
內部結算
七. 報表管理： 報表是b2c業務的宏觀表現，理論上說，每個部門的kpi都應該從中找到。
搜索報表(站內搜索量查詢)
銷售報表(多個維度銷量查詢，優惠券使用情況，報表導出)
財務報表
客服報表(客服日報和坐席報表)，前者反映與消費者發生的日常交互(包括正常與異常)，後者考核客服的工作績效
倉儲物流報表，這幾塊報表，是業務運作的核心，涉及到公司機密，就不能寫的太細了，見諒。
八. 系統設置：這塊大家都知道是幹嘛的，也就不多說了，分成三塊。
基礎設置(和業務有關的一些欄位值)
許可權設置(不同賬號的操作許可權和操作記錄)
其他設置
九. wa系統(web analytcis)
網站分析系統，幾乎全是外購，很少有能夠自建的，即使自建，最多做幾個簡單的模塊。用於實戰的，要麼是免費的ga(google analytics)，要麼是昂貴的omniture。