1.整体计划安排
2.团队分工
①alpha版本需要做的事
前端
后端
②各成员分工及TODO list
③燃尽图
（因为整个团队项目的ddl与完成时间未定，所以此处只是本次“需求分析报告”的燃尽图）
3.思维导图
①思维导图-首页
直观充分地展示了借呗的两个核心业务：
活动室的申请和管理、个人仓库里物品的租借和管理。
②思维导图-我的
“我的”页面主要分为：我租借的、我管理的、信用度三大部分。
我租借的：包含用户所租借活动室或物品的详细信息、到期时间，同时也包含归还与评价
我管理的：类似于“我租借的”，包含所借物品的信息和被租用次数
信用度：此功能主要用于对用户的诚信程度进行量化评估
③思维导图-消息
为用户提供租用申请的消息、学校或学院的重要通知。
并且为每位用户提供不同的数据分析，让用户能充分了解自己的物品使用情况。
④思维导图-社区
“社区”功能是我们为用户提供的一个社交平台，
让用户在租借/使用物品的同时能参与到不同的社交活动，
同时也能让不同用户的各种闲置物品充分流通。
4.每位成员的贡献比，工作流程图
5.评审表格
6.UML
类图
1.描述的是app的功能方面内容
2.仍需改进：项目模块定义的不够清晰 各个类之间的联系较为繁琐
3.统一了参数，总体设计，提高前后端开发的效率
用例图
1.描述了借呗app的各部分功能以及对各部分内容的具体化。
2.如果按照用户习惯来进行排版，提高使用的友好性
3.让各个用户使用的功能更加直观，防止了用户权限混杂的问题
状态图
1.描述的是物品的各个状态
2.仍需改进：每个部分的具体转化还不够完全，需要细致优化。
3.直观的体现了物品的状态，让后面的设计思路更加清晰
活动图
1.描述了用户借入和租出的后续操作和结果。
2.仍需改进：更多的功能和操作难以在图中表示出来
3.直观的表示出物品租借的步骤
实体关系图
1主要描述的是系统的概念结构设计的部分。
2实体的决定、实体属性的决定、实体之间的关系（包括了一对一，一对多，多对一，多对多)
3各实体属性的决定和实体间的关系和关联
7.工具选择
亿图软件
8.对工具的评价
这个软件的可以作很多的图，而且将各种图分类，有很多东西可以直接用，不过由于没有下载破解版所以导出的图片不清晰且有水印，可以去百度使用破解版。
9.答辩总结
①本组的现场答辩得分
51.72分
②回答其他小组对本小组的提问
1.便利性还是挺不错的，希望重点考虑下安全性和互动性，可以往社交方面走一走（第二组）
安全性的问题我们考虑用设置押金来解决；借呗有设置“社区”这个功能，用以满足不同用户的社交需求。
2.各个部门管理的不止有活动室，还有一些属于他们的物资，比如体育部就有记分牌之类的，可以考虑让部门挂出空闲的物资来出借（第三组）
对于部门来说的闲置物资，可以让管理人员以部门的名义建立个人账号来进行出借。
3.未提问（第四组）
...
4.是否可以对不想要出借的部门进行奖励或者合作来增加自己APP的可借数量，不止活动室，很多部门有他们独有的物资。（第五组）
我们对于活动室的管理首先要跟学院那边商定好，对于愿意出借活动室的部门会以奖励部员信用度和可借数量增加的方式进行合作（信用度越高，可借物品数量越多）
5.你们如何做到获取各个部门活动室以及其他场地的租借权利？（第六组）
在借呗上线以前，会先与学院和相关老师进行沟通来进行活动室的协调
6.你们数据库究竟是mysql还是sql server（第七组）
mysql
7.如何确保借用出去的物品或者是活动室的完整度，以及软件是如何进行盈利的？（第八组）
用户在出借和归还的时候都需要对活动室或者物品上传照片来确保完整度；至于盈利问题，平台会在需要租金的物品的出借成功时，收取小部分佣金。
8.对于某些已经被主席团分配给学院各个部门的活动室，如何跟相关的部门负责人协调，以确保有多方同时使用同一个活动室而造成的不便？（第九组）
我们会协调各个部门，通过奖励的方式让部门出借活动室；同时在发布出借活动室消息的时候，租借者可以选择自己独用或者在“社区”中发布消息招揽大家共同使用。
9.与学院、老师的合作有具体可行的方案吗？（第十组）
在借呗上线以前，会先与学院和相关老师进行协商来进行活动室的协调，具体方案还正在考虑中。
10.活动室的管理是否要和学院先做好沟通（第十一组）
在借呗上线以前，会先与学院和相关老师进行沟通来进行活动室的协调
11.如何避免具有活动室钥匙的人出租活动室谋取私利？以及活动室原有物资的安全问题（第十二组）
对于出租活动室，平台是不设置租金选项的，即租借活动室只需要申请不需要租金；对于安全问题，则通过在租借和归还时上传照片来解决。
③标明修改完善之处
①调整了表格框线的问题
②修改了环境要求和软件接口
③删除了一些不必要的内容
10.《需求规格说明书》
《需求规格说明书》
（提取码：ny78）
11.遇到的困难和解决方法
困难描述： 没有android开发经验，得边学边写。因为没有实际项目经验，分工不是太明确
做过哪些尝试: 阅读开发文档和书籍；询问有经验的人
是否解决: 是
有何收获: 有了一定的android开发能力
困难描述：需求报告工作量大，需求复杂繁多，难以完成；需求报告排版格式要求细致繁复，修改复杂
做过哪些尝试：百度搜索相关博客和文档阅读了解
是否解决：是
有何收获：通过博客和文档的阅读，训练了阅读博客和文档的能力；学会合理分配文档工作，实现了最后版本的需求报告
12.PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时 (小时) |
实际耗时 (小时) |
|---|---|---|---|
| Planning | 计划 | 12 | 15 |
| · Estimate | · 估计这个任务需要多少时间 | 12 | 15 |
| Development | 开发 | 2 | 2 |
| · Analysis | · 需求分析 (包括学习新技术) | 5 | 5 |
| · Design | · 生成设计文档 | 5 | 5 |
| · Design Review | · 设计复审 | 0.2 | 0.3 |
| · Coding Standard | · 代码规范 (为目前的开发制定或选择合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 2 | 3 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试(自我测试，修改代码，提交修改) | 0 | 0 |
| Reporting | 报告 | 0 | 0 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0.1 | 0.1 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出改进计划 | 0.5 | 0.5 |
| · 合计 | 14.8 | 15.9 |
13.学习进度条
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时（小时） | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 12 | 12 | 基本了解了原型图的设计理念与实现方法，掌握了墨刀的基础用法 |
| 2 | 412 | 412 | 20 | 32 | 构思算法，实现基本框架 |
| 3 | 660 | 1072 | 36 | 68 | 算法改进 |
| 4 | 148 | 1220 | 15 | 83 | 了解接口的使用，学习了github使用规范 |
| 5 | 0 | 1220 | 15 | 98 | 明确了团队项目选题 |
| 6 | 0 | 1220 | 15 | 113 | 明确了团队项目需求 |