项目背景和范围：
①背景：在急需志愿活动的今天，在部分个人物品无从处理时，有什么比将两者结合起来，给同学们提供便利更加有意义的事吗？没有！所以，为了调动同学们的积极性，献出爱心，同时简化学校慈善组织的工作，顺便还可以让同学们得到满意的志愿时长证明，甲方提出了该需求项目，想要一个具有以下功能的微信小程序。
②初步要求：
学生通过学号注册和登录；
学生可以将自己不需要的书籍，衣物等其他物品捐出，在应用上上传信息和图片；
由学生组织工作人员审核所发信息；
通过之后会留言给学生，之后方便进行线下交易；
可记录学生通过这个平台所获取的总志愿时长，有明确的时间，授权组织；
如果学生有违约行为，可经工作人员处理，暂时封号或者扣除志愿时长；
1.本周计划：
需求获取和分析，初步建立第一个模型（面向对象建模：目前一般采用Axure原型工具制作系统或功能原型。）
/*用户：涉众分类与描述；涉众评估（优先级，风险，共赢分析）；参与策略制定（敏捷方法—用户参与）
需求：功能需求与非功能需求；需求细化；划分需求优先级；
建立需求方案，确立约束条件（系统（兼容性），环境（操作系统等），资源）；
*/
5.13-15：将模块细分，然后分工处理，初步解决问题。
5.15：与甲方开会，我方全员参与。针对甲方的需求我方展示初步的解决方案。
5.16：经过与甲方的沟通，进行需求的增改。制作ppt，写博客。
2.详细人员分工安排：
博客+ppt：张芷璇；
需求描述：蒋雨彤；
用户描述：管熙玉；
建模：宋铁男，吴洋；
3.与甲方沟通情况：
| 时间：2019.5.15 9pm. | |
| 地点：图书馆一层大厅 | |
| 甲方到场人员：(2/2) | 乙方到场人员：(5/5) |
| 苏松林 张建新 | 张芷璇 蒋雨彤 管熙玉 吴洋 宋铁男 |
详细内容如下：
- 由我方向甲方汇报工作进展。
- 甲方提出新需求：
登录页面的设计；
捐赠物品的后续追踪；
选择身份进入系统；
志愿者用户说明；
能通过关键字搜索志愿活动；
副功能：个人申请（学生->组织）
4.目前成果：
①功能需求与非功能需求
1、功能需求：
学生志愿者通过学号注册和登录，并与教务处进行绑定；
志愿者将自己不需要的书籍，衣物等其他物品捐出，在app上上传信息和图片；
志愿者组织需要通过第三方进行认证；
由组织团体的工作人员审核所发信息；
工作人员对志愿者发布的信息留言；
可记录志愿者通过这个平台所获取的总志愿时长（有明确的时间，授权组织的记录）；
工作人员可针对违规志愿者向管理员发出暂时封号或者扣除志愿时长的请求；
由第三方管理员作为软件管理者进行数据管理和请求的处理；
2、非功能需求：
软件符合法定的相关标准；
能够在故障后重建、恢复数据；
可靠性程度要高，信息不会随意泄露；
可维护性程度要高；
进行系统构造时的编程语言为c++或者java；
兼容ios和Android系统；
至少能够存储10000个用户的信息；
允许500个用户同时进行操作；
因软件缺陷而导致的故障频率程度低于20%；
系统响应时间在5—10秒，将内容上传至数据库；
内存占用空间较小；
需求优先级：
功能需求—>非功能需求；
②用户:
涉众分类及描述：
1.管理人员：(团委)，可以查看后台数据，管理使用软件的组织和志愿者，对不符合要求或违约志愿者和团体可进行注销或禁发布信息操作
2.认证的组织和团体 可以发布信息，收集物品，对志愿者进行审核，对志愿者的留言进行回复，发放志愿时长。对于违约志愿者，可加入黑名单或进行申诉，由管理者对其进行处理
3.志愿者 需注册登录，可以查看各个组织发布的信息并进行留言沟通，捐赠物品，获得志愿时长，对于违约志愿组织可以进行申诉，由管理者进行处理
涉众评估--优先级:
1.志愿者(可将志愿团体对管理者进行申诉)
2.志愿团体(可对违约志愿者加入黑名单或对管理者进行申诉)
3.管理人员(总管软件内部数据信息)
实现共赢：
志愿团体:发布信息受众广，信息传播速度快，与志愿者沟通便利，可及时为志愿者发放志愿时长
志愿者:获取信息方便，可公平公开且及时的获取志愿时长
管理者:提高了对志愿团体和志愿者的管理效率，纠纷发生时可以快速查询到需要的数据对冲突进行及时处理
④面向对象建模用例图：
5.原型：
项目流程图：
部分界面参考设计如下：
6.未来计划：
13周：建模（原型 面向对象 结构化方法 p102-103） 开始书写需求规格说明书（模板：IEEE1998）
14周：基本完成建模和书写用户使用需求（用例）文档（分为组织工作人员和普通学生）
15周：需求验证，调试，完善，维护，反馈。
7.甲方组长确认：
8.需求文档进程：
目前完成了
项目前景和产品范围；
具体需求（功能与非功能）；
用户特征与分析。
9.老师建议:
其他：和团委，志愿组织以及其他真实涉众（学生）进行面谈沟通。获取进一步真实需求。
