这几天，实验室新接到了一个项目，目前正处于需求分析阶段。已经和项目的甲方连着开了几次会，也基本上明确了甲方的基本需求，今天又让我们总结文档，但是却写得焦头烂额，发现需求这个问题是比较麻烦的，所以有一些思考，在这里记录一下。
首先申明，由于这两天实在是有太多事情了，所以没有时间去查询那些前辈们的成果，本文中描述的都是一些自以为是的观点和想法。
需求分析应该由谁来做
上周第一次和老师去甲方单位做需求分析的时候，甲方拿出了一个文档，上面写着他们单位每个人的分工，然后就看见了他们那边的人有产品总监、产品经理等等各种角色，也对，既然别人是甲方，那么获得一个头衔也是应该的。然后对方产品经理就拿出了一个文档，突然就发现对方已经做了很多了啊，有一些产品经理的感觉啊。然后第一天的工作，除了熟悉他们现有的系统的业务功能外，我们就在看他们的那份文档，文档中就列出很多的功能，比如说希望新的系统相对原有的系统的某个页面要怎么修改之类的。还真别说，有一些还真的写得挺清楚的。可是，这个会开了一天，我确越来越糊涂。后来回来的时候，我给老师说，我感觉需求分析应该是由我们来做，他们能做的就是让我们熟悉业务上的内容以及提出一些他们的要求。老师说，他们的需求分析已经做得挺好的了，他做了这么多项目，这个算是挺好的了。那么需求分析到底是应该由谁来做呢？
关于这个问题，我认为需求分析是一个比较专业的过程，因为需求分析的结果会直接作用到后面的阶段，可以说需求分析的好坏，会直接影响到后面的项目的推进，所以需求分析应该我们来做也就显而易见了。我自己将甲方给出的这一个报告看做是需求要点，就是他们期望的一些内容，具体一点说就是产品最终表现形态上的内容。但是要用这个文档来作为需求分析，那时万万不可行的。这样的文档往往具有下面的一些特点：
过多地关注界面层次的东西，比如说这里应该放个什么按钮，那里应该放个文本框。实际上这种东西应该交给UE、设计人员来做，而不是需求层次的功能。
功能逻辑划分不清，拿网页来说，很容易出现功能重叠的需求。
领域分析深度不够，很多时候都会出现我以为、我认为、我觉得之类的字样（虽然这篇文章中也有很多这些资阳，囧），这恰好是说明没有做好领域分析工作，更多的是个人的主观看法，这样的分析有多少可信度。
在现在的互联网环境中，其实这样的例子是非常多的，特别是现在，互联网的环境异常的浮躁，”人人都是产品经理”，这句话真的是一个讽刺，如果是一个产品经理提出这样的话，我真的想呵呵。我个人认为，产品经理绝对是一门有一定的专业性要求的工作。换成”人人都能怀着对美好事物的追求”我觉得还是可以的。
上面说了那么多，简单点说就是需求分析的工作还是应该交给专业人士来完成的。
那么作为甲方应该做什么呢？甲方应该是给做需求分析放提供详尽的关于业务方面的知道。这里的业务往细了说就是甲方卖出一个产品的具体过程是什么样的。写到这里，突然想起了本科时候一个老师说过的关于另外一个经常接校外项目的老师的话，”每接到一个新的项目，那么这个老师就能够在半年内成为这个领域的专家”。我觉得这说的就是这个老师对业务的摸索很厉害，真的很佩服这个老师。
换另外一个话题，如今的计算机行业中存在很多的外包公司，这些外包公司往往就是直接去实现用户要求的一些功能而已。我认为一个好的外包公司，也要能够做好需求分析的工作。
传统的需求分析
上面提到了需求分析由谁来做的问题，接下来就是需求分析要怎么做的问题。其实我脑子里也没有什么太清楚的概念。上学期上了高等软件工程的课，老师是这样要求我们做需求分析的。首先在需求分析以前，老师要求我们要做领域分析，领域分析就是和行业相关、和课题相关的一些内容。比如我们上学期的课程项目选了”多电梯调度系统”，在领域分析中就调研了电梯的各种参数的要求，电梯的调度过程等内容。然后根据领域分析报告来完成需求分析，在需求分析中，主要采用UML来建模（其实看看这个过程，也能够得到上面的那个问题的答案就是应该由专业的人来做），我们使用了UML中的用例图、状态图、类图等来完成需求分析，并且对于用例图，用RUCM进行了详细的规格说明，将每个用例的前置条件、后置条件、参与者、流程等等内容都详细地描述出来了。最后形成了需求分析文档。
受限于我现阶段的知识储备，可能真正的需求分析过程还没有完全地描述出来。但总的来看，传统的需求分析的过程实际上是非常麻烦的过程。但是对于传统的一些项目，比如嵌入式领域的一些项目，这个过程又是必不可少的。
敏捷情景下的需求分析
上面看到了一个我经历的教学性质的传统的需求分析过程。那么在现在的互联网环境中，需要怎样的需求分析呢？互联网公司中，考虑到产品上线的需求，所以很多时候采用敏捷开发的模式，这种模式追求快速地迭代，显然是没有更多的时间来做完整的需求分析的，所以我觉得需求分析过程会进行一定程度的简化，但是具体做需求分析的流程呢，等我回头研究一下再说。：p
文档的书写
好的文档能够很好地指导真个开发过程，但是坏的文档可能就是一个灾难了，不仅仅是浪费很多时间在写文档上面，更会将项目过程搅乱，所以总结一下写文档也是一门艺术。