唯爱小粽子：软件开发中需求的先决条件
“需求”详细描述软件系统应该做什么，这是达成解决方案的第一步。“需求活动”也称为“需求开发”、“需求分析”、“分析”、“需求定义”、“软件需求”、“规格书”、“功能规格书”等。
一：为什么要有正式的需求
要求一套明确的需求，这点很重要，理由如下：
1、明确的需求有助于确保用户（而不是程序员）驾驭系统的功能。如果需求明确，那么用户就可以自行评审，并进行核准。否则，程序员就常常会在编程期间自行决定需求。明确的需求免得你去猜测用户想要的是什么。
2、明确的需求还有助于避免冲突。在卡是编程之前，先把系统的范围（scope）确定下来。如果你和另外的一个程序员对于“程序应该做什么”意见不一致，你们可以查看书面的需求，以解决分歧。
3、重视需求有助于减少开始编程开发以后的系统变更情况。如果你在编程过程中发现了一个代码的错误，你只需要修改几行的代码，然后就可以继续工作。但是如果你在编码的过程中发现了一个需求错误，那你就得改变设计，使之符合更改后的需求。你可能需要扔掉部分旧的设计，并且因为要与已经写好的代码相适应，可能导致新的设计，与在项目之初进行同样的设计相比，话费更长的时间。此外，还需要废弃那些受此需求变更影响的代码和测试用例，还需要编写新的代码和测试用例。
充分详尽地描述需求，是项目成功的关键，它甚至很可能比有效的构建技术更重要，关于如何清除低描述需求，已经有了很多优秀书籍。因此我们这里不作过多的讲解。
二：稳定需求的神话
稳定需求在软件开发中基本上是很难遇到的情况。一旦需求稳定，项目就能以有序的、可预测的、平稳的方式，完成从架构到设计到编码到测试等一系列工作。这是软件的天堂！你能预测开支，而且根本无需担心实现某项特性的开销增大为原先计划的100倍--因为在你完成调试以前，用户根本没有想到这项特性。
“一旦客户接受了一份需求文档，就再也不做更改”是一个美好的愿望。然而，对一个典型的项目来说，在编码之前，客户无法可靠地描述他们想要的是什么。问题并不在于客户是低级生物。就如同你做这个项目的时间越长，对这个项目的理解也就越深入一样，客户参与项目的时间越长，他们对项目的理解也就越来越深入。开发过程能够帮助客户更好的理解自己的需求，这是需求变更的主要来源。计划严格依照需求行事，实际上就是计划不对客户的要求作出回应。
三：在构建期间处理需求变更
1、使用需求核对表来评估你的需求质量
如果你的需求不够好，那就停止工作，退回去，先把他做好，再继续前进。当然，因为在此期间你会停止编码，所以感觉进度似乎会落后。如果没有对准正确的方向，那要停下来检查一下路线。
2、确保每一个人都知道需求变更的代价
假如你的组织对于“先做需求分析”的重要性并不敏感，那你就指出在需求阶段进行修改，要比之后进行修改的代价低得多。
3、建立一套变更控制程序
建立一个正式的变更控制委员会，评审提交上来的更改方案。客户改变他们的想法，认识到他们需要更多的功能这不是坏事。问题是如果他们提出的更改方案太频繁了，让你跟不上进度。如果有一套固定的变更控制程序，那么大家都会很愉快--你知道自己只需在特定时候处理变更。
4、使用能适应变更的开发方法
某些开发方法能让你“对需求变更作出响应”的能力最大化。演进交付是一种分阶段交付系统的方法。你可以建造一小块、从用户获得一些反馈、调整一点设计、做少量改动，在多建造一小块。关键在于缩短开发周期，以便更快的响应用户的要求。
5、放弃这个项目
如果需求特别糟糕，或者极不稳定，而上面的建议没有一条能奏效，那就取消这个项目。