1700423425
功能规格说明在某些方面的名声不太好。程序员们痛恨功能规格说明，因为它们非常枯燥，并且会占用大量编码的时间去阅读它们。结果，那些“没有人读的功能规格说明”反过来又强化了“撰写它们是一件浪费时间的工作”的印象—事实上也正是如此！一个应用不当的功能规格说明就这样变成了自我应验的预言。
1700423426
1700423427
对功能规格说明的抱怨之一是它们没有反映实际的产品。“在实施过程中事情会产生变化”，每个人都理解这个—这是技术型工作的正常情况。有时候你考虑好的一些事情会行不通，或不大可能以你想象的那种方式来运作。无论如何，这并不是一个把撰写功能规格说明书当成一件失败的工作而放弃的理由。相反，它强调了一个真正起到了作用的功能规格说明书的重要性。当事情在实施过程中改变的时候，你不应该举起你的双手宣称撰写功能规格说明书是没有价值的，而是应该让撰写的过程变得快速简便，不要把它变成产品开发过程中一个独立的项目。
1700423428
1700423429
换句话说，文档不能解决问题，但定义可以。我们需要的不是文档有多厚或有多详细，而是要足够清楚和准确。功能规格说明不需要包含产品的每一个细节—只需要包含在设计或开发过程中出现有可能混淆的功能定义。同时功能规格说明也不需要展望产品未来的理想化状态—只需要记录在创建这个产品时已经确定下来的决议。
1700423430
1700423432
记下来
1700423433
1700423434
无论这个项目有多么庞大或多么复杂，有几条规则适用于撰写任何类型的功能规格说明。
1700423435
1700423436
乐观（be positive）。描述这个系统将要做什么事情去“防止”不好的情况发生，而不是描述这个系统“不应该”做什么不好的事情。比如，下面这句描述就不太好：
1700423437
1700423438
这个系统不允许用户购买没有风筝线的风筝。
1700423439
1700423440
替换成下面这句会更好：
1700423441
1700423442
如果用户想买一个没有线的风筝的话，这个系统应该引导用户到风筝线页面。
1700423443
1700423444
具体（be specific）。尽可能详细地解释清楚状况，这是我们能决定一个功能是否被实现的最佳途径。
1700423445
1700423446
对比下面的例子：
1700423447
1700423448
1.最受欢迎的视频要重点标注。
1700423449
1700423450
2.上一周被播放最多的视频要显示在列表的最前端。
1700423451
1700423452
第一句话看上去像是定义了一条明确的需求，但是不需要花费太大精力就能看出它有很多漏洞。什么叫做“最受欢迎”？如果这个视频的评论最多，是否就“最受欢迎”了呢？那么被投票最多的那个视频也算吗？另外如何“重点标注”它们？
1700423453
1700423454
第二句话用具体的细节定义清楚了我们的目标，定义了我们认为什么算“最受欢迎”，并且描述了关于“重点标注”的机制。
1700423455
1700423456
避免主观的语气（avoid subjective language）。这是另外一种使需求“保持明确”和“避免歧义”的途径—因而也避免了误解的可能性。
1700423457
1700423458
这里有一个非常主观的功能规格说明：
1700423459
1700423460
这个网站的风格应该是时尚、闪耀的。
1700423461
1700423462
功能规格必须可验证—就是说，它必须要能证明“这个需求没有被满足”。你如何去验证这种被宣称为“时尚”和“闪耀”的产品品质？我对于时尚的定义也许并不符合你的，而CEO更可能对此有完全不同的看法。
1700423463
1700423464
这并不是说你不能要求你的网站时尚。只是必须找到某种方式来明确说出应该达到的标准：
1700423465
1700423466
这个网站应该符合邮递员Wayne所期望的时尚。
1700423467
1700423468
Wayne通常不会对这个项目说些什么，但是我们的项目发起人很显然会尊重他对于时尚的看法。而且这有可能和我们的用户的期望值是一样的。但是这样的一个需求仍然是很主观的，因为我们依赖的是Wayne的认同，而不是可以更客观界定的一系列的标准。所以，这个功能规格说明最好能像这样：
1700423469
1700423470
网站的外观应该符合企业的品牌指南文档。
1700423471
1700423472
时尚的概念已经完全从这个需求中消失了。相反地，我们得到了一个清晰、毫不含糊的、已有的参考指南。为了确保品牌指南有足够的时尚性，负责市场的副总裁可能需要去了解邮递员Wayne，或者去和她十几岁的女儿交流，甚至她还可能做一些用户调研的工作。这取决于她。但是现在我们可以明确地说出“这个需求是否被满足了”。
1700423473
1700423474
我们也可以量化地定义一些功能，通过这样的手段来避免主观性。正如成功的标准能使战略目标得以量化一样，用量化的标准来定义功能也能有助于知道我们是否满足了需求。比如，要求系统具有“高级别的执行能力”，我们可以用“要求这个系统的设计至少要支持1000个用户同时使用”来代替。如果最终产品只能支持千位数的用户，我们就知道这条需求没有被满足。
[
上一页 ]
[ :1.700423425e+09 ]
[
下一页 ]