一. 概述
在开始进一步讨论之前，我们先明确几个概念。
首先，本文是从开发团队，或者说项目组的角度来看需求问题。所谓开发团队，通常包括了程序员、测试员和其他一些项目成员，如配置管理员和软件架构师，以及基层的管理人员，比如项目经理。类比于传统企业，开发团队相当于企业的生产车间。但是，在大多数的软件组织中，开发团队除了担当“生产”任务以外，往往也是需求获取的主体；在某些较为正规的组织中，也许会有市场部门给出一些需求，但这些市场数据和有限的调研结果通常是远远不够形成需求规格书的。
其次，何谓“新产品开发项目”。简单而言，在本文中，新产品开发指开发团队需要从无到有将一个想法（idea）转化为产品（product）。新产品开发不同于产品升级，开发团队没有一个已存在的基础；新产品开发不同于开发一个实验型的作品或者演示、原型之类的东西，开发团队最终的产出必须是产品，在功能、性能、可用性等方面都有比较高的要求和期望；新产品开发不同于承接一个软件开发项目，也不同于为明确指定的用户或者客户定制产品，开发团队最终面对的是广泛的市场，是一个由众多独立的最终用户（同时也是客户）组成的群体。新产品开发项目更加不同于维护型的，或者其他类型的项目。
第三，本文所讨论的需求基于需求的传统定义，即软件需求指用户对软件产品明确的和期望的要求。这些要求直接影响了用户对此产品的满意程度，或者更直接的说，影响了用户的购买决定以及对产品和开发商喜好的判断。对于开发团队而言，在实际工作中，需求问题往往和设计问题，特别是高层（High level）的设计纠缠在一起，很难有明确的界限划分。但在本文中，需求问题不涉及与具体实现相关的问题，比如技术选型，人机界面。
概括而言，在一个新产品开发项目中，开发团队面临的需求问题涉及到需求的获取、分析和管理。本文的余下部分将重点讨论新产品开发项目中典型的四大问题，分别是：有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱。
二. 有限的需求来源
新产品的想法可能来自老板的拍脑袋，也可能来自市场部的报告，或者也可能来自研究部门的某个创意；但不管怎样，可以肯定的是，没有人具备足够的信息来准确的描绘出未来的产品（而且通常这个未来也不会很远）是什么样子。如果项目组成员恰好属于这个产品的用户，比如这个产品是一个字处理软件，或者仅仅是搭上一点关系，比如这个产品是一个个人理财软件，那获取需求的任务就更加理所当然的落在了开发团队身上。
表面上看，由开发团队自己定义需求会使得需求相对稳定，对开发团队是有利的。但事实上，开发团队会面临不少棘手的问题，最直接最明显的，就是需求的来源受限。开发团队最需要的就是明确的（最好也是稳定的）需求，而现在，要开发团队自己去获得，而且获取需求的来源又很有限。
由于是新产品，在组织内部，开发团队通常找不到足够的帮助。而要从外界获得，又受到时间、经费和职责等因素的限制。在这种情况下，学习竞争对手的产品是一个很有效的方法。开发团队可以从研究和剖析类似产品着手，例如，如果要开发一个电子邮件客户端软件，那么，Outlook和Foxmail就是很好的学习对象。亲身的去使用和体验这些软件，仔细阅读它们的用户手册、在线帮助，甚至联系它们的客户服务。而且，这项工作应该让整个团队一起参与，增强每个团队成员对产品的理解和感性认识，当然，参与的程度和时机可以有所不同。
面对有限的需求来源，引入资深用户是另一个解决方法。所谓资深用户，他们可能很熟悉同类产品的使用，或者了解用户通常需要些什么。比如开发个人理财软件，那么一个理财顾问，或者一个理财高手就是很合适的资深用户。对于面向群体用户的产品，特别是那些大众消费类软件，这些资深用户事实上并不如想象中那么难获得。个人关系是主要的获取途径。为了减少个人偏好的影响，应该尽可能多引入几个资深用户。对于某些产品，比如前面提到的电子邮件客户端软件，似乎团队成员中就可以找到资深用户。但在团队内部发展资深用户并不值得鼓励。其中的原因在“CPD陷阱”一节中会解释。
三. 模糊的需求界定
在一个新产品开发项目中，某项需求是否需要、它的优先级如何、某项功能或者要求究竟如何表述，这些界定问题由于没有一个确定的用户或者客户说“要还是不要，好还是不好，急还是不急”而会变得模糊不清。
这种模糊的需求界定也发生在开发团队内部。每一个成员都可以声称“用户要这个功能”，或者“用户根本不可能那样操作”。需求的界定常常成为“公说公有理，婆说婆有理”的争论。
在现实世界里，开发团队往往处于一个尴尬的境地。他们通常被认为有义务制定出需求规格，并对此负责，却没有被赋予对需求规格最后“拍板”的权力。在这种情况下，开发团队以及开发团队的领导要明确自身的立场，并将相关的责权利落实到纸面上。
在技术层面上，解决“模糊的需求界定”问题的一个方法就是采用原型。利用原型来讨论，利用原型来证明观点，这比“空对空”的争论要有效得多。拓展出去讲，在界定需求的时候，尽量用事实和数据来支持观点，避免“可能怎样怎样”的猜想，如果不能肯定，就落实到概率上，这样可以通过风险分析的技术手段来帮助决策。
四. CPD陷阱
CPD是PMT的一个词汇，意即“无谓的创造－追求完美－自我否定”。团队成员过多涉足需求的开发（即使可能存在进度上的压力，项目的初始阶段也几乎总是一段美好的时光。进入一个新鲜而陌生的领域，团队的每个人都容易发现一片崭新的世界，每个人都能够为新产品添加一系列“激动人心”的特性。但这些特性是否合适、是否有必要却往往被“激动”淹没了。追求完美是计算机技术人员一个很普遍的特征，这一特征会促使这些无谓的创造继续下去，直到大家觉得“这个产品做得再好也不过如此”，于是，自我否定就会接踵而来。
为了防止陷入CPD陷阱，开发团队只需要个别人参与新产品的需求开发，而其他人则可以以已开发的需求作为进一步讨论的基础。这或许限制了团队的创造性，但却是更高效率的。产品开发不同于研究。产品开发更多的是需要一种“收敛”，从“想法”到“产品”的“收敛”。如果你发现这种做法埋没了团队中太多富有创造精神的成员，但你要检讨团队的成员结构，或者你现在的团队适合研究而非产品开发。
五. NV陷阱
NV是PMT的另一个词汇，意即“下一版本”。在功能性需求上，CPD陷阱是常见的。而对于非功能性需求，比如产品性能上，NV陷阱是很容易陷入的。陷入NV陷阱后，往往到时候产品的质量会大打折扣，甚至“拿不出手”。另外，不完整的需求也容易导致错误的设计，这种架构上的缺陷实际上很难在“下一版本”轻易的改变。
除了主观上对非功能性需求的不重视，陷入NV陷阱的原因常常还有迫于时间压力，或者毫无来由的乐观。开发人员常常认为他们在以后的同样长的时间里可以完成多得多的事情，而且这些事情通常是现在不大愿意做的事情。
“这个版本的确不够稳定，下个版本再说吧”，这是经常可以听到的说法。为了防止陷入NV陷阱，非功能性需求从一开始就要被提出来，并受到应有的重视。如果这些非功能性需求是确实需要的，就应该被写入需求规格书，并在产品开发过程中接受实现状况的检查。
有限的需求来源、模糊的需求界定、CPD陷阱和NV陷阱是新产品开发项目中常见的四大问题。除此以外，新产品开发项目中也存在其他的一些特殊问题，比如在需求的跟踪管理上，新产品开发项目就与其他类型的项目有不同的地方。PMT将继续这方面的研究和实践，并期待和广大读者的交流。
你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。
现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。
许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不愿意将其产品说明书放在公共区域。
这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。
不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。
高质量需求叙述的特性
我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。
正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。
只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。
可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。
必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。
优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。
我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。
明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。
可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的高质量需求说明的特征
一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。
完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。
在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。
如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。
一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。
可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。
可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。
需求质量的评审
这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。
例1．“产品应在不少于每60秒的正常周期内提供状态信息”
这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。
弥补缺陷，重写需求的一种方法：
1、状态信息
2．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
3．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比
4．3任务完成时，应显示相关的信息
后台任务出错应该显示错误信息
为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。
例2．“产品应瞬间在显示和隐藏不可打印字符间切换”
计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。
象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。
例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？
试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。
例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。
在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的。
编写质量需求的方针
编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。
句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们
要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。
需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。
密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。
通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。
避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。
如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。
转自：
"http://blog.ourhtml.com/?action=show&id=259&page=1":http://blog.ourhtml.com/?action=show&id=259&page=1
多看多学习，任何时候，产品经理都应该比其他人想得更多，真的是很难，而且文档只是产品开始的第一步，剩下的实施将更为困难。一个足够复杂的文档自然有好处，在实际运行中可以做减法，这非常容易，如果要做加法则会比较困难，需求增加更容易影响到产品的最终逻辑，何况，交给技术人员的文档越明白越好，如果你足够剽悍，甚至可以精确到代码层面。这里不是说让技术人员纯粹的垒代码，而是尽量把技术人员的精力集中到解决程序难点上，避免多余的思考，当技术人员询问你：“这个东西到底怎么是什么？”的时候，就说明产品经理的工作还是有不足之处的。