需求规格说明书
1.引言
##1.1目的 本文档首先给出项目的整体结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓。同时对功能需求、性能需求进行详细的描述，以便于用户、开发人员进行理解和交流，反映出用户问题的结构，可以作为软件工作开发的基础依据以及确认测试和验收的依据。 本文档面向的读者:
- 项目经理:项目经理根据该文档了解预期产品的功能，并据此进行系统设计 - 设计员:对需求进行分析，并设计出系统，包括数据库的设计 - 程序员:了解系统功能，开发编码 - 测试员:根据本文档对软件产品进行功能性测试和非功能性测试 - 用户:了解预期产品的功能和性能，并与分析人员一起对整个需求进行讨论和协商 ##1.2背景 - 软件名称:咸鱼 - 项目任务:软件工程课程实践 - 项目开发者:至诚学院2016级软件工程实践《善学如泉》小组 ##1.3参考文献
《GB9385-2008 计算机软件需求规格说明规范》
#2.项目概述 ##项目loge  ##用例图 
##2.1产品背景
现如今网络上的二手交易平台有很多，例如转转、闲鱼等APP，用户可以在这些APP上出手自己闲置或者想要转让的物品，这些APP给用户带来方便的同时也有许多隐患。例如二手交易的安全性、不可预知性。由于这些APP的具有跨地域交易性，因此很多二手交易的结果不尽人意。因此，我们希望能够做出一个只服务于校内学生的二手交易平台，在提高交易便捷性的同时提高交易的安全性。
##2.2产品描述我们的《跳蚤》（以下简称为本产品），是一个能够整合二手交易信息的平台。在这个平台上，我们的用户可以收集到大量的二手交易信息，并在本产品上进行二手交易，能为不知道如何出手闲置物品的学生提供可靠信息并进行二手交易。
##2.3产品功能本产品的功能主要有两个,分别是购买和拍卖。同时还兼具商品评价和用户信用评级等功能。
##2.4未来市场高校内的新生和老生往往分别具有购买和拍卖物品的需求。新生由于刚到校园，往往需要购置一些大学生日常生活必需品，而这些必需品内往往有一些需要高价才能购买到，例如按摩椅、电脑、相机等。这些物品并不是一次性的，很多都是可以重复使用的，因此以原价购入并不划算。而且大学生的日常生活习惯具有高度的重合性，因此向高年级的学长学姐收购他们不再需要的物品就是一个很好的折中方案。由此可见新生与老生之间存在需求互补的现象。因此做一个服务于校内学生的二手交易平台具有一定的市场。
##2.5用户场景 |用户|使用场景| |:--:|:--:| |用户A|A是一名刚入学的计算机大一新生，在宿舍的前一个月，坐着宿舍内的座椅敲代码的时候觉得腰酸背痛，考虑到未来的很长一段时间都需要在电脑面前度过。因此他决定购买一张按摩椅来缓解长期坐在电脑前的痛苦。他去某宝上查看了按摩椅的价格，一看好一点的都要大几百甚至上千，因此他决定买入一张二手的按摩椅。他使用了本产品，很快找到了一张心仪的按摩椅---这是一位快要离校的学长在大二的时候买入的，现在还很新，最后A买入了这把椅子，以很低的成本解决了自己的需求。| |B|B在大二上学期选修了学校的网球课，体育老师要求大家需要自带网球拍，由于网球课只上一学期，而且B对于网球运动并不是很感兴趣，因此买一个全新的球拍并不合算，因此他到我们的APP上发布收购二手网球拍的消息，用较低的成本成功的买入一个二手的网球拍。在课程结束后，他又将网球拍进行拍卖,用较低的成本解决了自己的需求。| |C|C在大三的时候萌生了考研的想法，但是苦于没有经验，不知道从何开始。他就想能不能向往年的学长买一些考研笔记，让自己更有方向。因此他在我们的APP上发布了这类消息，很快他同专业的一个刚刚考研完的学长找到了他，达成了交易的意向。通过学长的笔记他很快就找到了考研复习方向的确立，为自己的考研之路制定了明确的目标。| ##2.6假设与约束 ###2.6.1假设 - 可操作性：假设使用本产品的用户在经过一段时间的熟悉后，可以灵活地操作本产品 - 用户支持：假设本产品开发的各个环节中得到用户的有效支持和积极配合 - 技术支持：假设开发初期，项目架构设计合理，小组成员充分认识本产品的需求，认真学习相关知识。开发过程中遇到的技术问题可以及时得到老师的指导与帮助。开发后期，团队熟练掌握适用于该项目的技术，充分优化系统性能 - 人员配合：假设团队成员的积极合作配合，为了项目的开发和实施，能够合理规划个人时间，并且在必要时，能为团队做出合理牺牲，配合队友完成任务。若小组成员变动，新旧成员能够出色地交接和快速了解项目、投入开发；若小组成员无变动，则假设项目开发过程中不会有突发情况导致项目成员无法正常参与开发工作 - 时间限定：假设项目截止日期不会提前 - 需求限定：假设项目需求确定后不会有太大改动 ###2.6.2约束 - 人员约束：团队成员皆为大三学生，共 7人 - 管理约束: 本次开发实行以一人担任组长，分工合作的模式进行。力求每个人的分工涉及开发过程中的所有流程，并按照进度表进行，开发过程遇到的问题通过小组会议得到一致解决。小组成员首次合作，需要一个磨合的过程，需要明确自身责任，分清各自任务，互相配合，遇到问题组长必须能进行有效的协调，才能快速、较好地完成开发过程 - 技术约束：小组成员在相关技术水平方面存在一定的欠缺，缺乏相关的项目经验，需要在开发中并发学习多种技术和能力；在文档编写能力方面也有待提升 - 时间约束：本项目开发周期短，时间相对紧张，两个月的开发时间需要开发者合理规划时间，做到多项任务并发 - 其他约束：开发期间，小组成员还有其他科目的学习任务，将对项目进度造成一定影响#3.具体需求 ##3.1外部接口需求 ###3.1.1用户接口 无特殊要求; ###3.1.2硬件接口 无特殊要求; ###3.1.3软件接口 IE8.0及以上； ###3.1.4通信接口 无特殊要求; ##3.2功能需求 ###3.2.1界面原型 - 首页：商品类型总览及热门商品推荐  - 注册登录：新用户注册、已有用户登录界面   - 商品详情:查看商品详情  - 商品发布:发布商品信息，进行拍卖  - 个人信息:查看、修改个人信息  ##3.3产品属性 ###3.3.1可用性 - 界面简洁大方，操作简便，易于用户使用 - 能够支持多人同时在线使用 - 能稳定运行，出现突发状况时能保证用户资料完整、正常退出程序 ###3.3.2安全性 - 能对用户身份进行识别，避免非用户本人对用户账号进行操作 - 在多用户并发运行时能保证用户数据完整性、独立性 ###3.3.3可维护性 - 系统能定期更新迭代、修复bug - 对系统进行更新迭代、修复的时候能保证用户数据的完整性、独立性
#4.验证验收标准 ##4.1文档验收标准 - 组员的文档格式统一 - 文档编写符合国际文档编写规范 ##4.2软件验收标准 - 客户端:用户能进行正常的检索、拍卖、收购等功能 - 服务器端：管理员能正常的对用户、数据库进行管理 ##4.3界面验收标准 - 界面简洁大方，操作简便，易于用户使用 ##4.4功能验收标准 - 购买：用户能正常购买商品 - 拍卖：用户能正常拍卖商品 - 评价：用户能正常评价商品、商家 - 举报：用户能够举报已购买过商品的商家，进行举报 - 学号注册：用户能够使用学院学号注册账号 - 检索商品：用户能正常检索商品 - 注册、登录：用户能正常注册、登录网站 ##4.5初期版本最核心完成内容 - 完成整体界面UI的设计及展示 - 实现用户正常的登录、注册 - 实现商品展示 - 实现购买、拍卖两大核心内容 - 实现多人并发操作
