如果软件不必满足要求，那你怎么干都行。但是，如果它打算满足要求，你就必须知道要求是什么，才能构建正确的软件。

这样思考很有价值:如果开发者正确地理解了产品打算为用户完成什么，以怎样的方式完成，这些产品就是最有用的。要理解这些事情，你必须理解拥有者的业务工作，并决定将来工作如何进行。
如果这些事情得到理解并达成了一致意见，业务分析师就与拥有者沟通，探讨怎样的产品能为工作带来最大的改进。业务分析师得到需求，描述产品的功能(它要做什么)以及产品的属性(它做到什么程度)。
不知道这些需求，开发项目得到的产品就不太可能有太大价值。除了少数撞大运的意外，没
有产品能在事先不理解需求的情况下成功。不论拥有者希望做哪种工作，科学的、商务的、电子商务的或社交网络的，也不论使用什么开发语言或开发工具来构建产品，开发生命周期(敏捷、原型、螺旋、Rational统一过程或其他方法)也与理解需求的要求无关。
这一事实总是会出现:你必须得到需求的正确理解，并与客户达成一致意见，否则你的产品或项目就会有严重的缺陷。
不幸的是，需求并非总是得到正确的理解。作者Steve McConnell和Jerry Weinberg提供的统计数据表明，多达60%的错误源自于需求活动。软件开发者(几乎)有机会消除这些错误，但许多人选择(或他们的经理选择)几乎跳过需求发现，直接轻率地开始构建错误的产品(这是不可避免的)。结果，他们在产品上花了许多倍的金钱。如果开始就发现了正确的需求，成本会低得多。糟糕的质量在开发生命周期中传递，事情就这么简单。