团队项目——需求分析心得——红鲤鱼与绿鲤鱼与驴

一.团队介绍

 

团队名称：红鲤鱼与绿鲤鱼与驴

项目名称：慢阻肺居家护理系统

成员介绍：张君逸（PM），陈骏科，郭晓哲，杨灿萍，张洋

指导老师：杨贯中老师

二.需求迭代过程

 

 

　　我们的项目一共经历了3次需求文档迭代，这3次分别是为了不同的目的。

　　1.0版本是基于上一届学长的慢阻肺家庭护理的需求文档进行的一个修缮后的版本，他们里面是对项目的一个基本的概括，但是其实是不符合新的需求的，因为我们的任务要求和他们已经不一样了，相较之前已经有了崭新的角色管理和功能；2.0版本是在第一次和老师以及助教开会头脑风暴之后得到的，这一个版本加入了诸如医生，家属等角色以及其他的功能；3.0版本其实是一个持续的迭代过程，我们将新版本的需求文档按照快速原型法得到了一个原型，然后用这个原型再次和老师展开会议，探讨项目的合理性，然后反复地按照老师提出的要求进行修改和迭代工作。

　　我们一开始写需求文档1.0的时候是套用了一个模板写的，这个需求文档1.0包括了我们绝大部分的功能需求，可以说是最贴近我们实际操作的版本，可是老师要求我们增加一些其他方面的需求，如医生这个角色，以及文章的点赞收藏评论功能。这是我们一开始没有考虑清楚的，所以我们在需求分析2.0加入了这些新的设计，再然后我们用2.0版本的需求文档制作了一个原型，并把它作为新的会议的主题和老师汇报，老师和助教利用这个原型更好地理解了我们对于需求的确认程度，然后提出了修改意见帮助我们把原本方向不太正确的需求理解修改好，这最终也促成了我们的3.0版本。在这个过程中，我们对迭代开发过程有了更好的理解，结合我们学习的螺旋模型，我们也明白了这个过程的重要意义。

　　随着需求文档一代一代的更新，我们的文档逐渐趋于完全。而在这个过程中，我们是一直参与着这一个迭代开发的过程，同时结合我们学习的螺旋模型，我们更加明白了这个过程的重要意义，这个过程对我们的益处的难以言尽的

三.迭代过程中的重难点

 

　　需求的收集是个很繁琐的过程，收集的不够，开发过程中变化会很多，特别是你上了一个演示版本后，开始别其他人一点意见都没，一看你的演示，就意见一大堆，所以在收集需求前要充分研读老师下发的项目PDF。同时我们要从两种角度去考虑需求，一种是用户角度，另一种是开发者角度；从用户角度分析用户需要什么功能，然后从开发者角度分析在软件设计和实现的机器层面怎么实现这些功能。

　　需求的模糊性：一开始我们认为需求文档2.0已经是充分理解了老师的要求的版本了，但是当我们制作了原型并展开会议之后，我们发现其实还有很多需求的理解并没有到位，这一点给我的体会就是，原型法是一个很好的确认双方理解的方法，非常有利于将概括程度很高的文字更好地理解。

制作的原型的重点界面展示：

     

　　需求的变化性：其实一开始并没有那么多的角色设计：医生，家属等等，也没有对文章的点赞评论收藏等诸多功能。但是在和老师的开会讨论之后，我们发现产生了新的需求和变化需求，所以我们添加了这些更多的角色，这里体现了用户反馈的作用，对于新的变化需求有比较高的反馈有助于最终产品的成功。

 

新增角色：医生的用例图

 

四.老师同学的互助过程

 

　　这是我们组的所有成员第一次参与项目设计，明白了需求文档的设计环节的重要性。通过这次需求分析，我们更加理解了需求在整个项目开发的过程中所起到怎样重要的意义。通过这次需求分析的过程，我们深刻明白了需求在整个项目过程中的重要意义，因为它是我们项目开展的基础。在这段时间里我们听老师讲课之余,也会在网络的各种社区阅读相关课程知识,将需求列出来之后询问老师是否合理.还有一个就是组内的同学互帮互阻,形成了良好的氛围。

　　同样也感谢仲勇杰助教和杨贯中老师在整个需求文档的获取过程中给我们的诸多帮助和解惑，还抽出时间配合我们展开了多次的会议，对我们的需求文档提出了诸多的意见和修改方向。

 

成员参与情况统计：

五.心得与体会

 

　　在真正进入需求分析之前，我们感觉这一过程并不容易。毕竟需求具有模糊性、隐蔽性以及多变性。

　　需求分析的整个过程需要团队所有人都参与进来，多次开会讨论、多次与项目老师、项目甲方进行沟通，才能得出最终的结果。项目需求是在不断变更的，因此每一次的讨论都是对上一次结果的重塑，且现在所完成的需求文档也可能并不是最终实现的项目的需求。因此要做好不断讨论、不断更改的准备。需求分析，是将整个项目“拆碎”、“嚼烂”，从甲方希望实现的项目功能出发，考虑操作性、工作量、技术性等因素，提出细致的需求，再从需求中提取出确定的需求用例。而提取出需求用例、完成需求文档、完成 UML 用例图，实际上又是对需求的再一次检验。在完成这些工作时，我们仍然会遇到许多不同的问题，它们关系着项目中不同角色的权限、功能、角色之间的关系等。因此，在整个过程中，团队的所有人都对项目进行了深度的剖析，对后续的实现有极大的意义。

　　学习软件工程这门课程已经有半个学期了。在我们看来，软件工程与其说是一门课程，不如说是一门思想，是一个如何去分析和处理问题的过程。应该说其范畴已经远远不止局限于该门课程，而是成为了一个综合的一个能够解决问题的思想集合。所谓的需求获取，那就是一个谈判，辩论，交流的过程，已经不是单纯的写写代码就能解决的问题了。这门课程教告诉了我们在完成一个实际项目时的一般程序及过程，这是一份非常具有实际意义的教学内容。当我们在毕业之后，这是我们实际要运用的一项非常有用的技能，而且不仅仅局限于软件工程的范畴，即使是从事与其它行业，也是要从需求获取开始。

　　但是其实真正开始之后，由于和四位相处融洽的成员一起讨论原型并进行分工设计，所以实际上虽然任务重，但过程却充满了轻松和欢乐的气氛。

　　这一点启示我，作为PM，应当在合适的时候调节团队内的气氛。当气氛融洽时，即使时间紧、任务重，团队成员也能享受在其中，同时，还保证了工作效率（人在轻松愉快的心境下，主观愿意完成该任务，工作效率会更高）。一个好的团队，必定是发挥了团队中每个人的优势，在开发团队中，不是你技术能力强，你就是最有价值的人，我相信在开发团队里没有一个从头到尾都能支持的能人，不是不没，是我是觉得不可能存在，也许我么说有些人不服，其实我这么说也有我的理由，一个人也许有机会经历团队中的每个环节，并且都能深入，但绝对不是一个机会，如果有，那就是一个人的开发，一个人的开发我想也不能叫团队，有时候，一个人什么都能做，多了一个人，什么都做不好，但面对大的项目，不得不进行团队合作。

　　我们需求的分析、原型的设计实际上经过了几次的迭代，其实每一次修改之后，我们都希望这就是最后一次的更改了。因为每一次的更改，都意味着要从头梳理一遍，以确定之前所完成的是完整的、无缺漏的，繁复的工作使得我们不希望多次修改。但我们明白这一过程是不可缺失的。只有项目开始的初始阶段，将需求分析完善、原型设计尽自己所能达到用户的需求，后续的开发过程才会顺利；而不是到了开发阶段，还要针对之前未完成的部分进行修改，从而耽误了整体的进度，也进行了更多、更无用的重复工作。

 

最终的3.0版本的需求文档目录展示：

 

总结一下我得到的思想上的方法论：

　　1.身为PM，应当对本组的工作进行规划，安排好每一步需要完成的工作，确保项目的进度；其次，作为项目的成员，在进行需求分析的时候，要充分了解到需求的模糊性和变化性，一定要尽可能的了解到用户的清晰需求；最后，一个团队内良好的气氛对于工作的完成起着不可或缺的作用，作为PM，我应当在整个过程中尽量营造和谐、轻松的气氛，使得在时间紧、任务重的时候，大家也可以高效率的完成工作。

　　2.不断进行需求验证，避免后期开发的不稳定性；

　　3.软件工程的创新工程，做中学目的是让我们将所学习的知识运用到实际项目中，不仅锻炼代码能力，更考验团队的交流配合，要求我们细化分工，不断了解业务流程，确认最终任务的执行，在项目开发中，互相讨论，确保统一的设计风格；

　　4.需求产生在不断的探究、交流与验证中，我们在开发的同时要兼顾需求的变化，同时从业务、用户、系统三个层次，兼顾功能性与非功能性需求，掌握需求，从而达到项目的成功！