项目所能耗费的资源是有限的→需求如果无限扩张，会造成以有限资源做无限工作的局面，最终导致忙中出错→在广度上，由于软件的应用环境处在变化之中，导致需求天生有越来越多的趋势→在广度上，对不做哪些需求要有清楚定义→在深度上，需求的明确是一渐进的过程。指望在初期某一截止时间点，澄清所有需求是不现实的。但能够澄清的没有澄清，却又导致效能降低→在深度上，要使需求开发的细致程度有所定义。
需求开发同时面对两个维度上的压力（尽管有时候，这两个维度可能有所重叠）。
在广度上，需求开发要尽可能明确究竟做什么，不做什么，如自己开发的项目管理系统究竟要不要和MSProject互相导入导出数据。
在深度上，需求开发需要尽可能明确，待开发软件的细节，如表单的具体格式。
在这两个维度上进行取舍时，所需要遵循的原则并不相同，我们来分别做一点考察。
1.在广度上寻找需求开发的边界
明确做或者不做某件事情的时候，有两个关键支点：一是值不值得做，二是能不能做。
似乎是“值不值得做”这一维度上的判断有更大的权重，毕竟大多时候软件是商业的一种延续，但实际上这个想法是很多软件开发出问题的罪魁祸首。
影响软件存在价值的东西，无疑具有最高优先级，但值得注意的是需求进行扩张的时候，扩张的并非这种生死攸关的需求，而是一些有价值但又不影响软件生死存亡的要求。
比如说，在开发项目管理软件时，大多时候，需求扩张时并不是关于“要能够依照WBS分解创建每个人的任务”，而是关于“是否要支持在Excel中创建任务，而后把任务导入到这一管理软件之中”。
这很正常，影响软件生死存亡的要求是软件存在的根本，大多时候在第一时间就会被提出来，并不需要在后面进行持续地扩充。
在现实中，商业要求总是有更高的权重，这就导致了这种不做也行，做了更好的需求会不断增加。这个时候如果日程本身又是定死的，事情就会变得非常尴尬。开发人员的工作变成了唯一的变量，于是开发人员就变成了一只只骆驼，背着一根根不停增加的稻草。与此同时，日程变得越来越紧张，项目是否崩溃则取决于最后那根稻草是否出现。所以说在判断某个需求究竟做或者不做时，先判定是不是“不做会死”，如果不是，那要优先考虑“能不能做”。考虑“能不能做”时，无疑的要考虑当前的工作负荷、新要求可能耗费的人力（需要比较精确的估算）等，但这反倒不是困难的事情。
2.在深度上寻找需求开发的边界
如前文所说，理论上讲，需求开发的结果与最终代码应该完全等价，因为虽然角度不同，但它们描述的实质上却是同一个东西。
这里的难点在于，需求开发真的可以做到代码所能到达的细致程度么？达到这种程度是否又符合最佳资源分配的原则？
我们可以把需求开发与设计编码的关系类比为常说的“想”和“做”。在没实现之前，需求开发得再好，也只是想象中的软件，是“想”。而在“设计编码”即“做”的过程中，始终伴随着对“想”的深化。
这就导致如果想做完美的需求开发，那么需求开发必然与软件开发整体结束的时间一致，不论是范围上，还是细致程度上。
而项目的时间限制不太可能允许单纯的需求开发一直持续下去。所以需求开发将是适可而止的需求开发。需求开发究竟在哪里终结本身是个经济问题。
我们假设预先澄清某一需求的成本是X，而没事先澄清这一需求，导致这一需求在较晚时期发现，并进行应对的成本为Y。显然在X=Y是需求开发的终止尺度。至于X<Y的情形究竟有哪些，眼下并无定论，我们来试做一点分析。
X<Y意味着Y会偏大，而Y偏大意味着需求对后续环节（设计、编码、测试等）影响比较大。这样的话，我们知道下面这些方面基本满足这一条件。
●方向性约束。这类约束一旦忽略，很可能软件自身的存在意义或可能性就受到影响。如与既定公司策略的吻合程度，有关的现行法规或标准，是否现存技术可以支撑，是否有类似的产品或组件（购买即可）等。
●非功能性要求往往对应于代码的根本结构，如果没有预先澄清，大多时候得不偿失。比如，每条记录的查询时间必须少于0.1s（性能要求），必须平台无关（可移植性要求），内存耗费的程度。(www.xing528.com)
●国际化的要求。比如，支持的语种、国家和地区。
●支持的硬件和平台。比如，是否会既支持Windows也支持Linux，是否支持64bit。
●是否需要兼容什么软件、协议。比如，是否要同Offfice互换数据。
●与出错处理这样全局性机制相关的要求需要预先澄清。比如，操作过程中如果磁盘满，那么需要弹出XX消息，接下来操作终止。
●横跨整个软件的Use Case。比如说，对于项目管理软件，创建任务，跟踪任务，对应的时间收集这样的典型场景下隐含着整个管理思想（领域模型）。
●与上述项目相反，前期细致讨论与UI相关的细小需求往往得不偿失。非功能性要求
很多非功能性需求是需要预先考虑的，一旦放入迭代之中往往会得不偿失。
《软件架构设计》一书中对非功能性要求做了很好的总结和描述，下面做一点摘录。
◆安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
◆易用性：指软件易于使用的程度。
◆可伸缩性：指当用户数和数据量增加时，软件系统维护高服务质量的能力。
◆可靠性：指软件在一定时间内无故障运行的能力。
◆鲁棒性：指软件系统在以下状况下仍能正常运行的能力：用户进行了非法操作；相连的软硬件系统发生了故障，以及其他非正常情况。
◆可扩展性：为适应新需求或需求变化为软件增加功能的能力。
◆可重用性：重用软件系统或其一部分的能力的难易程度。
◆测性：对软件测试以证明其满足需求规约的难易程度。
◆可维护性：为了达到下列3种目的之一，而定位修改点并实施修改的难易程度：修改Bug、增加功能、提高质量属性。
◆可移植性：将软件从一个运行环境转移到另一个不同的运行环境的难易程度。
◆……
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
