使用Impact Mapping
划定问题域的具体方法，是理解“Why”与“Who”。这和我在前篇对结合BDD进行DDD开发的一点思考和整理中介绍Impact Mapping这个工具时一样，重点是理解“为什么要这样做？”、“谁人将从中受益？”等问题，弄清客户开发系统所能期望的价值究竟是从何而来。此时，由于系统轮廓不清不楚，可能会感觉无从下手。为此，建议先分清业务目标与要交付的功能，而不是尝试去把每一个用户故事描述清楚。对此，我个人认为Impact Mapping提供的Goal-Actor-Impact-Deliverable模型，将是一个非常合适的挖掘工具。我们可以通过连续的Why提问，来弄清真实的、具体的、有期限的、能度量的业务目标。
从客户期待的输出结果推导业务目标
当难以确定业务目标时，先不要急于讨论需要哪些功能，而是可以从描述客户期待的输出入手，分析为什么需要这样的输出，从而归纳出业务目标所在。比如对于一个ERP系统，坚持“Report-first”，用各种报表展示客户期待的系统输出结果，由此发掘业务目标，可以帮助我们把注意力集中在具体的报表项内容上，而暂时把流程、处理等功能性需求放在一边。
使用“As a - In order to - I want”描述目标
As a stakeholder
In order to achive something valuable
I want some system function
这样三段式的描述，可以与Impact Mapping的内容有机地联系起来，相当于根据Actor-Impact-Deliverable直接转译而来。
询问的技巧
为什么这东西有用？ 通过提问，引导客户用具体的事例，来回答为什么某个功能有用？是如何给他的业务带来帮助的？“为什么需要这些东西”带有诘问的口气，因此并不推荐。
有什么可替代的方案？ 通过寻找可以替代方案，可以帮助客户从另一个角度去思考和认识自己的业务目标，同时也给团队的实现提供新的思路、决定当前提议的是否已经是最佳方案。
通过沟通协作来制定需求
系统需求，需要由客户与开发团队达成一致，确保系统的各个方面的功能都被包括其中，并有明确具体的验收指征作为约束。这和DDD中分享消化业务知识，得到领域的通用语言是一致的。在DDD中，也提倡专注于最有意思的对话上，并从用例开始，从一个系统行为作为起点，组织开发人员、业务人员和业务专家，围绕一个特定的场景进行讨论，由此发现这一场景内的领域概念和业务知识。这一点也正是我非常珍视的，实例化需求和BDD这一类方法，楔入DDD的关键点。
这种协作，不仅发生在开发人员与客户之间，同样也在开发人员与测试人员之间。如果开发人员与测试人员没有围绕Specification达成一致，那么双方就会各行其是。开发人员看到的是一堆的需求，而测试人员看到的是一堆的测试用例。若由开发人员撰写Specification，它会因为过于贴近模型设计而充斥大量的模式、架构元素，从而变得难以理解。若改由测试人员独立撰写时，可能又会因为太过琐碎零散而变得难以维护，最终迷失在各种测试细节的汪洋大海之中。测试人员编写的测试，没办法帮助开发人员去组织整个系统的各个部分，也无法通过自动化测试驱动整个开发过程。测试人员编写的测试，也没法被当作Specification再被开发人员利用，因为这些测试都是站在测试人员的立场，用测试人员的方言、专业术语编写和描述的，所以没办法用于双方的沟通。对于测试人员，则会在每次系统需求改动时，面对一大堆的测试重构。因为这些测试都不支持自动化测试，或者不容易被其他人理解。所以，协作是广泛的、多重的、具体的。
视协作的规模不同，可以分为：
· 大型的全体工坊： 适合项目刚开始的阶段，增进彼此的了解，并划定足够大的范围。但是要协调如此多人员的日程安排在某一天达到一致，是一件非常困难的事。
· “三剑客”式的小型工坊： 开发人员、测试人员、业务人员组成的小型团队，主要负责勾勒具体场景，产出Given-When-Then三段式的Feature文件。
· 结对编程： 分析人员与开发人员的结对，这是一种高效的方式。为了避免开发人员站在自己的视角采用TDD的方法编写用户故事而有失偏颇，所以转由分析人员编写测试，好让分析人员掌控Specification的全貌。但这又会产生另一个问题，分析人员编写的故事可能会影响到许多已有的测试，而他自己根本无法预见。同时，分析人员习惯于一个故事对应一个流程，从而产生大量重复。所以最后可行的方案，是由分析人员制定测试计划，并与开发人员一起编写feature文件，防止遗漏可能的需求。
· 非正式会议： 由分析人员、编程人员、测试人员和业务相关人员采取非正式的聚会形式，目的在于统一理解、消化知识，发现在各自独立工作时未能发现的内容与细节。
