需求分析

软件公司对从事需求调研人员的基本素质是不太注意的，企业的信息化主管经常可以看到软件公司派住的调研人员的年龄是偏低的、经验是不够的。在我与企业中、高层管理者的交流中，他们普遍都有这样的感觉。

需求分析是跨越了软件工程的三个层次的。这一点是和其他的过程是一样的。当然我们这里比较重点强调的是在软件工程的方法层，同时也涉及到一些过程层的思想，至于工具层则不再我们的讨论之列，但是会提到一些很适合在需求分析时应用的工具，诸如Word、Excel、Visio等。方法需求分析都包括了哪些方法呢？这里列举出在《需求分析》一书中推荐的一些方法。

需求来自于用户，不论是用什么方法，首先应是找到我们需要访问的对象，然后对对象进行分类，再逐步对对象进行访问。具体访问过程中可以针对不同的访问对象采用不同的方法，根据访问的内容进行确定。本文要讨论的是，如何确定我们的访问对象，以及如何对确定用户对象进行调查。

需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。

做软件项目需求最重要就是分解用例场景，没有用例就不是需求。软件工程这类书要学，不过软件工程软件项目需求最关键就是用例场景的合理建立，这条，好象没有什么大学教科书谈到，仿佛中国的大学计算机科学系教师统统没有做过软件项目的，完全没有这个概念。所谓的软件项目需求，如果不是变成走不通的伪代码，就是用不上的美工方案，程序员对此除了干瞪眼是没辄的。

需求分析的目的在于理解提出要求的组织对于这次评估的商业需要，评估小组领导将收集信息来帮助评估发起方对照评估目标和他们的商业目标。通过需求分析，可使评估人员在对评估目标，约束，输出和范围形成共同理解的基础上对下一步评估作出正确的决定。

一款游戏项目的确立是建立在各种各样的需求上面的，这种需求往往来自于玩家的实际需求或者是出于公司自身发展和实力的情况，其中玩家的实际需求也就是说市场需求最为重要。面对对游戏拥有不同知识和理解层面的玩家，项目的负责人(或者游戏制作人)对玩家需求的理解程度，在很大程度上决定了此类游戏开发项目的成败。因此如何更好地的了解、分析、明确玩家需求，并且能够准确、清晰以文档的形式表达给参与项目开发的每个成员，保证开发过程按照满足玩家需求为目的正确项目开发方向进行，是每个游戏开发项目管理者需要面对的问题。

成功的销售不是如何去说服客户，而是对客户的需求作出最精确的定义，根据定义出来的需求然后再选择和解释产品。一般情况下，产品销售成功的几率取决于消费者的需求和产品的结合程度，所以我们的关键是把握消费者的真实需求，按照消费者的需求来对产品的款式、颜色、功能进行组合设计，提供给客户一件最适合的产品。但是，了解客户的需求是长期而深入的工作，然而对客户的需求可以由销售人员一步步挖掘并定义出来。那么如何进行客户需求定义呢？

需求分析阶段需要经历两个步骤：首先，提出问题的人说一些话，以告诉帮助他解决问题的人他要干什么，这就是“问题陈述”，即通过语言或者文字对某个关注点的细节进行表述。然后，解决问题的人和提出问题的人进行沟通，以确证这个问题的细节，这就是“探索需求”，这是一个反复沟通的过程。

需求是一个过程，一个在软件生命周期中很重要的过程。在需求要素之上的要素只有一个：沟通。沟通是什么，说小了是需求过程的重要技巧，说大了是软件企业的生命线。一个项目失败的原因有很多，而绝大多数都可以总结到沟通不畅。需求过程中充满了沟通：需求分析员和用户的沟通，不同的用户之间的沟通，需求分析员和需求审核人员的沟通，项目经理和需求分析员的沟通。沟通到一个什么程度，是需求成功与否的标志。

软件开发难，恐怕大家都觉得最难的是搞清楚需求；但是其实更难的是管理需求。今天在北京.NET俱乐部上又有人提出了这样的问题，主要的难点是他的开发团队是为了自己的领导们服务的，几个领导都有自己的想法，而且不停的在开发过程中提各种个样的问题；开发进度无法保证，开发的结果总是满足不了要求……

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段，针对三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。

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

本文阐述了需求评审和确认的一些”注意”事项，一旦完成需求评审将表示进入了需求设计阶段，欲知需求设计如何实现，且听下文为您分解。

在我们的软件行业中，绝大部分的软件开发人员都没有接受过高效需求工程所需技能的正规培训。但许多开发人员在职业生活中的某个阶段总会扮演一个需求分析员的角色，与客户一起工作：收集，分析，编写需求文档。不能过高期望开发人员在需求工程的信息沟通中的“天份”。一定的培训将有助于提高需求分析员的能力和水平。

怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（ Davis 1993；IEEE 1998）。让风险承担者从不同角度对SRS需求说明进行认真评审，能很好地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，就会写出更好的（尽管并不十分完美）需求文档，同时也会开发出更好的产品。

需求分析阶段是管理信息系统（MIS）开发最重要的阶段。MIS开发的需求阶段首先是了解和澄清用户的需求，然后严格地定义被开发的软件系统的需求规格说明书[1]。常用的软件需求分析方法有面向数据流的结构化分析方法、面向数据结构的Jackson方法、面向对象的方法和原型法等。原型法由于改变了系统的分析、设计和实现三个顺序阶段的观点[2]，改变了传统的自顶向下的开发模式，降低了软件需求的风险，因此得到了广泛的应用，特别是在致力于某一领域MIS开发的软件公司，如致力于电力MIS开发的公司。

有时，我们会因为读到一篇文章或一本书，或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下，人们只讨论一些技术、解决方案和选项的某些方面，而忽视了一个至关重要的问题：非功能性需求。

在本文中，笔者将网站项目管理（WPM）与软件工程的统一过程管理（RUP）进行参照比较，并结合实际工作经验，力求将网站工程管理（WPM）的角色、分工、流程进行完整的阐述，使网站项目管理逐渐走向规范化。

软件需求分为三大部分：功能需求、非功能需求、设计约束。