需求分析

现在的很多公司，做起项目来，需求变化速度之快，实在是让人防不胜防。而且基本上对SRS的修改，都是先斩后奏。开发人员一般都是直接和客户交流，直接改代码。更过分的是，他们改完之后，从来就不会第一时间通知需求组，通知测试组。感觉就像整个项目组都应该围着他转一样。

需求链的概念指的是需求能够上传下达，从客户传达到需求过程，并从需求过程传达到需求过程的下游开发链。而这个传达是可以逆向的。

测试人员的首要职责是找bug，但是最重要、最根本的职责应该是在软件产品发布前确保公司的软件产品满足顾客的需求。

软件工程初期的一般过程是，软件开发的计划，确定要实现的目标和进度等，然后就是需求规格说明书，该说明书要得到用户的认可。用户往往提供了一份要求的说明，开发人员在这个基础上进行了加工和整理。此后的开发过程，都是围绕着需求规格说明书进行进一步地细化，直至开发出产品。当然，测试计划中也要针对需求进行验证，看看是否满足了用户的要求。

项目需求分析是一个项目的开端，也是项目建设的基石。在以往建设失败的项目中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。

这篇文章描述了高质量需求叙述和说明的几个特性(特点)。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

最近倍感轻松,因为负责的项目已经正式上线了.回顾这1年半的时间,真是酸甜苦辣,五味俱全.先来说下我们的项目,费用大概加起来接近300万,项目分为3个Phase,历时15个月终于正式结束了.所以在此回顾一下项目,并总结一下其中的经验和教训.欢迎各位拍砖.

在整个软件工程的过程中，并不全是康庄大道，也非充满崎岖，那么是什么让软件工程如此难以控制呢?那是因为软件工程中有两大鸿沟将整个软件工程过程划分为三个部分，并且目前这两大鸿沟上面似乎没有一座象样的桥梁。需求和设计之间存在着一大鸿沟，而另一条存在于设计与编码之间。本文将探讨这两条鸿沟产生的原因以及如何跨越的方法。

产品部和技术部，在网站的开发过程中，是两个需要密切配合的部门，很多网站甚至将这两个部门合并在了一起，不过大部分还是分开的。在互联网开发过程中，这两个部门的沟通效率，对于最终网站的质量有着非常重要的意义。笔者尝试将工作中这方面的一些体会分享出来，供读者参考或者指正。

在很多人的印象中，敏捷软件开发是种类似黑客行为的过程，是程序员最爱的勾当。不写文档，不作需求分析，没有项目经理，做什么东西完全是程序员自己的行为。所以他们认为这样的过程无法满足真正大型项目和复杂项目的需要，因此在经过考虑后，放弃了敏捷方法。

在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一个关键过程。 在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。

软件需求工程过程

需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键。总体上说，我们的需求分析是做了，但是做得很不够，我们做的需求只解决了我们能做出这样的项目，但是没有解决这样的项目是不是真就是客户想要的。

软件项目的需求分析一般要分信息管理系统、网站频道，这两个不同方向的需求分析的获取需求的途径是截然不同。

对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。

目前简化原型法已经在多个电力MIS工程中应用，大大提高了需求分析的工作效率。实践证明，简化原型法具有以下特点：1）简化的系统原型开发工作量大大降低，修改和补充方便；2）简化原型大大缩短了需求分析人员与业务主管之间的距离，便于交流；并大大加强了需求分析人员与业务主管对系统的认识，有利于发现和解决问题；3）简化原型的设计提前考虑了系统的设计与实现，大大降低了软件工程的风险；4）简化原型增加了系统操作员对实际系统的认识，大大简化了工程实施后系统的操作培训；5）简化原型可以直接指导工程的设计和编码，便于系统开发的组织。这种方法也可以用于其它软件工程，对于其它需求分析方法的改革也具有指导意义。

了解客户的需求是长期而深入的工作，然而对客户的需求可以由销售人员一步步挖掘并定义出来。那么如何进行客户需求定义呢?

如果把项目范围比作一个橄榄球，那么球内的充气量便是项目的实际工作需求。尽管五磅的气体和二十磅的气体充起橄榄球的外形是一样的，但不同的充气量会影响着橄榄球本身的弹性，从而影响整个赛事的结果。项目管理同样是这个道理。不同的工作需求同样会影响项目的结果。如果仅仅建立项目范围而没有建立范围内的工作需求，同样会影响项目所需的资源、时间、功能、质量，更直接影响服务的价格，从而导致项目的全面失败。

目前，我国各行业亟需各种应用软件系统，但传统的SE开发模式显然不能充分满足用户的需求。进入90年代以来，一种新的被称为“用户主导，面向领域的需求分析方法”被提了出来，即如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工程成为研究的热点之一。

需求分析是导致软件产品好坏的关键工作，导致软件开发难易程度大小的绝对因数。宁可将需求分析的时间给充足一些，也不愿以后在编程阶段补充修改需求（虽然修改需求是不可避免的事实）。