软件需求在软件项目中扮演着及其重要的角色。不管哪种类型的项目，无论是新产品开发，还是外包项目，开发队伍都面临着普遍存在的需求问题，比如如何获取有效的需求、如何处理需求的变更等等。这些问题有其共性的一面，也有和项目类型相关的一面。本文着重讨论了在新产品开发项目中的一些需求问题，以及避免和解决这些问题的建议。

　　一.概述

　　在开始进一步讨论之前，我们先明确几个概念。

　　首先，本文是从开发团队，或者说项目组的角度来看需求问题。所谓开发团队，通常包括了程序员、测试员和其他一些项目成员，如配置管理员和软件架构师，以及基层的管理人员，比如项目经理。类比于传统企业，开发团队相当于企业的生产车间。但是，在大多数的软件组织中，开发团队除了担当“生产”任务以外，往往也是需求获取的主体；在某些较为正规的组织中，也许会有市场部门给出一些需求，但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的。

　　其次，何谓“新产品开发项目”。简单而言，在本文中，新产品开发指开发团队需要从无到有将一个想法（idea）转化为产品（product）。新产品开发不同于产品升级，开发团队没有一个已存在的基础；新产品开发不同于开发一个实验型的作品或者演示、原型之类的东西，开发团队终的产出必须是产品，在功能、性能、可用性等方面都有比较高的要求和期望；新产品开发不同于承接一个软件开发项目，也不同于为明确指定的用户或者客户定制产品，开发团队终面对的是广泛的市场，是一个由众多独立的终用户（同时也是客户）组成的群体。新产品开发项目更加不同于维护型的，或者其他类型的项目。

　　第三，本文所讨论的需求基于需求的传统定义，即软件需求指用户对软件产品明确的和期望的要求。这些要求直接影响了用户对此产品的满意程度，或者更直接的说，影响了用户的购买决定以及对产品和开发商喜好的判断。对于开发团队而言，在实际工作中，需求问题往往和设计问题，特别是高层（Highlevel）的设计纠缠在一起，很难有明确的界限划分。但在本文中，需求问题不涉及与具体实现相关的问题，比如技术选型，人机界面。

　　概括而言，在一个新产品开发项目中，开发团队面临的需求问题涉及到需求的获取、分析和管理。本文的余下部分将重点讨论新产品开发项目中典型的四大问题，分别是：有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。

　　二.有限的需求来源

　　新产品的想法可能来自老板的拍脑袋，也可能来自市场部的报告，或者也可能来自研究部门的某个创意；但不管怎样，可以肯定的是，没有人具备足够的信息来准确的描绘出未来的产品（而且通常这个未来也不会很远）是什么样子。如果项目组成员恰好属于这个产品的用户，比如这个产品是一个字处理软件，或者仅仅是搭上一点关系，比如这个产品是一个个人理财软件，那获取需求的任务更加理所当然的落在了开发团队身上。

　　表面上看，由开发团队自己定义需求会使得需求相对稳定，对开发团队是有利的。但事实上，开发团队会面临不少棘手的问题，直接明显的，是需求的来源受限。开发团队需要的是明确的（好也是稳定的）需求，而现在，要开发团队自己去获得，而且获取需求的来源又很有限。

　　由于是新产品，在组织内部，开发团队通常找不到足够的帮助。而要从外界获得，又受到时间、经费和职责等因素的限制。在这种情况下，学习竞争对手的产品是一个很有效的方法。开发团队可以从研究和剖析类似产品着手，例如，如果要开发一个电子邮件客户端软件，那么，Outlook和Foxmail是很好的学习对象。亲身的去使用和体验这些软件，仔细阅读它们的用户手册、在线帮助，甚至联系它们的客户服务。而且，这项工作应该让整个团队一起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。

　　面对有限的需求来源，引入用户是另一个解决方法。所谓用户，他们可能很熟悉同类产品的使用，或者了解用户通常需要些什么。比如开发个人理财软件，那么一个理财顾问，或者一个理财高手是很合适的用户。对于面向群体用户的产品，特别是那些大众消费类软件，这些用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响，应该尽可能多引入几个用户。对于某些产品，比如前面提到的电子邮件客户端软件，似乎团队成员中可以找到用户。但在团队内部发展用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。