第二次团队项目--用户需求规格说明书
****超市
超市货物管理系统 项目
软件需求规格说明书
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.原型设计，队员估计任务难度并学习必要的技术，其中要重点突破java技术，充分了解如何用java构建数据库，各成员熟练掌握码云的使用技巧。 |
|
|
3.形成统一的、易维护的代码规范，搭建出适合开发的java平台环境，完成初步架构搭建 |
|
第10周 |
1.和客户讨论原型，并针对用户反馈的问题进行针对性改进 |
|
|
2.完成架构设计，WBS, 团队成员充分了解各自任务并估计出所需时间 |
|
|
3.对项目进行测试 |
|
第11、12周 |
1. 实现需求说明书的功能、前端搭建完成 |
|
|
2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 |
|
第13周 |
1.进一步完善前端的可操作性、实现拓展功能、增加程序稳定性， |
|
|
2. 团队Alpha阶段个人总结 |
|
|
3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 |
|
第14周 |
1. 团队项目Alpha博客：事后分析 |
|
|
|
矫正算法：因我们团队目前能及时完成原定计划安排，故基本计划不变，详细化一些关键步骤，让目标更加明确
成员分工、完成情况及感想
杨梓琦 产品经理
分配的任务及完成情况
协调团队工作 - 已完成
整理团队博客 - 已完成
撰写项目需求说明书（部分） - 完成
学习必要技术 - 未完成
个人感想：第一次进行团队开发项目，意识到了自己的知识储备不够充分导致较少提出建设性的意见，身为组长和产品经理没有很好地积极组织起成员。接下来的时间中要努力进取。
郑堡恩 开发人员（后续视情况可能会加入测试人员一同进行测试）
分配任务以及完成情况
撰写项目需求说明书（部分） - 完成
学习必要技术 - 未完成
个人感想：第一次进行团队协作，在开始讨论时所有成员都不是很熟练的样子，希望在接下来的合作中大家一起共同进步完成这次团队项目！
陈杰才 开发人员
分配任务以及完成情况
撰写项目需求说明书（部分） - 完成
学习必要技术 - 未完成
个人感想：尽管这次的团队项目开发的内容可能相对比较传统，较于其他团队没有什么创新的地方。但是我认为，团队内部之间的合作远比项目内容本身重要。不要妄自菲薄，一起加油！
李华 开发人员
分配任务以及完成情况
撰写项目需求说明书（信息管理部分） - 完成
学习必要技术 - 未完成
个人感想：自己知识储备太少了，很多时候跟不上队友的思维，说不出自己的想法，还是得好好学习基础知识，希望能配合好队友一起解决问题。
温海源 开发和测试人员
分配任务以及完成情况
撰写项目需求说明书（系统管理部分） - 完成
学习必要技术 - 未完成
个人感想：要学的知识还是有些难的，需要多花时间还有跟队友更好合作。
钟明康 开发人员
分配任务以及完成情况
撰写项目需求说明书（信息管理部分） - 完成
学习必要技术 - 未完成
个人感想：第一次进行团队协作，陌生的同时带点紧张，希望能做好自己的工作，学到必要的技术，圆满完成这次的作业，
