1988年，在苹果电脑，我度过了最糟糕的一周。苹果的开发系统小组开发了一个叫ASMCVT的工具，目的是为了要转换汇编源格式文件到另外一种格式化的更合适的新的汇编程序，该工具依然在开发之中。我被告知，由于相应的汇编测试团队的领导者，我将会在几天内收到这个工具。但是没有人逐字逐句的检查底层，直到开发者已经在下层的测试部分之上进行工作时，没有任何有关工具的细节。当我询问那个开发者，并且向他说明为了规划一套像样的规范，我们需要一个规格时，他告诉我，该工具非常简单并且写一个规格是完全没有问题的。

　　第二天他将一页纸放在了我的面前。那是一个漂亮的小文档，用30号的醒目黑体Helvetica “ASMCVT”横跨页面的顶部，还有一些其他的标记。我记得，还有一些水平的标尺，开发者的全名、日期、在他们旁边还有一类带着“N/A”的标题，和大量的空格。如果隔着一段距离或许会被误认为是一个真正的技术文档--带着莫名的称赞说谁设计的这个文档模板。但是它仅仅包含一个有技术含量句子：“这个工具从旧的汇编格式文件转换成新的格式”。

　　那个开发者好像很诧异，当我践踏他的文档，并朝他皱起了眉头时。

　　一 、讨论风险

　　他提供了一个微弱的防御措施，“几乎有1500种不同的文件需要从旧的文件转换成新的文件。当然，你别指望我将它们全部关闭。”是的，先生，我会那样做，如果你能够编译他们，你就能够写出来。我下一步的计划是我的老板Chris Brown，也是开发系统质量管理者。

　　“1500种，Chris，这就是他所说的。但是看看这个，”我将规格书举过头顶然后仍下来，他像羽毛一样随着空气飘动。“他称这个为说明书，我拒绝测试这个产品直到他告诉我这是什么。”

　　Chris似乎对于我示威的言行毫无反应：“Jim，”他说，“我们需要谈谈风险。”

　　使我惊奇的是，Chris没有看到测试一个没有规格的工具问题。他像这样解释道：“ASMCVT是一个将文本文件作为输入然后生产出一个新的文本文件作为输出的工具，这只是一个一次性的过程，它不会用任何方式改变原来的文件。源文件和新的文件都是人类能看懂的，在新文件中的错误将会很容易被发现，通过新的汇编程序来运行它，并且将会打印错误报告或制造一个新的对象文件，该对象文件并不是和旧的文件及旧的汇编程序制造的对象文件毫无差别的。如果我们不提供这个工具，我们的客户就必须手动转换它，尽管一个小的机动工具将会潜在的减轻他们很多的工作量。”

　　“这并不是一个高风险的情况，”他继续说道，“James，测试无非是风险管理。即使是一个简单的测试过程，基于我们假设没有什么工具，可能对于一个不太好的工具的风险管理已经足够。此外，你已经了解了足够多的有关新的汇编语法和旧的汇编语法之间的不同。如果任何的规格书问题提升了功能性或工具的风险，和开发者坐下来细细的询问他们。但是别指望开放信息垃圾。”

　　“仅仅是通过ASMCVT运行大量的源文件，”他总结道，“仔细检查结果，对于所有异常信息书写报告。如果现在在这里有一个非常重要的问题，你也许会发现它。”

　　……………………

　　查看全文请点击下载：http://www.51testing.com/html/02/n-227802.html

　　三 、要求重新审视

　　在普遍接受的软件开发实践中，需求分析应该是在设计以前就有的，并且设计应该是在编码和测试以前就有的。一些文件被认为应该是从需求分析中产生出来的。在IEEE 830-1993推荐的软件需求规格书包括一系列的质量属性列表：正确、完整、清楚、一致、重要性分级、可验证、可修改、并具有可追溯性。该规格被认为是应该指导后续的软件活动。

　　所谓的普遍接受的实践，尽管如此，并没有被普遍实践。正如我所遇到的他们一样，需求规格是一个模棱两可的问题状态和设计决定：他们表现的太过模糊或者太过精确，为了解释说明通常需要大量的背景知识，并且有些是在设计阶段就不用的或者忘记一半的。这些听起来熟悉吗？

　　对于一个拥有被大众接受的实践框架的不太好的需求规格，至少有一种简单的解决方法：做得更多。而不是压缩成了几周的访谈、会议、和熬夜写作，应该花费几个月的时间。一直坚持直到没有任何模棱两可和设计的风险。利用测试者、模拟器、完整模型，以及讨论组。探索全方位技术解决方法和评估收购与建造战略。让开发者隐姓埋名到客户现场，并且让他们像人类学家一样和潜在使用者生活在一起。