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个用户同时使用”来代替。如果最终产品只能支持千位数的用户，我们就知道这条需求没有被满足。
1700423475
1700423476
1700423477
1700423478
[
上一页 ]
[ :1.700423429e+09 ]
[
下一页 ]