软件需求在软件项目中扮演着及其重要的角色。不管哪种类型的项目，无论是新产品开发，还是外包项目，开发队伍都面临着普遍存在的需求问题，比如如何获取有效的需求、如何处理需求的变更等等。这些问题有其共性的一面，也有和项目类型相关的一面。本文着重讨论了在新产品开发项目中的一些需求问题，以及避免和解决这些问题的建议。
一。 概述在开始进一步讨论之前，我们先明确几个概念。
首先，本文是从开发团队，或者说项目组的角度来看需求问题。所谓开发团队，通常包括了程序员、测试员和其他一些项目成员，如配置管理员和软件架构师，以及基层的管理人员，比如项目经理。类比于传统企业，开发团队相当于企业的生产车间。但是，在大多数的软件组织中，开发团队除了担当“生产”任务以外，往往也是需求获取的主体；在某些较为正规的组织中，也许会有市场部门给出一些需求，但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的。
其次，何谓“新产品开发项目”。简单而言，在本文中，新产品开发指开发团队需要从无到有将一个想法（idea）转化为产品（product）。新产品开发不同于产品升级，开发团队没有一个已存在的基础；新产品开发不同于开发一个实验型的作品或者演示、原型之类的东西，开发团队最终的产出必须是产品，在功能、性能、可用性等方面都有比较高的要求和期望；新产品开发不同于承接一个软件开发项目，也不同于为明确指定的用户或者客户定制产品，开发团队最终面对的是广泛的市场，是一个由众多独立的最终用户（同时也是客户）组成的群体。新产品开发项目更加不同于维护型的，或者其他类型的项目。
第三，本文所讨论的需求基于需求的传统定义，即软件需求指用户对软件产品明确的和期望的要求。这些要求直接影响了用户对此产品的满意程度，或者更直接的说，影响了用户的购买决定以及对产品和开发商喜好的判断。对于开发团队而言，在实际工作中，需求问题往往和设计问题，特别是高层（High level）的设计纠缠在一起，很难有明确的界限划分。但在本文中，需求问题不涉及与具体实现相关的问题，比如技术选型，人机界面。
概括而言，在一个新产品开发项目中，开发团队面临的需求问题涉及到需求的获取、分析和管理。本文的余下部分将重点讨论新产品开发项目中典型的四大问题，分别是：有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。
二。 有限的需求来源新产品的想法可能来自老板的拍脑袋，也可能来自市场部的报告，或者也可能来自研究部门的某个创意；但不管怎样，可以肯定的是，没有人具备足够的信息来准确的描绘出未来的产品（而且通常这个未来也不会很远）是什么样子。如果项目组成员恰好属于这个产品的用户，比如这个产品是一个字处理软件，或者仅仅是搭上一点关系，比如这个产品是一个个人理财软件，那获取需求的任务就更加理所当然的落在了开发团队身上。
表面上看，由开发团队自己定义需求会使得需求相对稳定，对开发团队是有利的。但事实上，开发团队会面临不少棘手的问题，最直接最明显的，就是需求的来源受限。开发团队最需要的就是明确的（最好也是稳定的）需求，而现在，要开发团队自己去获得，而且获取需求的来源又很有限。
由于是新产品，在组织内部，开发团队通常找不到足够的帮助。而要从外界获得，又受到时间、经费和职责等因素的限制。在这种情况下，学习竞争对手的产品是一个很有效的方法。开发团队可以从研究和剖析类似产品着手，例如，如果要开发一个电子邮件客户端软件，那么，Outlook和Foxmail就是很好的学习对象。亲身的去使用和体验这些软件，仔细阅读它们的用户手册、在线帮助，甚至联系它们的客户服务。而且，这项工作应该让整个团队一起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。
面对有限的需求来源，引入资深用户是另一个解决方法。所谓资深用户，他们可能很熟悉同类产品的使用，或者了解用户通常需要些什么。比如开发个人理财软件，那么一个理财顾问，或者一个理财高手就是很合适的资深用户。对于面向群体用户的产品，特别是那些大众消费类软件，这些资深用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响，应该尽可能多引入几个资深用户。对于某些产品，比如前面提到的电子邮件客户端软件，似乎团队成员中就可以找到资深用户。但在团队内部发展资深用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。
三。 模糊的需求界定在一个新产品开发项目中，某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述，这些界定问题由于没有一个确定的用户或者客户说“要还是不要，好还是不好，急还是不急”而会变得模糊不清。
这种模糊的需求界定也发生在开发团队内部。每一个成员都可以声称“用户要这个功能”，或者“用户根本不可能那样操作”。需求的界定常常成为“公说公有理，婆说婆有理”的争论。
在现实世界里，开发团队往往处于一个尴尬的境地。他们通常被认为有义务制定出需求规格，并对此负责，却没有被赋予对需求规格最后“拍板”的权力。在这种情况下，开发团队以及开发团队的领导要明确自身的立场，并将相关的责权利落实到纸面上。
[1] [2] 下一页
 【责编:runlz】 |
