“问题的表述常常比它的解决方案更重要。”——阿尔伯特·爱因斯坦
理解“为什么”和“谁”
要评估一个解决方案，需要先理解为什么需要某些东西以及谁需要它们。
理解价值从何而来
相比在故事层次上讨论，在目标层次上讨论能更有效地梳理范围和优先级。
了解用户预期的输出是什么
当目标很难确定时范围也就不好界定了，此时可以着手研究系统的预期输出，一旦明确了期望的输出结果，就可以专注于实现这些输出的背后需求。分析为什么需要这些输出则有助于构想目标并获取范围。
从输出结果的实例开始，而不是和用户一起讨论往系统里增加某些东西。
询问“为什么某些东西会有用”
不要追问技术性的功能细节，而是要通过询问高层级的实例来理解功能如何有价值。
提出“为什么需要？”这样的问题，听起来好像在质疑；反之，询问“为什么有用？”则会温和许多，更容易让人接受。
询问替代方案
询问替代方案是从业务视角探索更多选择的好策略。
某些功能的用处或许很难表述清楚（即使举出实例也是如此），此时可以试着举一个反例来说明：如果系统不提供这些功能，你（用户）会怎么做？这样做能帮助大家认识到这些功能的价值所在。
不要在例子中使用 是/否 的回答
对于例子的确认，不要简单地用 是/否 来回答，应精确描述其功能特性。
比如说有一个例子用来描述发送邮件提醒的功能：“当系统事项发生更新时”，不要说*“是”，而是要说“应当发送两条邮件提醒，一条是取消旧的事项，另一条是注册新的事项”*。
不过对于判断型的例子，是/否 还是可以保留的，比如说某些用来“告知提醒邮件是否已经发出”的例子。
不要使用抽象的等式
抽象的等式包含陷阱！（小于10会不会包含负数？）要使用具体的例子，要么是精确的值，要么是精确定义的区间，如：0到1之间。
用数据做试验
尝试各种边界条件来验证例子是否完备。
使用替代方法来检验功能
为了测试故事是否有一组定义完善的例子，可以请用户来考虑一个替代方案。
“你觉得还可以怎样对它测试？”或者“还会有其他事情发生吗？”，提出类似的问题会很有帮助。
编造的例子要么无法提供足够的细节，要么无法揭示可能的变化，更糟糕的是还会误导你做出错误的决断。特别要小心抽象的，臆想的实体，比如“客户A”。找一个真实的客户，他/她必须具备你要描述的特点，这样你可以把注意力完全放在功能特性上。
避免虚构的数据
在依赖数据驱动的地方千万不要虚构数据，许多事情会依赖于真实数据细微的变化。
直接从用户那里获取基本例子
用户给出的例子也必须保证真实而非设想。有些用户会给出他猜想会有帮助的虚拟例子，但这其实很危险！
避免探讨所有可能的组合
举例的目的是为了增进沟通和理解，而不是为了穷尽一切可能性；但这并不是说边界条件无关紧要。当有人提出边界条件的时候，说明：1）他们没理解现存的例子；2）他们真的发现了一些会影响现存描述的东西。这些情况值得讨论。
寻找暗含的概念
如果用于描述某项功能的例子太多，或者太复杂，往往意味着这些例子应该用更高层级的抽象来描述。
领域驱动设计方法就是用来提炼更高层级抽象的好帮手。
所谓“非功能性需求”，通常是指如性能、安全性、易用性、响应时间（速度）等类型的特性，因为它们与单独的功能没有关系；但真相却是非功能性需求往往隐含着功能性。人们常常会把功能性需求误当作是非功能性需求，这是因为需求存在交叉性（如：权限）或者可按照比例来衡量（如：性能）。
获取精确的性能需求
当性能是关键特性时（相信我，没那么多。多数项目要到特定阶段之时性能才会成为瓶颈，而其中的大多数都挨不到那个时刻就死了），清晰地指明性能条件并举例可以帮助大家达成共识，并提供清楚的实现目标。
*“要比现有系统快”*可不是一个好的性能需求。要告知具体快到什么程度及其依赖的具体运行环境是什么。
为用户界面使用低保真度的原型