作者不仅通过案例分析和举例辨识出团队在引进实例化需求时可能面临的一些常见挑战和问题，而且还提供了具体的建议用于解决这些问题。
尽管该书中所举的大部分例子和案例分析，涉及的是一些采用敏捷开发的团队和组织，但是作者也指出了一个重要观点，这些方法并非局限或依赖于敏捷方法。
该书讲到了测试自动化的价值，并给出了实现自动化方面的建议，但是作者没有深入探究一些可用的工具及其如何配置它们。不过配套的网站提供了一些资源，包括书籍、开源和商业软件的链接、一些文章的链接、视频教程以及演示文稿.
在Adzic自己的网站上，他介绍了该书的几个主要思想：
实例化需求是一组过程模式，可以协助软件产品的变更，确保有效地交付正确的产品。 这里所说的正确产品，指的是该软件能满足客户或企业用户提出的商业需求，或者能达成预定的商业目标；同时它要具备一定的灵活性，未来能以相对平稳的投入接受后续改进。
他描述了该过程的多个步骤用以获得需求，并将其转化成一份“活文档“：
从目标中获取范围
用实例进行描述
精炼需求说明
自动化验证，无须改变需求说明
频繁验证
演进出一个文档系统
Gojko说：
自动化的实例化需求，如果仍以自然语言表达，并且团队的所有成员都可以轻易获取到，那这实际上就形成了一份可执行的需求说明。
“活文档”是实例化需求的最终产物。为了建立起活文档系统，很多团队最终都为需求说明和测试设计了一门领域相关的语言。
出版商为InfoQ的读者制作了一个示例章节，可以在这里找到。
作者还在amazon.com和amazon.co.uk上进行“A-B测试”的对比，并为协助测试者提供一份海报。
最近InfoQ的Shane Hastie访问了该书的作者：
InfoQ：请你简单介绍一下你自己，还有是什么启发了你写《实例化需求》呢？
Gojko：我是一个顾问，主要与致力于提高软件质量和以迭代为交付模式的团队合作。过去的5、6年时间里，我一直在关注敏捷验收测试和行为驱动开发上，而实例化需求是一个很自然的延续。有两点启发了我写这本新书。其中一个是Tom Gilb在2009敏捷测试日演讲时宣传敏捷并不实用，而且没有数据能证明敏捷如大多数描写和演示它的人说得那样好。另外一个是一篇2009年在InfoQ上发表的文章，其中问到是否真有人在敏捷过程中实现了自动化验收测试，还是说该想法只是一个理论上的提议。在那时，我已经目睹过该过程在一些环境下获得了很大的成功，我无法理解这些针对敏捷的怀疑和否定，所以我决定开始收集真实的故事，而不是自我感觉，用以展示给大家确实有人，而且是很多人，已经通过实践该过程从中获得了很大的益处。
InfoQ编写这本书的目的是为了解决哪些问题？
Gojko：在软件开发社区中，人们对于实例化需求、验收测试驱动开发以及行为驱动开发，确实有不少误解。五年前，我在各种会议中遇见的很多人都从没听说过这些概念。现在大部分我见过的人都听说过它们， 但还是只有极少数人在他们的过程中成功地实施了这些想法。大多数的失败主要是由于那些常见误解造成的。在本书中，我介绍了那些成功团队在他们的过程中实施成功的7个关键模式，还有很多从50个不同背景的项目经验中获取的窍门和应该避免的注意点。我希望这些知识能够帮助问题团队找出他们自己的典型障碍，排除他们，并提高他们的交付过程。
InfoQ：在该书中，很多经常提到的概念和想法就是大家所说的验收测试驱动开发（ATDD）或者行为驱动开发（BDD），为什么你要提出新的术语实例化需求，而不是使用它们两个？
Gojko：这个术语的负面看法最少。在编写本书的时候，我遇到的一个很大的问题就是如何将来自不同团队的知识以一个统一的概念展现给大家，同时我也意识到作为一个社区我们在这整件事情上采用了完全错误的言词。我们使用技术术语为其命名，却造成了商业用户的困惑，以至于很多想让他们参与进来的想法都失败了。而且我们在命名各种软件过程的工件时也很少会有一致性，这造成了更多的困惑。由此我决定这本书的目标就是要推广一套术语，帮助人们在脑袋里建立起正确的心理图像，让团队可以避免那些常见的陷阱和误解。一个主要的问题是在整个开发过程中，团队过分侧重于测试的方面，将整件事情理解成只是一个测试活动。这就是为什么我不想使用ATDD的原因。而BDD则是一个还没有精确定义的方法论。取决于你讨论的对象，它可能包括也可能不包括基于拉动式的工作模式，从外到内的设计之类的事情。使用实例作为功能的需求说明，并基于那些实例进行自动化测试是BDD的核心支柱，但是它可能不止这些。我们很可能要等Dan North写一本关于BDD的书去将其明确说明。我希望这本书就是一组具体的实践方法，可以运用在不同的方法论中，就像我曾访问过的那些使用XP、Scrum、Kanban及其他方法的团队。