结对项目第一次作业——部门与学生的双向选择需求分析

N：

学生方面：需要了解各个部门的常规活动时间与面试时间，从琳琅满目的部门中选择时间安排合适的不多于五个部门。

部门方面：对部门来说，面对一波一波的小鲜肉，不仅需要筛选出符合部门需要的人员，还要确保新生在面试之前就先确保自身时间不会冲突，且不会报名过多的部门。

A：

我们的做法参考了福州大学的选课系统，具体做法如下：

① 一个同时可以选择进入“学生”或“部门”模块的Home界面，根据所选择的角色不同进行登录

② 学生登录后首先来到他们已选择的部门页面，在该页面同时可以进入补填他们信息的页面以及选择部门的页面，部门选择页面通过表格的方式呈现每一个已经填写好部门信息并开始纳新的部门，这些信息包括上面所说的“常规活动时间”“以及“面试时间”两个重要信息，因为这两个信息应该是部门在纳新开始前就已经申报确定的，所以可以在此时直接填写在部门信息中。新生通过页面中部门的简介选择自己喜欢的部门（多选，至多选择五个），按下“投递简历”按钮即可将已经填写好的简历发送到部门端，同时回到已选择的部门界面，在这个界面此时还可以进行撤回简历的操作，但若部门已同意面试，则不可撤回。

③ 部门登录后来的已投递给该部门的学生列表的界面，在这个界面部门负责人可以多选学生，进行同意面试操作以及拒绝简历操作，另外在这个界面还要通往填写部门信息页面的按钮。

④ 具体的内容将在下面的原型模型中展示。

B：

① 界面友好，操作简单，所有的界面都十分简洁，没有难懂的操作。

② 对学生而言，在选择部门界面将一次性展示所有所需要知道的必要信息，不必多花费时间二次了解。

③ 对部门而言，同样可以在选择学生界面一次性得到关于学生的具体信息，且由于软件硬性设置，不必担心学生选择过多部门。

④ 对学生与部门而言，所有的操作批量进行，一次性即可完成双向选择操作，效率十分高。

C：

竞争必然存在，但我们的产品直接针对用户需求，做到一刀去病，没有任何副作用，也就是没有任何使得软件变得更加复杂的不必要功能，我觉得这是我们的特色，可以让我们在后续的维护中针对双方信息交换这一个点做到最好，而不需要去考虑很多繁杂的其他模块。而假如在后续如果客户有其他更新的需求，比如要加入部门持续对学生进行管理的模块，我们可以直接另外再建立一个新的模块来完成需求，最终将二者整合成一个软件，由一个接口选择通往两个不同的模块，所以客户也不必担心我们产品的拓展问题。

D：

推广计划希望在我们的产品基本完善以后，由校方官方的队伍，或者联合部门校部门进行试用推广，只有通过更高层更大的力量才能真正将我们这样一款实用的软件有效率的铺满为数众多的新手群体。

叶文滔：

首先这次结对项目确实对我而言是比较新颖的体验，因为我接触代码、软件设计等计算机方面的专业只是都是在进入计算机专业以后，一直以来都是一个人完成作业之类的编码任务，也有少数几次与多个同学合作完成一个项目，但这是第一次与仅仅一名同学来合作。这个过程中我们需要单独来沟通各自的思路，所以初次交谈的时候还是有些紧张，会有些不知从何说起的尴尬，但是很快我们就适应了这个项目，讨论过程中也开始熟悉起来，在此之前我和杜宏庆同学是完全不认识的，所以我觉得不仅是收获到了如何进行原型设计（尽管不得不承认我们做的模型还是比较丑的），还提前学到了更重要的工作交际的能力，确实感觉很棒。

而关于本次项目，我觉得首先是学到了设计软件的一种新思路，即构建之法上的NABCD模型，确实让我对如何系统的去构造软件有了一个比较清晰的思路，第二点是新软件的学习，其实在之前我完全不知道原型模型是什么玩意，而且很奇妙的是百度上也没有关于原型模型比较简单具体的解释，基本都是原型模型有什么作用之类的，所以弄懂这个东西还花费了我一天的时间，才知道大概就是做一个预览界面，也通过这次学习了一些Axure RP这个此前从未接触过的软件，所以阅历上的收获还是很大的。

杜宏庆：

队友比较有经验，给我推荐Axure这款原型工具，我用了之后感觉挺好上手，不懂的地方还可以问他。结对相比于个人，可以取长补短，互相督促，大大提高了效率，我觉得这就是两人合作所带来的优势。

关于本次项目，目的是实现学生和部门之间双向选择的一个原型系统，让学生和部门之间可以双向选择。设计好界面后，把学生信息和部门信息收集起来，进行统一的管理，大大方便了部门和学生的选择。另外，我发现需求分析是一个项目不可或缺的一部分，起到至关重要的作用，只有把需求分析做好，才能顺利开展后面的工作。《构建之法》第8章中的NABCD模型可以很好地完成需求分析。