2018软工实践做业七之项目需求分析

小白吃们的需求分析

hjj的坐标

目录

• 项目总体计划安排
• 项目logo及思惟导图
• 一分钟宣传视频
• 团队做业贡献比
• 评审表格
• 答辩总结
• 需求报告改进
• 需求规格说明书
• 困难及解决
• PSP
• 学习进度条

---

团队项目总体计划安排

阶段	主要任务	计划时间	内容
1	项目选题	18.09.27—18.10.12	项目选择，经市场调研并与老师沟通后肯定选题
2	需求分析	18.10.13—18.11.04	完成需求规格说明书
3	设计分工	18.11.04—18.11.11	项目详细分工，代码规范，平台环境基本架构，界面初步美化设计，视觉识别算法完善
4	模块编程及对接	18.11.11—18.11.23	后端服务器搭建完成，界面交互彻底实现，各模块编码基本完成后，进行对接
5	测试	18.11.24—18.12.07	d对alpha版本进行应用测试，根据测试结果肯定beta版本优化内容
6	优化完善	18.12.07—18.12.21	根据上一阶段测试反馈内容，对项目进行进一步优化改善，造成正式版本
7	项目实施	18.12.21—19.01.08	争取在实际场景中可以试点实施，投入运营

---

项目logo及思惟导图

• 项目logo
  
• 思惟导图
  

---

一分钟宣传视频

演技max系列

---

团队做业贡献比

成员	分工	贡献比
葛亮	原型优化	14%
文斌	视频剪辑+评审表设计	14%
黄泽	报告整理、规范+视频演员	15%
静茹	视频idea+视频演员+答辩记录	14%
敬甲	logo+思惟导图+功能描述+博客整理	14%
泽明	功能验收标准	14%
刘浩	ppt制做演讲	15%

---

评审表格

想看戳我吧

---

答辩总结

• 答辩得分

组号	得分
1	79
2	73
3	76
4	72
5	66
6	78
7	75
8	80
9	77

最后得分：75.71分

• 问题收集与回答

第1组
一、在早上的答辩中，为了解决诚信问题所提出的解决方法须要付出额外的人力成本进行诚信核查，这是否会影响到项目初衷提升支付效率？

答：出现诚信问题，须要诚信核查的状况属于少数状况，不会影响总体的结算效率。

二、若是算法识别不出菜品，以后软件的处理逻辑是什么？

答：在服务器正常运行状况下，不会出现识别不出菜品的状况，若是出现极少数识别错误的状况，会在项目落地实施后，若出现极少数识别错误的状况，咱们会与商家协定相应处理措施。

三、识别算法所须要的数据集有一个收集的标准吗？

答：咱们的数据集的标准：要求能够拍摄餐盘内的全部菜品，而且同一个餐盘从菜品不一样分布拍摄，每种分布100张。

第2组
一、会不会出现使用产品时识别不出菜品的状况，到时候该如何解决呢？

答：在服务器正常运行状况下，不会出现识别不出菜品的状况，若是出现极少数识别错误的状况，会在项目落地实施后，若出现极少数识别错误的状况，咱们会与商家协定相应处理措施。

二、消费者的信用问题该如何获得更好的解决？

答：以项目投入使用前的宣传手段和信用支付监管手段共同完善对信用问题的解决。

三、会不会出现识别菜品出错，从而致使算错了价格，致使用户（包括学生和商家）的体验变差

答：算法的置信度现已达到95.4%以上，在投入使用前会达到99%以上，识别错误几率极低。在项目落地实施后，若出现极少数识别错误的状况，咱们会与商家协定相应处理措施。

第3组
一、大家提到的在线支付容许支付宝、微信、学生卡等多方支付平台，请问是否有考虑过可行性呢？由于我本身日常尚未碰见过在小程序里容许支付宝支付的情形。

答：由于平台和模式限制，咱们目前只提供微信支付的接口，基于微信支付的广泛性，能够知足绝大多数用户的需求。

二、产品的推出主要是为了方便学生群体，可是商家可能存在直营、外卖以及使用小二结帐等多平台致使目不暇接的状况，如何去处理使得商家更愿意使用大家的产品？

答：咱们的产品主要针对食堂的使用场景，知足商家的直营需求，而在学校的监管下经营外卖的食堂商家会愈来愈少直至没有，因此不会存在经营目不暇接的状况。

三、大家在数据分析中提到能够分析出卡路里、热量等等关乎健康的数据，但就我我的而言，这样的数据不太能获得个人认同，由于可信度不高，有什么更精准更有说服力的数据分析方式吗？

答：提供的健康数据分析，基于菜品中的食材种类给出相应的数据，但提供给用户具备必定的参考价值。除此外，咱们会基于用户的用餐量，提供“猜你喜欢”的推荐功能。

第4组
一、识别错误的后续处理是否能保证到用户体验呢？

答：识别错误势必致使用户体验不佳，因此咱们在尽量减小用户不良体验的状况下，会把更多精力放在提升识别准确率上。

二、识别错误率控制在1%如下是十分困难的一件事，若是是基于速度快的YOLO算法的目标检测来完成，是否在准确性方面达到的效果不会特别好呢？

答：是的，确实比较困难。目前咱们用YOLO检测了1W张图片，准确率在95.4%。而且还在优化中。在咱们优化模型以后，咱们有信心将准确率提升到99%。

三、产品的市场前景很是宏大，是否存在一个详细的规程来协助产品的迭代维护呢？

答：暂时没有，精力有限，能力有限，放眼当下。

第5组
一、大家是否有考虑到用户使用大家的产品会出现的逃费行为，就是买了产品不付钱，或者只拍部分的食品，这种行为大家有考虑到如何检测到或避免吗？

答：逃单行为咱们会采用摄像头人脸识别，匹配帐户的选餐记录和支付记录来作监管。对于只拍部分食品的行为，也在咱们的考虑范围内，但没有很好的解决方案，但这种状况属于极少数，损失可弥补。

二、大家PPT给出的自选窗口菜品识别错误率控制在1%一下，是否有些偏高呢，毕竟涉及到商家的利益，可否再下降错误率，否者商家如何会选择大家的产品呢

答：不会偏高，技术虽好也有瓶颈和天花板。识别错误率控制得极低，也有相应的反馈机制，在这两个前提下，即使有错误和损失，成本也极低，在给商家带来足够的利益的前提下，商家可以接受这样的额外成本。

三、大家的产品主要卖点就是不用排队，但大家是否有考虑到排队其实是能帮助食堂消化人流，若是每一个人都不排队的话，那么是会出现不少人找不到座位的，并且取餐人流和取完餐回座位的人流是否会产生冲突混乱呢

答： 排队消化人流是由于食堂自己硬件限制，才会有这样的畸形的好处。而排队结算点单是食堂用餐体验的硬核需求，咱们不会为了一粒芝麻丢掉一个西瓜。

第6组
一、你好，请问原型登录页面老师、学生登陆按钮不够清晰，原型不够美观，有考虑改进吗？

答：现有原型主要为了展示项目逻辑，美观度会在项目实施时改进。

二、你好，请问视频背景音乐太过嘈杂，是否考虑改进？

答：会在上传到b站时使用强降噪改进。

三、你好，请问是否考虑分析用户喜爱?

答：会根据用户的点单量，为用户提供“猜你喜欢”功能。

第7组
一、请问当大量用户没能及时取餐，而致使有大量的餐盘堆积在商家工做区，这样给工做人员带来了极大的不便，大家打算怎么解决？是否只能到商家附件才能够点餐，仍是能够预定点餐？

答：参考如今市场上已有的点单小程序，例如：“汉堡王”等，提供用户位置选择界面，让用户本身选择是否到达食堂，同时也有GPS系统的定位，确保用户到达食堂才可点单。

二、大家软件拍照识别支付的操做复杂度是否会大于直接扫窗口的支付宝二维码？若是这样对于效率的提高彷佛并非很大。

答：拍照支付的位置是在座位上，二维码是在窗口前，即使操做复杂度相同，也是更好的体验。

三、请问大家调查过商家愿意使用大家产品的比例吗？当商家使用的比率不高的时候，大家打算怎么说服商家？

答：没有调查过。宣传和合做方式有不少种，不是技术层面简单明了，涉及到人的意愿的问题，老是复杂的，也老是有解决办法的。

第9组

没有问题

---

需求报告修改

根据其余组的意见和建议，没有须要修改的地方。

---

需求规格说明书

此次戳我吧

---

困难及解决

• 困难描述

  一、规格说明书规范化

  二、logo以及短视频的idea

  三、验收标准的完善

  四、ppt演讲的练习

• 作过哪些尝试

  一、在网上查找比较好的一整套文档规范，并写入文档

  二、logo参考了ofo的配色，短视频引用了“真香系列”的思路

  三、验收标准参考了以前学长学姐们的格式，结合本身的实际来完成

  四、组内有提早作ppt演练

• 是否解决

  一、文档规范合格

  二、在老师的要求和条件限制下，作出的视频和logo都不错

  三、验收标准基本完善，后期会根据状况作小的调整

  四、ppt演讲流畅，但还存在过度依赖演讲稿的问题

• 有何收获

  一、学习到了比较好的文档规范

  二、视频和logo的制做，让咱们更贴近本身的项目

  三、有了一套基本完善的标准，也是为以后的完成定下了一个目标和方向

  四、关于ppt演示认识到了不少细节问题，再也不一 一详述，演讲展现仍需继续改进

---

PSP

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	45
•Estimate	•估计这个任务须要多少时间	390	545
Development	开发	0	0
•Analysis	•需求分析 (包括学习新技术)	60	60
•Design Spec	•生成设计文档	60	60
•Design Review	•设计复审	30	45
•Coding Standard	•代码规范(为目前的开发制定合适的规范)	30	60
•Design	•具体设计	60	90
•Coding	•具体编码	0	0
•Code Review	•代码复审	0	0
•Test	•测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	60	120
•Test Repor	•测试报告	0	0
•Size Measurement	•计算工做量	30	20
•Postmortem & Process Improvement Plan	•过后总结, 并提出过程改进计划	30	45
	合计	780	1090

---

学习进度条

第N周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
4	0	340	5	25	Leangoo工具的学习
5	300	640	15	40	哈希算法、优先队列、结构体等c++算法复习
8	0	640	10	50	代码方面暂无