团队项目-需求分析报告
一、整体计划
- 编写需求说明书。
- 确定各功能模块分工。
- UI设计完成，基础功能算法完成，制定测试计划。
- 完成Alpha版本，编码+测试+项目管理同步推进。
- 完善项目，确定用户试用反馈和对测试计划改进。
- 完成Beta版本，以反馈为基础进行改良。
- 版本完善，编写用户手册。
- 正式版本发布，并进行维护和支持。
二、团队分工
| 组员 | 分工 |
|---|---|
| 林涛（组长） | 规划项目进程、分配任务、审查文档、写博客 |
| 童圣滔 | 项目概述 |
| 林红莲 | ppt制作 |
| 潘雨佳 | ppt制作 |
| 于瀚翔 | 演讲、展示 |
| 袁正闻 | 提出相关假设 |
| 吕瑞峰 | 非功能规格设计 |
| 蒋梦迪 | 项目logo设计 |
| 王德钊 | UML图制作 |
| 吴友昆 | 功能规格设计 |
| 覃鸿浩 | 设计评审表、评分 |
三、思维导图
四、团队贡献比例
| 组员 | 贡献比例 |
|---|---|
| 林涛（组长） | 12% |
| 童圣滔 | 8% |
| 林红莲 | 9% |
| 潘雨佳 | 9% |
| 于瀚翔 | 10% |
| 袁正闻 | 6% |
| 吕瑞峰 | 6% |
| 蒋梦迪 | 10% |
| 王德钊 | 10% |
| 吴友昆 | 10% |
| 覃鸿浩 | 10% |
五、评审表设计
六、UML
七、工具选择
- Visual Studio
- Git
- My sql
- PS
八、工具评价
- 一些网页就可制作思维导图，无需下载，十分方便。
- 有些软件无破解版，全英文使学习难度稍微提高。
九、答辩总结
1.现场答辩得分：
- 53.75
2.提问回答
-
Q：人工审核卖家商品上架请求是否太过繁琐、工作量过大？
-
A：我们会尽量加入类似关键字屏蔽的功能，含不和谐商品会自动无法上架，减少人员工作量。
-
Q：若遇到卖家反复修改后多次提交审核请求该怎么办？
-
A：我们有一个审核时间，在该时间内修改商品信息可以任意次数，审核人员以最新版本为准。
-
Q：人工审核多个内容基本相似的上架请求是否考虑过会出现处理效率大幅降低的问题？
-
A：不会。
3.修改之处
- 加快原型制作；
- 加入手持学生证拍照认证；
- 添加一个买家短时间可取消订单以免买家手滑误操作；
十、需求规格说明书
十一、困难及解决方案
1.困难描述
- 任务分配太晚，时间不够；
- 不了解需求分析报告；
2.尝试
- 将分工更细化；
- 加强沟通；
- 很好地利用网络；
3.是否解决
- 是。
4.收获
- 增强了团队的凝聚力；
- 了解了需求分析报告的规范；
- 懂得思维导图等的制作；
十二、PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 40 | 60 |
| Estimate | 估计这个任务需要多少时间 | 30 | 20 |
| Development | 开发 | 0 | 0 |
| Analysis | 需求分析 (包括学习新技术) | 100 | 100 |
| Design Spec | 生成设计文档 | 120 | 120 |
| Design Review | 设计复审 | 60 | 60 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 30 | 20 |
| Design | 具体设计 | 30 | 30 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 60 | 60 |
| Test Repor | 测试报告 | 30 | 20 |
| Size Measurement | 计算工作量 | 20 | 10 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 550 | 530 |
十三、学习进度
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 200 | 200 | 13 | 13 | 学会了EDraw Mind Map等制图软件的使用、懂得了需求分析报告的规范 |
