基本事实：（11个）
1.需求是某种自然法则，需求活动不是编写需求文档。相反，它专注于理解业务问题并为之提供解决方案。
2.如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。
需求发现者必须确定拥有者看重的价值是什么。在某些情况下，提供一个小系统，解决一些小问题就能够为拥有者提供足够的利益；在另一些情况下，扩展系统的功能提供很大的价值，并且可能只要增加少量成本就可以实现。这都取决于拥有者认为什么有价值。
最佳价值：充分理解拥有者的问题，以便交付一个解决方案，以最好的价格提供最好的回报。
3.如果软件打算满足要求，就必须知道要求是什么，才能构建正确的软件。
不幸的是，需求并非总是得到正确的理解。数据表明，多达60%的错误源自于需求活动。如果开始就发现了正确的需求，成本会低很多。
4.构建一个软件和解决一个业务问题之间，存在巨大的差别，前者不一定实现后者。
软件要对拥有者有价值，就必须解决拥有者的业务问题。
5.需求不一定要写下来，但构建者必须知道它们。
需求是否写下来，不是问题的要点。在某些情况下，口头的沟通需求更有效，在另一些情况下，必须永远的记录下需求。除了改进理解外，正确的需求编写也提供了追踪文档。需求的理由，或故事卡上的缘故，记录团队的决定。它为测试者和开发者提供了清晰的指示，说明了需求的重要性，从而建议需要花多少工作量。此外，如果维护者知道为什么有这项需求，也会降低将来维护的成本。
6.客户不一定总能给你正确答案，有时候客户也不可能知道什么是对的，有时候它就是不知道需要什么。
直接将客户的要求翻译成产品需求的坏处是：没有考虑到利益相关者在试图描述需求时的困难。
也会有增量改进的问题，常常会导致平庸的产品，不能满足期望。
业务分析师必须表演戏法。每个利益相关者都有可能时匹诺曹，不要什么都相信。
7.需求不是偶然得到的，而是通过某种有序的过程得到。
8.你怎么迭代都可以，但仍需要理解业务的需求。
9.虽然我们需要有一个有序的过程，但不应该认为它能够代替思考。
在需求过程中，业务分析师需要面对几个版本的需求，同时还要想象未来最好的软件产品是怎么样的。
分析师使用最重要的工具:眼睛、头脑和耳朵。
10.要想成功的实现需求，需求就必须可度量、可测试。
例如：如果产品的一个需求是“应该对新用户有吸引力”，那么就可以建立一个测量指标，即初次使用的用户能够在2分钟内成功建立一个账户，对于用户应该知道的所有数据项，都不会超过5秒钟的犹豫，如他的姓名、邮件地址和类似的数据项。（犹豫时间是测量产品直观程度的指标，是对用户的吸引力的一部分）。
如果不能为需求找到测量指标，那它就不是需求，只是一种无根据的想法。
11.作为业务分析师，你将改变用户思考这个问题的方式，不是现在就是将来。
在理解需求时，尤其在需求来自于不同的利益相关者时，你就开始建立一些抽象的概念。并建立一个词汇表。你展开业务过程的模型，与利益相关者一起发现工作的本质。得到清晰和可测量的需求。并将所有这些事实反馈给利益相关者。在做这些事情时，你就会改变他们对业务问题的看法。
