阅读需要具备一定的需求工作经验，并非通过阅读能够直接获取经验和知识，如果不具备经验可以跟有经验的人去交流，获得知识需要认真的思考，勤奋和努力
需求其实并非在谈需求
需求是某种自然法则，等着你来发现。需求的活动主要不是编写需求文档，相反，它专注于理解业务问题，并为之提供解决方案。软件是要解决某种问题，硬件和服务也是。需求发现的真正艺术是发现真实的问题。
如果我们必须构建软件，那么它必须为拥有它的人提供最理想的价值。
产品提供的利益必须与产品的成本相称。“业务分析师”、“需求工程师”、“产品拥有者”、“系统分析师”以及其他“头衔”的职责，就是确定拥有者最看重的价值是什么。
如果软件不必满足需求，那你怎么干都行。但是，如果它打算满足需求，你就必须知道要求是什么，才能构建正确的软件。
你必须得到需求的正确理解，并与客户达成一致意见，否则你的产品或项目就会有严重的缺陷。不幸的是，需求并非总是得到正确的理解。软件开发者（几乎）有机会消除这些错误，但许多人选择（或他们的项目经理）几乎跳过需求的发现，直接轻率的开始构建错误的产品。如果开始就发现了正确的需求，成本会低很多。
构建一个软件和解决一个业务问题之间，存在巨大的差别。前者不一定实现后者。
软件要对拥有者有价值，就必须解决拥有者的业务问题。最多的错误就是需求错误，相当多的软件不能正确的解决问题。
我们永远不知道用户批准上一次交付是因为对它满意，还是因为被过程搞得筋疲力尽。
我们必须无数次的强调：软件就是要解决一个业务问题。所有开发工作者都必须从问题开始，而不是从看到的解决方案开始。
需求不一定要写下来，但构建着必须知道它们
在某些情况下，口头沟通需求更有效，在另一些情况下，必须永久的记录下需求。需求的理由记录了【团队】的决定，它也为【测试】者和【开发】者提供了清晰的指示，说明了需求的重要性，从而建议需要花多少工作量。此外，如果【维护】者知道为什么有这项需求，也会降低将来维护的成本。
需求的工作并不是要为项目增加额外负担，编写需求的工作将带来数倍的回报，因为需求的准确性会影响将来所需要完成的工作。
客户不一定总能带给你答案，有时候客户也不可能知道什么是对的，有时候他就是不知道需要什么。
传统来讲，需求活动被看成是某种类似速记员的任务。准确记录他们说的所有东西，并将他们的要求翻译成产品的需求。需要考虑到利益相关者在试图描述需求时的困难。展望一个产品来解决一个问题，尤其是问题并非总是理解的很彻底，也有“增量改进”的问题，这种增量的方式通常排除了重大的创新，常常会导致平庸的产品，不能满足期望。
需求不是偶然得到的，要通过某种有序的过程得到
所有重要的努力都需要有序的过程。这些过程不是因循守旧的过程，不是无头无脑的执行所有指令，不过问任何疑问，按照实现描述的顺序，没有任何变通。相反，有序的过程由一组任务构成，实现预期的结果，但是这些任务的次序、重点和应用程度总需要采用该过程的人或团队来决定。最重要的是，参与这个过程的人必须能看到，为什么过程中不同的任务是重要的，哪些任务对项目最重要。
你怎样去迭代都可以，但仍需要理解业务的需求
迭代式开发方法变得越来越流行。这肯定是有意义的进步，但像很多进步一样，这些技术有时候炒作过度了。
冷静地头脑会意识到，任何开发技术都需要发现需求，真实认真开发的先决条件。需要冷静的头脑事先已经将需求过程吸收到他们的开发生命周期中。聪明的做法不是废弃需求，而是从一个不同的方向接近需求。
真正值得关注的是既要发现需求，又不必编写无用的、不成熟的、浪费成本的成堆的文档。不论你怎样开发软件，总是要理解客户的业务问题，以及产品必须做些什么来解决这个问题（即它的需求）。
没有银弹。所有的方法和工具都无法弥补糟糕的想法和糟糕的手艺
虽然我们需要有一个有序的过程，但不应该认为它能够代替思考。在需求的过程中，业务分析师需要面对几个版本的需求，同时还要想象未来最好的软件产品是怎样的。
需求活动从来都不会是简单的，想要成功，就需要业务分析师的思考和理解。会有一些自动化的工具可以有所帮助，但它们只能作为辅助手段，而不能够代表最好的需求实践。盲目的遵循事先制定的实践，根本不能取得有经验的业务分析师能够取得的结果。分析师最重要的工具：头脑、眼睛和耳朵。
要想成功地实现需求，需求就必须可度量、可测试。
从本质上说，功能需求是产品支持其拥有者的业务时必须要做的事。非公能需求是产品要在拥有者的环境中取得成功，必须将功能完成得多好进行量化描述。
要让构建得产品完全满足这些标准，在编写需求时就必须准确。同时，必须考虑到需求来自于人，而人并非总是准确，可能总是不准确。要达到必要的准确程度，必须对需求进行某种测量。
即使完美的程序检验工作，也只能建立满足规格说明的程序。软件任务最难的部分在于，得到完整而一致的规格说明书。构建一个程序的许多本质工作，实际上就是消除规格说明书中的缺陷。
如果不能为需求找到测量指标，那么它就不是需求，只是一种无根据的想法。
作为业务分析师，你将改变用户思考这个问题的方式，不是现在就是将来。
在你开始理解需求时，尤其在需求来自于不同的利益相关者时，你就开始建立一些抽象概念，并建立一系列词汇表。你战士业务过程的模型，与利益相关者一起发现工作的本质，得到清晰和可测量的需求，并将所有这些事实反馈给利益相关者。在做这些事情时，你就会改变（改进）它们对业务问题的看法。
如果人们对需求的含义有了更好的理解，他们就可能看到改进的办法。你的一部分工作就是帮助人们尽早理解和质疑他们的需求，这样让他们就可以帮助你发现他们真正的需求。
