五黑小队需求分析心得体会

一、需求分析的目的

        需求分析就是分析软件用户的需求是什么。我们进行需求分析，是为了满足用户的需求。在解决"做什么"的问题的基础上,全面理解用户的各项要求,并准确地表达所接受的用户需求。因为在现实生活中，客户的需求往往具有模糊性和隐蔽性、多样性、变化性的特点，所以这就需要我们抓住主要矛盾，合理取舍，才能获得最可行的方案。所以说，需求分析是一个必要的，现实的，目的性很强的工作。

      在本次的医生智能提醒小程序（以下简称小程序）开发中，为了让用户和软件开发者双方对该开发软件的初始规定有一个共同的理解，定义所要开发的小程序的开发目标，包括对功能的规定和性能的要求，指出预期的系统用户、系统的运行环境以及对用户操作的约定，使之成为整个项目中软件产品开发设计与实现的根据，以及软件产品的测试和验收的依据，我们小组每个成员都各司其职，全心全意地合作完成需求分析。

二、需求分析心得概述

       1、针对需求的模糊性和隐蔽性，我们采用了非正式会议和正式会议相结合的方式与老师进行了多次访谈，并且在小组内部开展了多次需求分析活动。我们以原型的方式和老师迅速确定了系统的基本需求。在快速分析的基础上，我们根据老师所说的基本需求，迅速实现了一个可行的系统，但忽略了最终某些细节上的要求。通过运行原型，我们发现了一些之前未考虑到的问题，针对这些问题，我们与老师进行了沟通协调。原型的设计帮助我们想像如何实现需求，并发现需求中的漏洞，使老师比较直观地判断出我们的需求是否可以完成必要的业务过程。

       2、针对需求的多样性，我们通过用例来解决这个问题，我们站在了每一类用户（医生、助理、患者）的角度上，分析系统应该为每一类用户做什么，并对每一类用例进行了汇总，得到了我们最后的用例文档。

       3、针对需求的变化性，我们进行了多次原型设计，对于每一次原型版本，我们都进行了至少一次会议审核，针对其中不必要的和未考虑到的需求进行更改和完善，并且对其进行了记录，作为原型以及最终实现的参考。

三、需求分析详情

       在本次需求获取与分析阶段中，我们小组每个成员均兼任需求分析员，负责需求的记录与验证。

       在需求分析过程中的前进与曲折令我们深刻地认识到，需求分析是一个动态的过程，而非一个静态的任务结点。比如最初我们设想可以让医生与患者进行沟通，提前了解病情。但是经过与老师沟通后，为了更贴近实际情况，我们决定增加一个助理端。因为医生在上班时间无法频繁查看手机，所以与患者沟通的环节很可能因此形同虚设。而助理的设置，可以让与患者沟通的对象不仅仅是医生，还可以是医生助理。再比如我们本来设置了网上商城的功能，医生可以通过这个小程序给患者在线开药，但是考虑到项目针对的是口腔诊所，核心需求是智能预约，结合实际情况，经过激烈的讨论后，我们最终决定去掉这一功能，需求分析也因此发生了较大的改动。

　　由于指导教师没有特别要求原型开发工具，因此我们使用墨刀进行原型设计，在做原型的时候本以为会很简单，结果做起来还是很麻烦，起初是因为团队间没有及时沟通，因此出现了很多链接上甚至是逻辑上的错误。原型1.0版本中设置了很多没有实质性作用的功能，比如购物车，商店等功能，后来经过和老师的沟通交流，删除了很多没有必要的功能，原型中的一些字段字体大小也不合适，影响了美观，在制作页面时，也是因为沟通问题，没有统一格式，因此做出来的原型差异较大，美观度大大降低。总的来说，这是一个团队项目，沟通很重要。困扰我们的不仅仅是沟通问题，还有细节性问题。界面设计不能仅仅是简单粗暴的信息铺陈，我们要考虑如何有逻辑，有关联性的把信息呈现给用户的同时，让小程序的使用尽可能的简单。所以我们在设计过程中，一直在不断的更改页面的排布和连接，力争让小程序变得符合实际。同时，我们也要注意小程序的细节处理，不仅仅是之前提到的字体大小，还包括排版和图标的放置等问题。

        其次，在设计界面的时候不能盲目开始，一定要首先明确我们需要什么功能，这些功能之间又应该通过什么样的方式连接，这样可以大大加快界面的设计速度。如果没有明确功能和需求,那么界面就可能会设计的不合理,功能之间又可能有重叠，并且，在设计的过程中，我们不能只顾着添加功能，我们还要考虑实现过程中的难度与实现方式。总之，界面的设计是一个非常重要且复杂的过程。

        在界面设计时很多细节方面组员之间有一些争议，比如注册和资格认证是否要分开，是否显示已就诊患者等细节问题。在讨论过程中，我们求同存异，相互了解，最终都达成了一致，确定了方案。原型设计，需求分析，是对整个项目的导向。这次项目经历，使我们清楚的认识到需求的重要和成员达成统一，决策者的决定性作用。总的来说，只有确定了需求，大家才有目标。才拥有共同奋斗的方向。

四、需求用例编写心得

       在开始编写时，我们首先参照往届学长学姐们所写的文档中的用例的格式进行了编写，犯了一些错误，比如只描述了用户即参与者的行为而忽略了系统的行为等，但在软件工程导论的课堂上，老师讲完了用例的基本概念与实例要点后，我们了解了编写用例的一些基本规范以及如何描述用例，并以此为依据，对之前完成的用例进行了更改：

1、通过自然语言描述参与者与系统进行交互时双方的行为，需要描述的内容包括：

       用例的目标、用例如何启动、参与者与用例之间的消息如何传送、用例结束后的系统方法等；

2、对于路径交互步骤的描述：

       只描述可观测的行为，并且使用以执行者或系统为主语的主动语句，每一句都要朝目标迈进，不能涉及实现细节；

3、可以进行一些扩展点的描述：

       比如执行者的选择、系统验证、步骤失败等，总而言之，需要考虑可选的动作序列以及会出现异常的动作序列。

 

                                   学长学姐的预约用例　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　我们组的预约用例

五、关于开发小组合作的心得

       开发小组内部时间和老师时间的协调也十分重要，因为我们是大三学生，不仅仅需要忙活于本次项目的需求分析，还需要应付各自繁杂的课程。由于小组成员各自选修的课程不同，因此每个人空余时间都不尽相同，并且老师也很难抽出太多时间参与我们的小组会议。因此，开发小组内部会议时间的协调以及开发小组与老师会议时间的协调十分重要。我们为了更好地安排会议时间，所以要求小组成员把各自课表发到小组群里，供PM参考。并且每周一都询问老师本周的空余时间，从而能更好地提前准备会议内容并与老师进行沟通交流。

       在讨论的过程中，我们都积极提出了各自的想法，但也不可避免地会产生一些意见上的分歧(包括与指导老师的)，我们通过不断的交流沟通去了解对方的想法，并给出自己的理由、以理服人，最后和谐地达成一致。