【作业二】结对项目之需求分析与原型模型设计
031302517 031302319
一、一个老师的迫切需求——开课报课之繁琐
首先，先来看下客户的现实困扰：
开课计划书以群发邮件的形式发给所有老师。每个老师收到邮件后，在规定的截止时间之前，要将自己的名字填入自己希望报的课程的那一行 “任课教师”列，如果有起讫周序的要求，可以填入对应列中。如果对于安排等有其他要求可以填入“备注”等。如果没有特别要求，备注栏等就可以空着。然后填好后，老师以邮件形式发回给负责人。负责人查阅每封邮件，打开每个excel，查看每个老师的填报，最后手动汇总成一个excel。
困扰在于：群发邮件、群收邮件、催收邮件、汇总每个老师的excel，工作量巨大。
二、需求分析（NABCD模型）
好了，客户已经向我们阐述了他所要的需求，然而具体要如何去分析，去理解客户真正想要的是什么呢？我们小组两人抽空看了《构建之法》，就着里面介绍的NABCD模型来试着按部就班的分析下客户的需求，以尽可能的有条理的去说服客户。
1、N（Need 需求）
客户说，他的困扰在于群发邮件，催收邮件。我们先来看这两点，试着分析下客户想表达的是什么。首先，现在的邮件应用已经很完善了，不管是群发，群收，都能实现，那么客户为何还要提出这个困扰呢？我们结合客户的工作，给出了我们的理解：客户实际上困扰的不是有没有群发邮件这个功能，反而是选择群发对象的繁琐。比如，每次要群发的时候总要从众多好友列表中找出那么几个。虽然我们可以事先建个分组，把需要群发的对象拉入里面，可是不要忘了客户后面还有催收。催收对象是那些还没完成的，那么总不能再建个分组吧。所以，针对这点，我们要解决的就是实现事先把要群发的对象找出来，客户不管是群发还是催收只要点击就完事，不用再手工去查找群发对象，具体做法在A阶段分析。
我们再来看客户的其他困扰：群收邮件。这个词看着感觉很奇怪，有群收邮件这个概念么？什么叫群收邮件，难不成邮件还能强制要求一群人发过来让你接收？当然不可能，还是再次结合客户的工作，我们可以很容易的理解出，客户想表达的只是如何从收件箱中那么多的接收邮件中找出相关老师发过来的邮件。什么意思，这么说吧，客户发任务给各个老师，然后定一个期限前都要回复邮件对吧。那在这期间，难道就不会接收到其他无关的邮件么，比如你的博客被评论了，收到一份邮件，比如你的学生发了些问题来请教等等。这样一来，收件箱就变得乱了起来，所以我们要解决的就是如何屏蔽其他无关的邮件，只接收相关的邮件，怎么做还是留到下阶段A中分析。
最后，再来看看客户最后一个困扰：汇总每个EXCEL，工作量巨大。这点就很好理解了，没什么好分析的，就是客户手工汇总的话太麻烦，工作量大，所以要解决的就是自动把汇总工作完成，让客户可以直接看到汇总后的内容即可。同样，做法A阶段分析。
先贴张图，不然都是文字太乏味了：
此图为我们小组在讨论原型的设计以及APP的功能，但由于在上课时拍摄，还有老师在讲课，不敢大张旗鼓叫同学拍。
2、A（Approach，做法）
好了，下面就是分析具体如何做了。我们小组定位的是APP应用，所以结合N阶段总结的需求，我们组的APP要能实现以下几点功能：
1. 把要群发的对象分组，并能在该分组内实现区分有回复以及没回复的对象，并将他们分组。
2. 能将接收的邮件分组，将接收到指定对象的邮件都放到指定的地方。
3. 能自动汇总每个EXCEL中的内容。
在介绍上述功能如何实现前，先说明下我们小组采用的原型工具是MockingBot（墨刀）支持在线编辑，团队开发。说这个是因为接下去的分析过程中，我们将采用文字描述配合原型图片来讲解。
好了，下面就讲讲我们小组APP的思路。首先看下客户的工作，教务处提供开课表以及教师名单，客户根据教师名单群发邮件。所以，我们想法是实现类似QQ好友列表一样的功能，这点是为了能让客户选择要群发的对象。然后，也提供一个类似QQ讨论组的功能，客户可以发布一个任务，把要参与任务的教师都拉到一个任务里，在这个任务里，客户只需编写一次任务描述，所有在这个任务里的教师都能接受到消息。同时，我们提供任务列表已经文件列表，当客户创建一个任务时，会在文件列表中自动生成相应的文件组，这样，在这个任务里的教师回复的文件都会统一放到与任务相应的文件组里，排除了其他无关文件的干扰。并且，在这个任务里会区分出回复文件和没有的教师，并能实现对未完成的教师统一催收。下面贴几张原型模型设计图：
然后，在文件组里，我们提供了汇总的功能，客户只需选择还未汇总的文件，点击汇总，程序会自动把各个文件汇总到总文件中。客户随时可以查看当前汇总的情况，甚至也可以查看各个文件里的内容。另外，还有一点，EXCEL表格在手机上展示会出现很多问题，如何排版就很重要。我们想法是，摒弃EXCEL表格的形式，只解析里面的内容，然后提取出来按照我们的布局来显示。如下图：
最后是教师端的使用，我们只提供接收消息，编辑内容并发送的功能。当然，催收的实现，可以类似短信或ＱＱ一样有通知。贴几张图：
3、B（Benefit，好处）
好处很显然，能完成自动汇总，还能实现将群发的对象分组，随时随地都可以进行催收，只要有部手机即可。还有，我们将EXCEL表格在手机上的展示进行了自定义布局，改良了可观性，让客户在手机上也能随时舒服的看到EXCEL表格中的内容。
4、C（Competitors，竞争）
目前我们所了解的还未有实现此需求的软件，虽然这样一来看似市场潜力大，前途光明，但竞争仍然很激烈。每个学校肯定都会这种相同的困扰，至于其他学校有没有解决，如何解决，我们并不知道。但就这次来说，共有30多个小组在竞争，这些小组里不乏有大神，学霸之类的，也有创意点特别好的。所以竞争性还是特别强的。
5、D（Delivery，推广）
1.我们的平台一开始可以在福大普及，之间不断的完善。
2.之后可以向各大高校进发，率先占领新市场。
三、原型模型展示
本来写了个iframe嵌入网页提供直接原型模型交互的，可是好像博客不支持，反正显示不出来。没办法了，上面对原型模型的截图有限，只贴上了几张教重要的，要直接交互试试看效果的，可以：点击这里进行交互
四、可行性分析及预期规划
原型模型是做出来了没错，但具体能不能实现，我们小组却没有多大的把握。我们小组都是第一次接触Android，都是抱着对Android强大的兴趣才坚持下来的。我们在讨论的过程中，就产生了一些茫然，主要是不确定我们设计的APP应该基于哪种形式开发，下面就附上我的组员给我发的一段话：
第一种：文件（exl表格）主要以邮箱的形式收发，然后APP主要实现用以整合表格，还有一些文件的增删改查，催发邮件等。这样的话APP只需关联邮箱并且服务器只需存放负责人和教师的账号信息等简单的数据单位。但细细想想，这个APP的亮点也就是整合表格，也就是只需一个能整合一堆格式类似的exl的工具，其他似乎都显得多余了，完全可由exl编辑和邮箱代替（关联邮箱还需要负责人把邮箱里的附件一个个下载下来）。
第二种：搭建自己的服务器，文件以离线的形式发送，相当于我们本身就是一个邮箱软件。这样的话，就已经可以预料到往后服务器的搭建将是一个庞大的工程！如果APP实现了，负责人就无需去邮箱一一下载附件，发送任务计划和催发的话也只需选择教师列表里的人点击发送，相对轻松（事先导入教学任务exl文件和添加好教师列表里面的人） 接受时选好要接受的老师就可以下载所选老师发给负责人的exl文件到本地（无需通过邮箱），再次点击整合按钮，APP就可以在后台整合。我想老师更希望是我们做的这种方案来解决需求。但如此的话感觉，服务器是个重大难题，还有接口也不好实现。
并且，在最后我们小组讨论后发现要实现这个APP仍存在很多难点要解决，以下是我们所罗列的：
1. 教师列表能否实现？
2. EXCEL表格如何导入或导出，以及如何解析
3. 自动汇总逻辑如何实现
4. 如何与服务器交互以及与数据库交互
总之，难点还有很多，要学的也还有很多，至于对这个项目的预期规划，记得在《构建之法》中有个对预期实现的时间公式：
Y = X ± X ÷ N //注：Y是实际时间花费,X是对某件事的估计时间，N是做过类似开发工作的次数
如此来算的话，Ｎ＝０，X = 2人月，这样一来的话，有可能我们会在预期时间内完成。但，也有可能是无限长的时间。
最后，附上该博客的PDF：点击下载
