高等软工--需求分析阶段的总结与体悟

需求分析感悟与体会

  不知不觉，高等软件工程课程已经过半，我们各个小组也完成了各自项目的需求分析报告。不得不说，这次的需求分析与本科阶段的软件工程的需求分析有很大差别。

领域分析

  此次需求分析报告之前多了一个环节，称之为领域分析报告。其作用是通过查阅资料，加深对自己所做项目专业领域定位的理解。例如我们小组的项目名称为轨道信号灯控制系统，我们就需要调查轨道信号灯的运行方式，铁路的相关规定与相关的系统等等。只有充分调研了相关的技术背景以及专业领域的知识，在接下来的需求分析阶段才不会跑偏，老师如是说。
  个人角度来看，这是我第一次接触到领域分析，一开始确实不清楚领域分析的作用，而且也不知道该如何入手。因此只能按照要求，去尽可能的查阅各种相关资料，规定专业术语。实话说，在真正开始需求分析建模之前，对于领域分析的重要性一无所知，就单纯当作一次资料收集的任务。真正认识到领域分析报告作用是在我们小组开始讨论系统的边界，以及系统的建模开始。
  首先需要清楚我们系统要面向的任务以及与其相关的外部系统。在领域分析中，我们列出了当前铁路运行使用的列控系统的原理，经过理解，我们小组一致认为我们信号灯控制系统的任务应当是通过控制信号灯的显示来保证列车安全又高效的行驶。同时，列车的调度是由列控系统来完成的，我们的系统属于列控系统的下层系统。同时，针对系统故障，无法完全依靠系统内部自己去完成故障的排除，因此需要系统之外的故障处理人员。以上，即是我们小组针对领域分析，对我们系统的核心业务以及边界的阐述。

需求分析

  需求分析第一个要搞清楚的是需求分析的目的，以及需求分析的最终结果产物。只有目标明确了，前行的路才不会迷茫。那么，需求分析的目的是什么呢？我认为需求分析是一次对整个项目宏观的把控，首先需求分析要搞清楚项目的核心业务以及系统的边界所在。核心业务不难理解，但系统边界的确定真的是一件说起来容易，做起来困难的事情。我们小组的第一次用例图，就是在系统边界完全混乱的情况下凑出来的，我们都意识到当时那个用例图问题很多，但我们无法确定出其具体原因。于是，我们在课上第一次报告时，得到了老师的反馈。我们的用例图未能准确的体现系统与外部Actor的交互准确性，太过含糊其词，边界把握不够准确。可以说，一针见血的指出我们当时的问题，也给出了我们建议，从领域分析中准确的把握住系统的核心业务以及系统的边界所在。
  于是，我们小组开始了第二轮的需求建模，这次过程中，我们一直坚持准确定义系统的边界，究竟哪些功能是我们系统之外的事情，又有哪些功能是我们系统内部的事务。这时就不得不庆幸我们是一个团队，多个人的头脑风暴有时候真的能够取长补短，我们经过数个小时的讨论之后，终于得到了一些我们能够共同认可的系统方案。即，我们的系统将只专注于利用信号灯来保证列车能够安全的行驶，而关于列车的调度以及列车的具体驾驶，我们一致认为不属于我们系统的业务。个人认为，至此才是我们此次建模工作的一大突破。于是，这时我们再画起我们的用例图时，就毫无阻碍，并且能够准确的给出每个用例的定义与意义。
  然而，用例图的完成，不过只是第一步而已，第二个难关在于类图的抽象。我们第一次报告的类图可以说十分粗糙，现在看来当时的类图完全不得要领，就是肆意妄为的写出来，从未考虑过什么系统功能体现与连贯性。之后，我们小组选择利用课上讲到的场景分析的方法提取我们的类。首先，对我们系统的业务划分了三个场景，列车出站，列车从区间A驶入区间B，列车进站。这是按照列车的一次完整运行时间线，进行的分析，可以保证至少我们最终的类图能够体现出这三个核心场景，其余的就是关于细枝末节的细节添加。总的来说，我们小组对类图的成果还是比较认同与满意的，直到需求答辩的结束。只能感叹，站的高度还不够，所以问题看待的还是不够全面，我们虽然将列车的行为分为了三个场景进行分析，但这样的划分导致的结果就是我们对系统业务体现过于孤立，缺乏了连续性，类图中无法体现我们系统的完整运行过程。这可能是接下来我们需要解决的问题。
  需求建模，我们小组共同攻克的难关即为以上两个，因为我们觉得用例图与类图是对系统的整体把握，如果在这两个建模过程中我们小组成员无法达到一致时，那么我们在后续的工作中，就有可能在某个关键结点上产生分歧，那将是一件不可调和的灾难。后续的，用例规约以及活动图和时序图，这些琐碎的描述，我们的做法是将任务分配下去，然后大家在约定时间内完成之后，再集中进行一次评审，类似code review？这种合作方式保证了我们小组成员对系统的基础认知是统一的，同时也能够及时发现某些分歧点，及早消除隐患。

个人体会

  这次需求分析大大颠覆了我之前的浅显认知。第一点了解了对系统核心业务的确定过程，之前编写过的软件真的只能算是计算机大作业，软件功能可能就是一个人琢磨一小会儿，估计就能总结的七七八八了，那时候的需求分析真的是犹如画蛇添足。但此次软工的题目，则完全超出了这个范畴，不太可能坐那瞎想就总结完了。于是，为了能够把握系统的核心业务，首先需要领域分析，掌握领域专业知识；之后要确定好系统的边界，这是就需要不断的根据之前的领域专业知识去反复核对，当这步完成之后，系统的核心业务才刚刚出现一个雏形；最后是需要设定应用场景，然后对这些场景进行分析抽象，并不断与之前的结果相互映照。只有这些过程的结果，能够顺畅的串行下来，总结出对应的用例图和类图等，那么才能说，核心业务可能找到了。
  第二点就是认识到团队的重要性，一直以来，我们上学经历过的考核一直都倾向于个人完成，而对与人合作这方面很难有机会经历，即时合作完成课程大作业，也极容易出现一人带飞，其余人抱大腿的现象。但软件工程任务的琐碎与难度，几乎不可能一个人完成，至少我不能。所以，团队的有效配合将是本课程的另一个收获吧。实话说，我们小组一开始的分工完全不考虑任务之间的联系，就是将总任务人为切割之后，各自为战，这就导致我们的成果会有矛盾之处，很难统一起来。而如果我们完全一起做，那将极大降低效率，相当于五台电脑，同时干一件事。我们也是经过不断的讨论与磨合，才最终确定了将任务分为两类，一类是所有人必须达成一致的核心任务，另一类则是核心之外的任务。核心任务时，我们会集中讨论，各抒己见，将意见统一。非核心任务，就平均分配给每个人，之后再集体进行评审，这样大大提高我们的效率同时，也能保证我们对系统的认知始终保持一致，能及时解决分歧与矛盾。
  最后要说的是对后续课程的一个期冀。目前来看，我们小组对系统的整体的把握还算过关，但是具体细节方面似乎还是欠缺了一些什么。究竟欠缺了什么，我们还处于探讨中，而且系统在我脑海里还是有一些模糊不清的东西，希望后续我们能够准确的找出我们的问题，并且真正梳理通透系统的关键业务。