需求之于软件犹如水、空气之于人，它既为设计提供输入，又用于对输出进行验证。故对于需求分析，占用再多的精力都是值得的。很多人错误的认为需求分析仅仅发生在项目的开始阶段，然后很快就退出了（当然这是需求工程师的终极追求，这要得益于超于常人的审慎和判断，以及客户明确的传达出他想要什么），这种错误的认知会潜移默化的影响的设计决策，设计的不够灵活、设计的只重当下，。而事实是需求的变化是贯穿项目的整个生命周期，任何阶段只要是有意义的需求变化都应该被接收，被实现。对于需求的变更，任何人都没有理由说“No”，因为这就是需求，这就是客户想要的样子。
为了更准确，更高效的管理需求，很多公司采用了层次化的方式，不同的CFT（cross function team）负责不同层次的需求。市场部门的同事因为能够经常性地接触到客户，经销商，甚至竞争对手的产品，他们可以对产品的发展趋势，市场的定位情况等作出比较明确的判断，从而形成商业需求规格。
商业需求规格很好的反应了市场的趋势，以及用户所期待的基本的功能、性能指标，但是距离最终产品还有非常大的GAP。系统需求规格正是为了弥合这一点，它涵盖了与产品相关的电子、结构、软件、采购、生产、服务、法规监管、质量以及基本的功能、性能的细节等方方面面。而且因为软件的特殊性，很多厂商会将软件的需求从系统需求中分离出来，形成单独的软件需求。
上述对于产品需求的阐述正是软件工程中“分而治之”的层次化的一个例证，能够帮助个人以及企业更好地管理、量化需求。从商业需求到系统需求再到软件需求，是一个从抽象到具体，从偏向用于到偏向实现转化的一个过程，这个需求之间有着明确的依赖、引用关系，从而也形成了某种变更依赖关系，当其中的任何一个发生变更的时候一定要及时更新相邻的链条。实际操作过程中，常见的一种现象时商业需求一个小小的改动，可能会整个篇幅的影响软件需求。
在软件工程的生命周期中，各种各样的缺陷都可能会出现，随着项目的深入缺陷的修复代价会越来越大甚至成指数级攀升，一个常规的编码错误可能很容易修复，只要条件合适，或者必现，很容易就可以修掉，可是如果缺陷发生在需求层面，可曾想过影响会有多大？我们都知道测试工程师的工作就是按照需求规格，设计各种各样的测试用例，来验证产品是满足了系统规格。如果测试工程师无条件的信任需求规格，会发生什么呢？细思极恐！这里要说的正是需求应该具备的一些属性，精确性、无歧义性、可操作可实现性、可测试性。但是仅仅这些仍然无法规避错误的需求给开发带来的负面影响，那么最通常的一个手段“审阅”，不断的“审阅”，不同的部门之间的互相“审阅”。审阅者专注在自己的领域，发现并记录自认为是潜在的缺陷，并在团队内部形成共识，最后反馈到需求owner。一个小的改变可能不会对系统提升带来多大的影响，几个，几十个的叠加就会带来非常大的改变。
