从需求分析看软件开发的挑战

前序

　　在这里我真的要感慨一下了，时间确实过的太快了，一个小小的需求分析阶段竟然耗尽了课程的将近一半的时间，之前从来没想过需求分析多么多么重要（可能是之前的项目需求过于明确或者考虑的过于简化），但是这次项目真的就不一样了。我们的项目名称叫程序知识提取，程序的知识？是不是觉得很抽象？到底什么是知识呢，这个题目本就比较抽象，此外还要在这个抽象题目下去建模。那么问题来了，建模一词在我看来是一个更加抽象的概念，两次抽象的结果让我感觉到，我是谁？我在哪里？我在做什么？好了，不能再扯了，再扯真就把自己给吓住了，接下来看一下我们小组在需求阶段的遭遇。

项目需求过程

　　如果从我的角度来感受需求的整个过程，那就是不断地探索一个问题知识到底是什么。首先在一开始的领域分析中，我们详细分析了现有的技术栈，如java语言的特性与风格、git的相关技术、java代码的现有度量方式等。可能是因为题目太过于抽象，我们并没有很好的把知识的定义给出来，而是把更多的目光放在了技术栈本身。但是，现在想想这样做的结果只会是让知识的定义更加模糊，以至于开始回避知识到底是什么这个问题。果然，在后来老师给出的共性问题中，确实指出了我们的关键问题所在。我们在对问题的技术背景充分调研的同时，却把项目最核心的问题给遗漏了。

　　在需求初期，我们开始逐渐意识到需求中知识的定义是不可回避的问题，我们开始尝试去定义一些知识。最初，我们将这个项目定位成了给学生和老师提供代码指标分析服务的课程系统，因此在这一阶段，我们将知识初步抽取为java结构性度量（有一些专有的度量指标）、git托管的代码变更分析、对学生代码的测试、命名分析、结构分析和关联分析等。我们认为这些就是我们的知识，我们根据这些需求进行了详细建模。但后来经过课上展示后，还是被老师提出了非常多的问题，如知识过于笼统、系统过于庞大、对于知识的理解还是不够精确，缺乏对知识之间联系的理解。一句话，我们还是没能够准确的回答我们项目的核心问题——知识到底是什么。

　　终于，是时候认真解决这个问题了（因为快要需求评审了）。我们课后再次对知识进行了细化，并且对原来定位的系统进行了适当的精简，我们开始通过场景再现的方式来定位我们的需求，然后从需求中分析知识的定义。最终，将冗余的部分删除后，我们精炼出四大模块，而且对每一模块都做了详细分析，在每一模块中分别提取关于程序的知识，才算是将知识的准确定义给出来，虽然在后来的需求评审中可能还存在一些小的缺陷，但是总体上我们定义出了系统的知识，给出来了系统的需求模型，我想这一步对于后来的工作是非常关键的。

思考

　　从本次项目的需求分析来看，我收获最多的就是对软件工程的需求分析有了新的认识，其实需求分析在软件开发过程中是非常重要的，而之前对这一点认识还不够。IT界一直有这样的比喻，软件开发过程就像是在盖楼房，需求分析是在给楼房打地基，一旦地基没有打稳当，那么整个楼房也就脆弱不堪，现在的我也非常赞同这种观点。另一方面，需求工程其实已经成为了一个软件分支领域，这也更加充分体现了需求分析对于软件开发整个过程的重要性。结合我们项目来讲，在我们对于系统需求比较模糊的初期，后面的工作真的就是无法开展的，更别说要对系统进行建模了。此外，既然需求工程已经成为一个独立分支，这也就说明了需求分析并不是一件容易的事情，它是有研究价值的。综上所述，对于软件工程面临的所有挑战中，需求分析必定占有一定的份额。