武綠有機**專案
文件狀態：v0.1
撰寫：肖松
文件修改記錄
目錄文件修改記錄 1
1 引言 1
1.1 目的 1
1.2 預期讀者和閱讀建議 1
1.3 產品範圍 1
1.4 參考文獻 1
2 系統概述 3
2.1 任務背景 3
2.1.1 簡單性和實用性 3
2.1.2 整合性 3
2.2 產品功能 3
2.3 使用者特點 4
2.4 執行環境 4
2.4.1 硬體平台 4
2.4.2 支援軟體 4
2.5 設計和執行約束 5
3 介面需求 6
4 功能需求 7
4.1 需求類1名稱優先級別 7
4.1.1 業務流程 7
4.1.2 功能需求 7
5 非功能需求 8
5.1 效能需求 8
5.2 安全設施要求 8
5.3 安全和保密要求 8
5.4 質量要求 9
5.5 業務規則（選） 9
5.6 其它需求 9
附錄1：待確定問題清單 9
本文件是在對武綠有機**電子商務平台軟體進行總體分析後，得出的對武綠有機**電子商務平台的需求說明。本文將對武綠有機**電子商務平台軟體的軟體需求進行詳細的定義，並以需求基線的形式確定下來，對之進行嚴格的控制，目的是準確和正確地滿足武綠有機**電子商務平台需求，減少返工。
本文件將作為對正式發布版本武綠有機**電子商務平台軟體進行設計開發和驗收活動的依據。
專案經理——仔細閱讀文件的所有細節，同時對文件進行修改和審批
開發人員和測試人員——仔細閱讀每個需求功能說明和效能要求，同時制定自己的計畫時間和基線；
武綠有機**平台電子商務平台軟體是內集各公眾平台使用者資源領域的電子商務平台，公司和第三方客戶使用以後即可以不僅可以將客戶資訊、管理資訊、庫存資訊、購銷資訊等資訊孤島同電子商務平台有機的整合，形成一致的、可靠的、安全的、共享的資訊系統，又可以提高的推廣的的效率和增加推廣的渠道。對於公司不僅可以取得經濟上的直接利益，同時也極大促進了今後占領本領域的市場份額，樹立自己的品牌形象。
作為國內集各公眾平台使用者資源領域的電子商務平台，武綠電子商務平台總體結構的設計應從體系、功能、過程、資訊等各個方面保證整個電子商務平台總體目標的實現，以提高市場競爭能力。其總體設計原則應以下設計原則：
將管理技術、資訊科技等有機融合而成的電子商務技術是當前傳統工業技術的一次改革。電子商務平台主要面向的是客戶，而每個客戶的水平良莠不齊，因此要求平台設計簡單實用，同時又具備先進性，使整個專案立足於高起點，又能滿足公司的實際要求。
● 整合國內所有已開放的公眾平台和其他使用者資源較多的平台，將我們電子商務平台的資訊散步到各個使用者群體多的地方，不僅僅是單一的**。
● 將公司的客戶資訊、管理資訊、庫存資訊、購銷資訊等資訊孤島同電子商務平台有機的整合，形成一致的、可靠的、安全的、共享的資訊系統。
2.1.3 與公司改革相輔相成
電子商務平台為公司改革提供了一系列的資料支援、系統支援及決策支援。同時公司的改革需求又必將反饋到平台，這樣互相推動，形成有效的電子商務模式。
武綠有機**電子商務平台是為公司、銷售第三方、客戶提供乙個網上的虛擬交易平台。解決了推廣渠道原始且不足，資訊孤島等現象。主要的功能包括：
使用者註冊、商家入駐、產品搜尋、產品發布、產品購買等功能。
使用者可能更關注登入、搜尋、商品鏈結跳轉、支付鏈結跳轉等功能，這些功能通常需要一天使用多次，因此對快速響應的效能要求很高，對資料的準確性有一定要求。
商家可能更關注商品的上架、銷售情況等功能，這些功能通常只要的一天使用幾次，因此對於快速響應的效能要求不是很高，但對資料的準確性有要求。
公司可能更關注使用者的使用量、**流量、交易額等，這些檢視功能這些功能通常只要的一天使用幾次，因此對於快速響應的效能要求不是很高，但對資料的準確性有要求。
面對軟體的眾多使用者（還可能是使用軟體的不同角色），當他們的需求發生衝突時，首先考慮的應當是服從重要客戶的需求，其餘的需求可以考慮在下一版本實現。
開發需要遵循以下文件約束：
資料介面模組，需同商品品類管理系統資料、體系結構相匹配，包括平台庫存模組與內部系統庫存模組的介面、平台配送模組與內部系統配送模組的介面、平台使用者模組與內部系統配送模組的介面、平台支付模組與內部系統結算模組的介面、平台產品發布模組與內部系統**模組的介面等
使用一種或幾種最恰當的方式，如流程圖、表或者uml語言等，來表述系統執行該需求任務的輸入/輸出響應。
軟體效能需求通常包括以下方面：
1. 同時支援的最大使用者數、同時支援操作的個數、某時刻能承受的最大資料量、資料最大儲存量、對系統執行時允許占用的系統資源要求；
2. 系統持續執行時間、響應時間、資料更新處理時間、資料間的轉換和傳輸時間、介面重新整理處理時間的要求；
3. 在不同安裝/執行環境、不同操作方式下，或者與其它子系統介面發生改變時，某些資料和引數可以允許的變化範圍。
//軟體應用的領域不同，對其效能的要求可能也不盡相同。即使是為客戶量身定做的專用軟體，客戶對某些效能的要求或許比某個功能更加重要和嚴格。因此應當解釋這種要求，以便做出合理的設計和優化的演算法。
//當這些效能要求已經分散到各項功能需求當中，這裡的敘述就是不必要的。
範例：當有30個以上的使用者同時對系統執行查詢操作時，系統的相應時間應當不多於2秒，頁面重新整理頻率應當在0.2次/秒~0.3次/秒。
//闡述的是與使用軟體過程中可能發生的損失、破壞或危害相關的需求，滿足安全設計要求。
說明為避免或減輕對相關人員、財產和物理環境產生危害，而必須採取的措施，以及為預防的潛在的危險動作而必須遵從的安全標準、策略或規則。
範例：如果軟體系統探知配電室的最高溫度超過了35度，軟體必須立刻同時啟動三颱冷風空調。
說明與系統安全性、完整性和保密性相關的需求，明確產品必須滿足的安全保密策略。
//例如：防止非法訪問系統功能及資料丟失而要求使用者身份確認，防止病毒入侵和黑客進攻而增加的警告攔截等功能。
說明其它的軟體質量屬性要求（可能從合同中或系統需求中匯出，對使用者來說至關重要）。這些特性應當是確定的、定量的、並在必要時可驗證。如果這些屬性之間發生了衝突，指明相對的側重點是什麼。
質量屬性通常如下：
可靠性（軟體能夠無故障的執行一段時間的概率）、可維護性（對軟體進行修改的難易程度——修改所用時間、修復的比率）、有效性（軟體正常執行時間/總時間）、可用性（掌握軟體操作的難易程度）、重用性、可測試性（查詢缺陷的難易程度）、可移植性等。
//如，可靠性優於可維護性。
//對軟體本身的操作規則，通常可以在某些功能需求中體現。
//定義在軟體需求說明書中其它部分未出現的需求，例如國際化需求或法律上的需求。還可以增加有關操作、管理和維護部分來完善產品安裝、配置、啟動和關閉、修復和容錯，以及登入和監控操作等方面的需求。還可包括對於交付的產品文件的要求、培訓要求、開發進度要求等等。
//如果不需要增加其它需求，可以省略這一部分。
附錄1：待確定問題清單
將文件中待確定的問題（tbd）列出，便於今後的跟蹤確認。
軟體需求說明書
軟體需求說明書的編制是為了使使用者和軟體開發者雙方對該軟體的初始規定有乙個共同的理解，使之成為整個開發工作的基礎。編制軟體需求說明書的內容要求如下 版本歷史 目錄1 引言 1 1編寫目的 1 2背景 1 3定義 1 4參考資料 2 任務概述 2 1目標 2 2使用者的特點 2 3假定和約束 3 需求...
軟體需求說明書
軟體需求說明書的編制是為了使使用者和軟體開發者雙方對該軟體的初始規定有乙個共同的理解，使之成為整個開發工作的基礎。編制軟體需求說明書的內容要求如下 1.1編寫目的 說明編寫這份軟體需求說明書的目的，指出預期的讀者。1.2背景 說明 a 待開發的軟體系統的名稱 b 本專案的任務提出者 開發者 使用者及...
物流軟體需求說明書
軟體需求規格說明書 目錄 目錄 2 第1章概述 4 1.1 使用者簡介 5 1.2 專案的目的與目標 5 1.3 假設與約定 6 1.4 前景 6 1.5 術語定義 7 1.6 參考資料 7 第2章目標系統描述 7 2.1 目標系統概述 7 2.1.1 目標系統建設背景 7 2.1.2 目標系統的特...