❶ 電子商務網站系統需求分析的主要內容有
呵,兄弟,這個是要看是前台還是後台的,如果是後台的話,大概有這六塊:訂單,倉庫,財務,客服,商品以及顧客的資料管理。前台的是一些優化跟推廣之類的。
❷ 軟體架構是怎麼實現軟體質量屬性
復和修復是可用性的重要方面,為了阻止錯誤發展成故障,至少能夠把錯誤限制在一定的范圍內,從而使修復成為可能。維持可用性的所有方法包括某種類型的冗餘,用來檢測故障的某種類型的健康監視,以及當檢測到故障時某種類型的恢復。有些情況下,監視或恢復是自動進行的,有時需要手動。
我們事項考慮錯誤檢測,然後分析錯誤恢復,最後討論錯誤預防。
❸ 電子商務網站常用的系統架構哪些
一. 商品展示
站內搜索(搜索提示,搜索規則,搜索成功頁,搜索不成功頁,相似推薦)
導航(頻道導航,其他導航如銷售排行,廣告位,推薦位,文字鏈,also buy等)
商品分類(品牌分類,品類分類,屬性分類如剪裁形式)
登陸頁(商品列表頁,商品詳細頁,商品活動頁)
這里的訪問邏輯是:a /b/c分流消費者去往相對個性化的頁面,由登陸頁體現商家的核心訴求和價值傳遞,完成call-to-action的第一步。
二. 內容展示:內容展示較為簡單,對純購物品牌而言包括:
公告區
幫助中心
論壇(如需商城與論壇發生交互,則需自行開發,否則可集成discuz做同步登陸即可)
三. 訂單確認
訂單確認,就是幫助消費者正確提交訂單信息的環節,看似簡單,實則非常復雜,需要對很多信息邏輯判斷和處理,一般由2個部分組成:
購物車
訂單提交(返回購物車,收貨地址&地址薄,支付方式判斷,配送方式,發票,訂單標記,實付金額計算等等)
四. 支付系統
與一般的想像不同,支付系統其實並不簡單等於第三方支付工具接入:
外部支付系統(支付寶將介面,財付通介面,網銀直聯埠,信用卡分期埠)
內部支付系統(賬戶余額,積分,禮品卡,優惠券)
支付系統的邏輯設計不但需要考慮到各種極端情況的發生(如一張訂單先用禮品卡,再用積分,最後網銀支付),還要預留財務做賬所需的相關欄位,並充分考慮訂單取消之後如何回滾各類內部賬戶。
五. 用戶中心
注冊&登陸(快速注冊,完整注冊,注冊有禮,推薦注冊,密碼找回,主站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。
❹ 功能需求,質量屬性需求,約束分別對軟體架構產生哪些影響
功能性需求: 系統必須實現的功能,以及系統在運行時接收外部激勵時所做出的行為或響應。
質量屬性需求:這些需求對功能或整個產品的質量描述。
約束:一種零度自由的設計決策,如使用特定的編程語言。 質量原意是指好的程度,與目標吻合的程度,在軟體工程領域,目標自然就是需求。 對任何系統而言,能按照功能需求正確執行應是對其最基本的要求。正確性是指軟體按照需求正確執行任務的能力,這無疑是第一重要的軟體質量屬性。質量屬性的優劣程度反映了設計是否成功以及軟體系統的整體質量。 系統或軟體架構的相關視圖的集合,這樣一組從不同視角表達系統的視圖組合在一起構成對系統比較完整的表達。
❺ 如何對電子商務系統進行需求分析
從不同的角度看待
從用戶的角度
需要實現什麼功能
從企業角度
需要實現功能
從未來的發展來看
需要實現那些的功能
整體的就是系統的整體的需求和分析
採納吧
❻ 電子商務網站系統需求分析的主要內容有哪些
一言難盡,這些都是個性化的東西.不是你這樣一句話就有答案的!就像你來問這個問題一樣!明白我的意思嗎?(說道點兒上了了,轉載之)
❼ 質量屬性效用樹是對質量屬性進行( )架構分析工具。A分類B權衡C分析D修改
分析:正常負載情況下,系統必須在0.5秒內對用戶的交易請求進行響應;信用卡支付必須保證99.999%的安全性。
作用:
1、是一種工具,用於組織內部時,應確保特定產品、項目或合同的要求被恰當地納入質量計劃;在合同情況下,質量計劃能向其顧客證實具體合同的特定要求已被充分闡述。
2、可在特定產品、項目或合同上代替或減少其他質量體系文件的運用,簡化現場管理。
3、合同情況下,應在合同簽訂前編制質量計劃,並可作為質量文件的一部分參加投標。
(7)電子商務平台的軟體架構質量屬性需求分析擴展閱讀:
質量屬性包括了正確、可用等功能性屬性,也包括了性能,安全,易用,可維護等非功能性屬性。各質量屬性間本身也存 在正負相互作用力,提高某個質量屬性會導致其它質量屬性受影響,也會使項目進度成本等其它要素受到影響。
項目進度成本有限,不可能滿足所有的質量要求,因 此必須系統的確定各質量屬性滿足的優先順序,滿足的度。這裡面有QFD系統的方法,也可以參考KANO模型真正找到我們投入不多的時間和成本就能大幅增加客戶滿足度的易用性需求。