需求分析
软件的最终目的是用来解决用户的某些问题，需求分析就是要理解要解决的问题，真正明确用户需求。
1、 访问软件项目的真实用户（至少10个），确保软件真正体现用户的需求，为软件最终可用奠定基础。
我们是写的新项目，采用的用户调研方式是调查问卷
调查问卷的git地址（https://gitee.com/kezhiqing/soft_team_blog/attach_files）
（1）调研目的
为什么要进行这次调研？可以是为了确认产品功能是否好用，可以是了解用户喜好，可以是为了推广新产品。
以这次调研为例，目的是通过用户调研，理性了解用户，根据他们的目的、行为和态度差异，将他们区分不
同类型，然后从每种类型中抽取出典型特征，赋予人群画像，最终挖掘出不同人群对产品的偏好和潜在需求，
以及对品牌的认知程度，从而更好地进行产品设计及推广。
(2)目标人群
因为我们的打卡小程序有自创话题的优势，可以了解了各个年龄段的潜在需求，所以调查的年龄跨度相对比较大
(3)调研内容
就是要调研哪些层面的内容，用什么形式进行调研。例如这次我们重点是针对用户小程序及其app关于打卡小程序的使用情况和使用态度设计调查问卷，并进行全站发放。研究发现大家更愿意使用小程序来进行打卡，原因是小程序更加方便，而且用完即走，无需下载。所以挺有市场的
(4)、调研方法
第一步：划分用户范围
比如本次调研目标需要区分核心用户、普通用户，那么定义核心用户为在XXXX年XX月，在打卡小程序发布过20个以上的话题并参与打卡活动完成，其他人则为普通用户。
第二步：收集样本数据
我们是利用网络资源，在线上群发，请求线上各个年龄段的人帮助我们如实填写调查问卷
第三步：聚类分析
我们调查发现大部分人坚持做一件有意义的最长时间集中在半年之内，其没有坚持下去的原因大部分是因为没有自制力，而大部分人觉得打卡能督促自己做一件事情或者养成习惯。所以微信打卡小程序的用户大都是没有自制力但是想坚持做一件有意义事的人和有自制力仍然愿意参加打卡的人，其潜在用户是没有自制力需要劝说进行打卡的人。而我们小打卡程序就是希望通过打卡来督促大部分人坚持一件事
（4）数据来源说明
这次调查问卷投放五天的时间，主要通过在朋友圈和空间进行了投放，聚集团队里六个人的朋友圈和空间，数据可信，实际回收了100多份问卷，有效问卷99。
（5）发现产品应该具备的功能
（6）总结
1、学生群体应该是潜在目标用户，因为学生时代比较喜欢参与各种事物，并且可以参与的话题也比较多？
2、学生群体的特点是：学历较高、习惯用使用微信并且可以说已经离不开微信。针对这一特点，我们是否可以考虑写个公众号啥的，在学生群体加粉丝，然后进行推送
3、很多人相信打卡能够督促自己坚持一件事情或者养成好习惯，可以发展潜在客户，让更多客户知道这个应用
4、有些人参与了打卡但是并没有坚持，我们可以挖掘一些吸引人的功能，比如把奖励机制做好，让用户愿意坚持打卡并且从中发现乐趣。当然还有自创话题界面美观等等
2、参考《软件需求规格说明书》国标规范文本，撰写对应项目的软件需求规格说明书。提供《需求规格说明书》的Git链接。
除形式上满足规范文本要求外，整体内容必须围绕项目实质展开，对所要开发的项目确保尽力做到清晰完整准确。使用一致的图形符号和文字描述内容。
我们的《需求规格说明书》的Git链接：
（ https://gitee.com/kezhiqing/soft_team_blog/attach_files）
3、NABCD 写作，视频
NABCD模型：
1) N (Need 需求)
大家经常会有这样的行为：常常对自己说明天早起，却还是经常睡过头；给自己定了个小目标，每天要记60个单词，却总是三天打鱼两天晒网。当然，你可以让同学或舍友提醒你。但是，时间一长，这显然是行不通的。也有用户会去下载相应的APP来监督自己,但是往往只用一小段时间，用完还要卸载，太不方便了。这时候，如果能有一个小程序，能监督自己去完成所定的目标，那用户的痛苦就解决了。
2) A (Approach 做法)
开发一个微信打卡小程序，用户在该小程序中可以先新建活动（用户给自己定的任务），然后设置活动内容，活动时间等，待用户完成该任务后，可以进入该打卡小程序通过发表打卡日记来完成打卡。
3) B (Benefit 好处)
谈谈我们团队设计开发此打卡小程序的初衷在于，对自我行为的约束，良好习惯的养成，予以目标实现更大的可能性，这是较为宽泛的好处。
娓娓道来:
A.我们的产品在形式上可以给客户带来新鲜感，一方面由于以微信小程序通道的模式，减免了重新下载软件的繁重感（毕竟现在还是有一大批小可爱的手机内存是16g的），另一方面以电子互联网模式代替纸质计划的制定，避免了记录的丢失和消息的闭塞，是极好的。
B.在体验感上，我们的产品主要针对青少年学生（学业重）和上班族（压力大），自然，界面要走小清新路线，一目了然，操作简单上手容易，我们的原型设计框架结构清晰，相信我们最终交付的作品也不会有太大的偏差，满足预期效果并且更好地去完善。
C.与此同时，我们的首页发现模块借鉴微博的类似功能，在此平台建立打卡，分享打卡日志，互相监督遇见与自己志同道合的一批人，与之结为好友，这是一个相对来说不可控却又令人惊喜与期待的好处。
D.当然，现在市面上已经有诸如此类小程序的成功案例，比如，“小打卡”的功能就相对强大，而我们要做的，很明显是竞争用户群啊，先从身边舍友好友同学推广，扩至校园，再运营至更大的用户空间和类型。从学生大众角度出发，设计出一个界面美观，功能完善的打卡程序。
E.至于在基本功能实现的基础上，作为我们的杀手功能的“我的奖励”模块，也属于画龙点睛之作，后续将会详细提及，在此就不一一赘述。
F.据说Benefit还可以指对自己团队的好处，团队每个人都很不错，至少就目前进度而言，我们处于需求分析框架设计阶段，每个人都积极提出自己的想法与见解，指出团队设计上存在的缺点和不可行之处。术业有专攻，每个人都有擅长的模块，就我而言（无名氏），视觉感受比较敏锐，审美较强，细心，瞎写点东西的能力也还是过得去，自然，我选择了前端开发，顺便做个可爱的美工小姐姐，完全ojbk的hhh。
4) C (Competitors 竞争)
竞争的话，上述也有提到，市面上已存在此类打卡小程序，对比各小程序，较为成功的就属“小打卡”了，而APP有待开发。基于团队经验值为零和前端基础薄弱的情况，我们就先尽全力去实现微信小程序。我们的产品的优势就在于提供奖励机制，增加小程序的趣味性，可以吸引更多的顾客。
**5) D (Delivery 交付) **
最终成果交付，这个问题简单回答，我们给自己的小程序设定的预期用户数为30人，这个相对来说还是可行的（论亲友团的重要性）。在微信朋友圈、qq空间、微博等发布相关动态，借用现有通讯介质，（各种美图？）渲染宣传效果。我们还可以在集大通朋友圈po出我们的作品，介绍基本功能和特色功能，实现校园用户的普及，那么打卡的实际操作力将
大大提高。打个比方：创建一个夜跑活动，在首页推送，同集大的学生加入后，相互了解认识（确保可靠性），一起去万人夜跑啊，减肥健身得终身践行，可不就是开启一段从虚拟世界走向现实的革命友谊。
将NABCD组织成一段话：
各位用户小伙伴你们好，我们的产品“滴卡录”，首先我们的名字就很可爱了，它是为了解决青少年学生自制力的匮乏、上班族工作压力大的痛苦而量身打造，他们需要制定目标、约束行为、养成良好习惯、与此同时享受生活 。但是现有的方案并没有很好地解决这些需求，我们有独特的办法 ，就是开发一个微信打卡小程序，操作简单上手容易。它能给用户带来的好处数不胜数，例如，界面新鲜感和使用体验感良好，分享打卡结识好友，奖励制度是我们的杀手功能，远远超过目前市场上的竞争对手微信“小打卡”、“易打卡”、“计划控”团队。同时，我们有高效率的成果交付方法，比如现在这种面基的形式就很不错，能很快地让大部分用户知道我们的产品，并进一步传播。
杀手功能：
用户一旦新建完一个活动，即可获得一棵树的种子。根据用户新建活动中的活动时间，用户所能选择的树的品种也不一样。用户每完成一次打卡，即可获得相应的能量（总的能量/天数）。若在活动期间存在未打卡情况，那么这棵树就立马枯萎。只有打卡全部完成，才能获得这棵树作为奖励。
附加题：
视频链接：（https://m.weibo.cn/5702894875/4227758076947602 ）
4、团队协作，加强分工，需要描述每个成员的具体分工及占整个文档任务的工作量比例。
5、原型设计
原型设计能够在表现层将设计合成一个逻辑整体，用户能和你一起看到未来交互的软件蓝图、功能和效果，获得较真实的感受，在不断讨论的基础上完善未来的设计思想。因此，原型设计能起到有效沟通的作用，漂亮，直观的原型图更是让人赏心悦目。不要等到所有代码写好之后再去验证需求，请用设计工具描述用户界面和需求。原型设计不仅要考虑主要功能的页面排布，同时也要考虑用户实际操作中的问题，提前为用户考虑得当并征求用户意见系统是必须可运行的，可实际使用的——请抱着这样的同理心去考虑系统。
给目标用户展现原型，与目标用户进一步沟通理解需求。
原型设计工具：墨刀
原型设计结果链接：滴卡录
（1）“滴卡录”小程序入口界面
（2）首页界面
（3）进入Keep健身计划活动界面
（4）点击立即加入活动，选择是否打卡界面
（5）点击“+”后进入的界面
（6）新建活动界面
（7）活动选择界面
（8）编辑打卡日记界面
（9）进入“我的”界面
（10）我参与的活动界面
（11）可查看该活动详情及参与者的动态界面
（12）我的打卡记录界面
6、任务分解WBS
一个团队项目要在一段时间内完成诸多任务，满足用户需求，实现团队目标，从哪里入手？
WBS（Work Breakdown Structure）即工作分解结构，是根据项目目标把工作分解成许多层次分明的、可交付成果的工作任务，然后用逻辑图形或树形结构表示出来。
请给出团队项目的WBS；团队成员估计各自任务所需时间
一个团队项目要在一段时间内完成诸多任务，满足用户需求，实现团队目标，从哪里入手？
WBS（Work Breakdown Structure）即工作分解结构，是根据项目目标把工作分解成许多层次分明的、可交付成果的工作任务，然后用逻辑图形或树形结构表示出来。
6.1.请给出团队项目的WBS；
- 前端：郭炜埕 廖怡洁 包梦榕
- 后端：郑晓丽 柯智青 黄晓杨
6.2.团队成员估计各自任务所需时间
| 成员 | 任务 | 所需时间 |
|---|---|---|
| 郭炜埕 | “首页”前端 | 3天 |
| 廖怡洁 | “我的”前端 | 4天 |
| 包梦榕 | “新建”前端和“我的”前端 | 4天 |
| 郑晓丽 | “首页”后端 | 5天 |
| 黄晓杨 | “我的”后端 | 7天 |
| 柯智青 | “新建”后端和“我的”后端 | 7天 |
7、编码规范
8、系统设计
在设计阶段，我们要清楚：软件是怎么解决这些需求的？一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计完成团队项目的数据库设计，并在随笔中提供相应ER图
滴卡录架构设计
ER图
9、个人感想
- 郭炜埕：在本周团队合作中，我主要负责的是用户调研和软件需求规格说明书的攥写。关于用户调研，我们应用了问卷星进行线上的问卷调查，通过分享朋友圈、转发到群的方式，在短短两天内，有99人填写了问卷。这个数量我个人是满意的，也在此感谢每一位参与调研的朋友！再者，关于软件需求规格说明书，我们参考了老师给的模板，自己也上网查找了许多资料。从一开始无从下手，到后来理清头绪完成说明书的攥写，还蛮有成就感的。我们已将部分文档上传至项目Git，也期待下一次的合作。
- 郑晓丽：这次博客量比较多，所以我们分工完成，可以说特别和谐了，而且效率也不错。组长分配有方，组员积极完成。然后我负责的是用户调研和需求规格说明书完善及博客整合。感觉问卷是用户调研不错的方式，毕竟在网上，所以可以很快找到用户帮忙填写。在博客整合的过程中，发现组里的其他成员都很厉害，用心得完成了自己的任务，而且完成得很好，察觉到自己平时不够细心的缺点。这样团队合作的方式，可以让你发现别人的优点认识自己的不足的，取长补短。
- 廖怡洁：当我在做WBS的时候，先了解了一下如何做任务分解，通过查书、百度种种方法全面获悉应该如何着手，然后我发现用通俗的话来解释其实就是分工明细每个人的任务，之后我们经过商量讨论，就画出了分工的逻辑图，并且也商讨了编码规范，按照书上的编码规范，一项一项罗列出来，给出了一个个明确的标准，以后我们就按着这个标准写代码。看着我们一步步为这个小程序开始做各种准备，很有凝聚力的感觉。
- 包梦榕：本周博客我们团队进行了各自的分工合作，我和我的舍友负责需求分析中的NABCD分析和原型设计。感觉这两个任务相对来说，NABCD设计还是比较简单的，只要把各点理清楚写起来得心应手，最后的视频录制比较尬就是了；原型设计也是特别有趣的，以前嗯没有接触过使用墨刀进行界面设计，第一次和舍友一起共同设计。两个人对着一台电脑互相讨论（后来做完了才知道是可以两台电脑共享，浪费了些时间），（在此之前我们团队讨论了很久的原型设计，可以说是很用心了），将各自的设计想法po出，一旦有错误的如图标链接另一个人及时纠正指出，或者有更好的比如图标选择，这也很考验我们的审美力哈哈，这个过程给我的感觉有点像我之前做过的微信文编辑，充分地体验了合作的乐趣。不断地进行修改查看的循环操作，乐此不疲，没错啊，这个过程我们委实是对精致的猪猪女孩了d(`･∀･)b。
- 柯智青：在这次团队合作中，我参与了原型设计和需求分析中的NABCD分析，体会到项目不是随随便便就开始做的。项目前期要进行需求分析，原型设计，系统设计等一系列工作。完成这些任务后，对我们所要进行的小程序开发有了更进一步的认识。在小组讨论进行任务分配及原型设计过程中算是比较顺利的，大家的积极性比较高，希望下周进行冲刺的时候继续保持这种状态。
- 黄晓杨：这次博客我主要负责系统设计这一部分，这又分架构设计和数据库设计。我对于架构设计的概念比较模糊，所以在百度过后，根据自己的理解大致写了一下关于小程序整体的实现方式，具体的语言之类的还没有确定。然后就是数据库，在仔细分析讨论过后才得出了这样的一个设计，但后续的开发中，可能还会有一些细小的改动和完善。