****超市
超市貨物管理系統 項目
軟件需求規格說明書
THE BUG 團隊
二零二零年五月
1、引言
1.1 編寫目的
為明確軟件需求、安排項目規划與進度、組織軟件開發與測試，撰寫本文檔。
1.2 文檔格式
本文檔按以下要求和約定進行書寫：
（1）標題最多分三級，大標題為宋體三號加粗，中標題為宋體四號加粗，小標題為宋體小四加粗
（2）正文為宋體小四號，無特殊情況下，字體顏色均采用黑色。
（3）行和段落間距為1.5
（4）特殊情況另作規定
1.3 預期的讀者和閱讀建議
本文檔的主要內容共分4部分：綜合描述、系統特性、非功能性需求和外部接口描述。綜合描述部分主要對系統的整體結構進行了大致介紹；系統特性部分對系統的功能需求進行了詳細描述，是本文的主要部分；非功能性需求部分對非功能需求進行了詳細的描述；外部接口需求部分對用戶界面、軟件接口、硬件接口和通訊接口等進行了描述。
本文檔面對的讀者對象：
（1）項目經理：項目經理可以根據該文檔了解預期產品功能，並據此進行系統設計、項目管理。
（2）設計員：對需求進行分析，並設計出滿足需求且簡單實用的系統，包括數據庫的設計。
（3）程序員：配合《設計報告》，充分了解系統性能，編寫用戶手冊。
（4）測試員：根據本文檔編寫測試用例，對軟件產品進行功能性測試和非功能性測試。
（5）銷售人員：充分了解產品的功能和性能。
（6）用戶：了解預期產品的功能與性能，並與開發設計人員對需求進行討論和協商。
（7）其他人員：如部門領導、公司領導等可以據此了解產品的功能與性能。
在閱讀本文檔時，首先要了解產品的功能概貌，然后根據自身的需要對每一功能進行適當了解。
1.4 范圍
該產品是在聽取了**超市的實際客戶需要，並在該超市進行了10天的統計觀察，結合了當地用戶的實際情況。本產品在適用大多數小型超市的情況下，對**超市進行了特色性改進，主要完成貨物錄入，貨物查詢，銷售統計及分析等業務。
1.5 術語
1.6 參考文獻
2、需求概述
2.1 目標
通過使用管理系統，方便超市管理人員對貨物的錄入售出以及各貨物的詳細信息進行管理和查詢。
2.2 用戶特點
本軟件最終用戶面對管理員，即超市內相關工作人員如：經理、倉管人員、銷售員，在進行培訓以后可熟練使用本系統。超市內工作人員為經常性用戶。
系統維護人員為計算機專業人才，熟悉數據庫、操作系統、網絡維護。系統維護人員為間隔性用戶。
2.3 功能需求
主要功能
系統管理（權限設置，當前操作員，角色設置）
1.權限設置，設置進入該系統的身份
2.當前操作員，顯示當前進入系統操作員的基本信息
3.角色設置，設置員工職位
信息管理（貨物，人員信息管理）
1.貨物信息管理，增加、修改、查找、刪除貨物信息
2.人員信息管理，增加、修改、查找、刪除內部員工信息
銷售管理（賣出 買入）
1.貨物出售信息
2.貨物買入信息
綜合分析（出入庫明細，盈利等等）
1.貨物出入庫明細
2.貨物庫存查詢
3.超市流水時段分析
4.某商品銷售情況分析
5.商品銷售排行分析
6.即將過期商品分析
2.4 數據描述
通過對超市貨物管理系統需求及其數據流圖分析，可得出該系統設計員工、商品、出入庫信息表等數據實體。E-R圖如下：
2.5 性能需求
此開發項目針對超市，使用頻率和性能要求都較高。為防止信息資料和管理程序的惡意破壞，要求有較為可靠的安全性能。要求穩定、安全、便於管理與操作。
- 查詢速度不超過5s；
- 交互功能反應速度不超過5s；
- 平均故障間隔時間不低於300h；
2.6 其他需求
數據輸入輸出格式、數值范圍、數據精度統一
1.硬件故障存在不可預見性，應經常對其進行檢查修復
2.網絡故障保證前台收銀系統照常運行
3.誤操作需提示警告，並提供容錯方法
2.7 運行環境
2.7.1 硬件環境
服務器
1.處理器CPU：Pentium 900M
2.內存容量RAM：256M+
客戶端
1.處理器CPU：Pentium 133M（以上）
2.內存容量RAM：64M+
2.7.2 軟件環境
1.操作系統：收銀員采用Windows XP,后台服務器采用Windows NT2000
2.數據庫系統：收銀台和后台服務器采用MSSQL2000
3.數據接口：前后台均采用ADO.NET
2.7.3數據庫表的建立
1.銷售信息表
(單號，訂單(商品編號 商品名 數量 單價 總價)，總價格，日期(精確到時))
2.商品信息表
(名稱，生產廠家，進貨價格，出售價格，數量，生產日期，保質期)
3.員工信息表
(工號，姓名，職位，手機號碼，微信)
4.拓展信息表
(當前登錄信息，等)
2.7.4 接口
硬件接口
考慮到大量數據備份的要求，需保持與磁帶機和光盤刻錄機的接口，較容易實現
軟件接口
主要考慮軟件與操作系統、數據庫管理系統的接口，以及局域網和互聯網軟件之間的數據交換。文檔處理時需要常用辦公軟件：Microsoft的office系列，應盡量實現它們之間的數據格式和自動轉換。
2.7.5 控制
本系統采用目前主流技術，對程序的運行和控制無特殊要求
3. 系統特性
3.1系統管理
3.1.1角色設置：角色設置分為經理，系統管理員，銷售員
3.1.2權限設置：
3.1.3當前操作員：不同的職位登錄會有不同的權限
3.2信息管理
3.2.1貨物信息管理
1. 用例簡述
管理員和員工可以通過該頁面查詢信息
2. 基本事件流
（1）用戶提交請求
（2）系統顯示商品信息
（3）用戶：更新，修改，刪除商品信息；
（4）系統：保存修改后信息
（5）結束
3.商品屬性（名稱，生產廠家，進貨價格，出售價格，數量，生產日期，保質期）
商品信息表預覽：
| 編號 |
名稱 |
數量 |
進貨價格 |
出售價格 |
生產日期 |
保質期 |
生產廠家 |
| 商品1 |
|
|
|
|
|
|
|
| ...... |
|
|
|
|
|
|
|
4.活動圖：
3.2.2員工信息管理
1. 用例簡述
管理員管理員工信息。
2. 基本事件流
（1）管理員申請查看員工信息
（2）系統顯示用戶請求
（3）管理員可進行修改員工信息
（4）系統保存員工信息
（5）結束
3.員工信息表預覽：
| 工號 |
姓名 |
職位 |
手機號碼 |
微信 |
| 員工1 |
|
|
|
|
| ..... |
|
|
|
|
4.活動圖
3.3銷售管理
3.3.1銷售員通過銷售管理功能進行商品賣出。
3.3.2經理通過銷售管理進貨。
3.3.3銷售員和經理都可以通過銷售管理查詢訂單表和銷售記錄
3.4綜合分析
超市的管理人員（如銷售經理）可通過分析查詢商品的的庫存情況、銷售利潤盈利以及的銷售情況等，便於在進貨時能針對性地選擇熱銷的商品以及了解超市的營銷情況，或者通過分析得知滯銷的商品的銷售情況可進行適當地降價或促銷等。
3.4.1貨物出入庫明細
按時間段查看貨物出入情況
3.4.2貨物庫存查詢
查詢某商品在倉庫的存儲量
3.4.3超市流水時段分析
按時間段查詢超市的流水狀況，例如可以查看某季度、某星期、某日、或某年的流水，查詢結果可用圖表表示
3.4.4某商品銷售情況分析
根據時間段分析某商品的銷售利潤或者銷售數量。通過該功能的查詢可以得到該商品近期的銷售情況和利潤，分析結果用圖表直觀體現
3.4.5商品銷售排行分析
商品間可以在某時間段內以銷售數量或銷售利潤進行排行
3.4.6即將過期商品分析
通過計算生成日期，保質期和現時間得到某批進貨商品距離過期或已經過期的時間，並按該時間進行排行。可以將貨物簡單划分幾個狀態：已過期、即將過期（兩個月內）、未過期
4.非功能性需求
4.1 性能需求
（1）一般響應速度不超過1秒。
（2）查村速度不超過3秒。
（3）支持500種貨物信息的一次性導入，導入時間不超過100秒。
（4）支持200名用戶並發使用，並保證性能不受影響。
（5）平均故障間隔時間不低於200h。
4.2 安全性需求
（1）根據不同用戶角色，設置相應權限，用戶的重要操作都做相應的日志記錄以備查看。
（2）對一些重要的數據按一定的算法進行加密。
（3）能經受來自互聯網的一般性惡意攻擊。
（4）能夠記錄系統運行時所發生的所有錯誤，包括本機錯誤和網絡錯誤。
4.3可用性需求
（1）盡量從用戶角度出發，以方便使用本產品，如查詢貨物時輸入漢語簡拼快速檢索到結果。
（2）支持沒有計算機使用經驗、計算機使用經驗較少的用戶能方便地使用本系統，如兒童老人等用戶。
（3）誤操作應提示警告和提供容錯方法.
（4）在90%的故障中，系統最多需要20秒重啟。
（5）在網絡環境差的條件下保證系統的可用性。
4.4 其他需求
（1）高可擴展性
（2）系統安裝方便，易於維護。
預期用戶數量：200
系統價值及其意義
（1）真實性：在我們鄉鎮中就有一家小型超市，經過我的調查發現該超市的管理人員和銷售人員比例達到了1:5，遠超同規模的城市超市管理與銷售比，該超市大量的成本浪費在雇佣管理人員上。有感而發開發這個項目。
（2）可用性：該系統結構精簡，操作簡單，不對使用者文化水平有過高要求，適合鄉鎮超市。
（3）價值：在如今的各個鄉鎮的中小型超市中，超市的貨物人員管理是一個痛點、難點，市面上的超市管理系統往往結構龐大、操作復雜、價格昂貴，因此這樣一個精簡實用的超市管理系統能幫助各個中小型超市提高管理效率的同時不帶來太大的財政壓力、管理難度。
團隊項目的碼雲鏈接 https://gitee.com/the-bug/surpermaket
碼雲的團隊項目issues截圖
團隊項目時間安排表
校正前
| 第 8 周 |
1.團隊組隊、團隊博客 |
|
|
2.團隊介紹、成員展示、角色分配、選題確定 |
|
|
3.制定團隊計划安排，團隊貢獻分的規定 |
| 第9周 |
1.需求規格說明書 |
|
|
2.原型設計，隊員估計任務難度並學習必要的技術 |
|
|
3.編碼規范完成、平台環境搭建完成、初步架構搭建 |
| 第10周 |
1.原型改進（給目標用戶展現原型，並進一步理解需求） |
|
|
2.架構設計，WBS, 團隊成員估計各自任務所需時間 |
|
|
3.測試計划 |
| 第11、12周 |
1. 團隊項目Alpha任務分配計划 |
|
|
2. 連續7天的Alpha敏捷沖刺，7 篇 每日Scrum Meeting博客+代碼提交 |
| 第13周 |
1.用戶反饋+測試計划改進 |
|
|
2. 團隊Alpha階段個人總結 |
|
|
3. 團隊項目Alpha博客：發布說明、測試報告、展示博客、項目管理 |
| 第14周 |
1. 團隊項目Alpha博客：事后分析 |
|
|
|
校正后
| 第 8 周 |
1.團隊組隊、團隊博客 |
|
|
2.團隊介紹、成員展示、角色分配、選題確定 |
|
|
3.制定團隊計划安排，團隊貢獻分的規定 |
| 第9周 |
1.需求規格說明書 |
|
|
2.原型設計，隊員估計任務難度並學習必要的技術 |
|
|
3.編碼規范完成、平台環境搭建完成、初步架構搭建 |
| 第10周 |
1.原型改進（給目標用戶展現原型，並進一步理解需求） |
|
|
2.架構設計，WBS, 團隊成員估計各自任務所需時間 |
|
|
3.測試計划 |
| 第11、12周 |
1. 團隊項目Alpha任務分配計划 |
|
|
2. 連續7天的Alpha敏捷沖刺，7 篇 每日Scrum Meeting博客+代碼提交 |
| 第13周 |
1.用戶反饋+測試計划改進 |
|
|
2. 團隊Alpha階段個人總結 |
|
|
3. 團隊項目Alpha博客：發布說明、測試報告、展示博客、項目管理 |
| 第14周 |
1. 團隊項目Alpha博客：事后分析 |
|
|
|
矯正算法：因我們團隊目前能及時完成原定計划安排，故計划基本不變
成員分工、完成情況及感想
楊梓琦 產品經理
分配的任務及完成情況
協調團隊工作 - 已完成
整理團隊博客 - 已完成
撰寫項目需求說明書（部分） - 完成
學習必要技術 - 未完成
個人感想：第一次進行團隊開發項目，意識到了自己的知識儲備不夠充分導致較少提出建設性的意見，身為組長和產品經理沒有很好地積極組織起成員。接下來的時間中要努力進取。
鄭堡恩 開發人員（后續視情況可能會加入測試人員一同進行測試）
分配任務以及完成情況
撰寫項目需求說明書（部分） - 完成
學習必要技術 - 未完成
個人感想：第一次進行團隊協作，在開始討論時所有成員都不是很熟練的樣子，希望在接下來的合作中大家一起共同進步完成這次團隊項目！
陳傑才 開發人員
分配任務以及完成情況
撰寫項目需求說明書（部分） - 完成
學習必要技術 - 未完成
個人感想：盡管這次的團隊項目開發的內容可能相對比較傳統，較於其他團隊沒有什么創新的地方。但是我認為，團隊內部之間的合作遠比項目內容本身重要。不要妄自菲薄，一起加油！
李華 開發人員
分配任務以及完成情況
撰寫項目需求說明書（信息管理部分） - 完成
學習必要技術 - 未完成
個人感想：自己知識儲備太少了，很多時候跟不上隊友的思維，說不出自己的想法，還是得好好學習基礎知識，希望能配合好隊友一起解決問題。
溫海源 開發和測試人員
分配任務以及完成情況
撰寫項目需求說明書（系統管理部分） - 完成
學習必要技術 - 未完成
個人感想：要學的知識還是有些難的，需要多花時間還有跟隊友更好合作。
鍾明康 開發人員
分配任務以及完成情況
撰寫項目需求說明書（信息管理部分） - 完成
學習必要技術 - 未完成
個人感想：第一次進行團隊協作，陌生的同時帶點緊張，希望能做好自己的工作，學到必要的技術，圓滿完成這次的作業，