清华社样章大话软件需求——需求发掘与实现.pdfVIP

6

第6章

实例化需求

—如何写出高质量需求

第2～5章讲解了如何发掘业务需求、如何定义利益相关方需求、如何编制功能需求规

约和非功能需求规约。但是，这些内容和软件系统的代码实现之间没有直接的关联，可能

造成需求与代码实现的不匹配。本章聚焦如何把需求提升到可执行水平，使其成为代码的

一部分，从理论上消除从需求到代码实现之间的信息衰减。同时总结出编写实例化需求的

CARUN规则。本章的讲解重点如下：

为什么要引入实例化需求？

实例化需求是什么？

实例化需求怎么做？

第6章实例化需求—如何写出高质量需求203

6.1为什么要引入实例化需求

在软件系统研发过程中，做正确的事固然是一件困难的事情，正确地做事也不是轻而

易举的。传统上，哪怕是一个中型的软件系统，它的需求规约可能也是长篇巨著：几十万

字的软件系统需求规约非常普遍。为了更精细地描述软件系统对外提供的功能，上百万

字的需求规约并不鲜见。软件开发人员对于满篇充斥的“一定要做到……”“一定不能违

反……”的规定性描述文字，一方面感到非常枯燥，另一方面非常容易出现理解偏差。在

没有实际系统做演示的情况下，只有这些强制性要求的需求信息传递效果非常糟糕，因为

它们虽然看起来像是很精确，却包含很多潜在的和可能产生理解不一致的地方。每个软件

开发人员都有自己的假设，这些假设影响着他们对这些文字的理解。因此，急需一种有效

的方法，消除需求团队和开发团队之间对于需求理解的不一致，使软件系统的原始需求所

蕴含的信息能够准确、一致、高效地在各个团队之间传递。相对于抽象的理论、概念，人

们对于具体的实践、故事更容易理解和接受。就像同样深奥的经文，我们自己读起来可能

莫名其妙，而经过大师旁征博引、结合实际，就

能轻松明白其中的深奥道理一样，用“实例”来

描述需求，能更好地提升信息的传递效率，保持

它的一致性（图6-1）。

回想一下需求团队如何从最终用户处挖掘他

们的需要：聆听他们在实际工作中发生的“故

事”，或者期望能够完成工作的“方式”；通过对

这些故事的总结、归纳、提炼、精细化，最终形

成抽象、格式化、命令式的需求。为了验证、确

认和诠释这些抽象的需求，开发团队通常会重新

构建一些“业务场景”，以方便和需求团队进行

沟通（图6-2）。在这个过程中，是不是存在什么

图6-1大师讲经，舌粲莲花

问题？

用户故事业务分析团队软件系统需求研发团队验证场景

图6-2需求形成和验证过程

一个非常直接和自然的想法是：为什么不能够直接把最终用户的“故事”固化下来，

在不同团队之间传递呢？这样不同的团队看到的不就是同样的信息，能够消除信息传递过

程中的衰减了么？

GojkoAdzic总结了业界在这方面的研究和实践，并在2011年出版了《实例化需求：团

队如何交付正确的软件》一书，完整描述了实例化需求（SpecificationbyExample，SBE）

和用这种方法推进软件系统研发的模式。实例化需求就是用实例来精细化需求，其核心是

使用实例作为需求、开发和测试等团队之间沟通的桥梁，以实例为载体，多方协作制定需

204

大话软件需求—需求发掘与实现

求，从而保证团队所有成员对需求的理解一致，具有以下好处。①作为多方一起工作的成

果，在技术的支持下，能够“在不修改的情况下实现自动化验证”，消除信息传递衰减的风

险；②既可以作为开发的目标，也可以作为验证软件是否按照预期执行的标准，还可以作

为和客户沟通的依据；③能够实现持续验证，从而保障其与系统代码的一致性，避免出现

“需求文档完成即过时”的问题。

作为促进需求信息有效传递的最佳实践，实例化需求引入了一组过程模式，协助研发

团队正确研发软件系统（图6-3）。

范畴（用户