项目管理入门（8）——范围之需求（功能需求）

 

翻译来源：
A Project Management Primer
or “a guide to making projects work (v2.0)”
by Nick Jenkins

 

需求

需求规格书是对满足客户需求时必须要完成的目标的提炼。

有时，在项目正式开始之前便已经开始着手需求规则书，用于选择正确的方案和技术。这通常称之为项目可行性研究。更为典型的是将一些需求凑在一起（可能在一个文档中），然后在项目真正开始之后才真正着手于需求规格书。

功能需求

功能需求即最终用户和利害攸关者要求产品所拥有的明显的日常需求。项目以功能需求为中心，且必须为用户提供这些功能。
典型的功能需求如“系统X必须有功能Y”，是一种“断言”。断言明确了利害攸关者严重系统必须的行为。

没有清晰的断言需求，除了给你带来令你思绪混乱的讨论之外，更没有任何好处。
对比一下下面两个截然不同的功能需求：
    • 该财务系统必须以附录A的描述来生成详细的客户发票
    • 为用户生成发票很重要。发票应包含所有必要的相关信息，以证明用户对货物的支付
第一个功能需求的描述是一种断言。表明了财务系统应以附录A中的描述来生成详细的客户发票。同时，其描述可以更具体，为了成功开发财务系统，读者不会对财务系统必须做的事情感到含糊。

第二个需求可以作为财会书籍的引言。尽管其陈述了发票的重要性，但没有提及由谁或什么来生成发票。那么会开始纠结发票中到底有什么内容。这样的描述不应该在需求规格书中。

第二个“需求”看起来与问题相关，但是其实是有歧义的。相关的信息是什么意思？以证明用户对货物的支付是多余的，否则发票是做什么的？这样的陈述，也许很准确，但是没有对系统要做什么有任何的贡献。

这里是一些“更好的”需求描述：
• 客户账户记录必须包含唯一个账号、主要联系人、联系方式，以及该客户在过去销售年中的销售清单
• 联系方式必须包括电话号码、地址、以及可选的电子邮件地址
• 对于每个联系方式，需要支持最多5个电话号码