作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上所具有的选择限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能，多角度描述产品对用户和开发人员都极为重要。
需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将会最终给系统带来极大损害的部分，而且以后再对它进行修改也极为困难。
不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指推出的产品能以合理的价格、及时地完成并在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第 5章将介绍怎样应用软件风险管理从而防止与需求有关的风险的出现和不适当的需求过程所引起的一些风险。
（1）包含的用户数不多将导致无法接受的产品。
（2）用户需求的扩展将带来过度的耗费和降低产品的质量。
（3）模棱两可的需求说明可能导致时间浪费和返工。
（4）用户增加一些不必要的特性和开发人员“画蛇添足(gold-plating)”的追求。
（5）过分精简的需求说明以致遗漏某些关键需求。
（6）忽略某一部分用户类的需求将导致众多客户的不满。
（7）不完善的需求说明使得项目计划和跟踪等无法准确进行。
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户参与。究其原因：一来因为与用户合作不如编写代码有兴趣；二来因为他们觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白用户的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。
在开发中若不断地补充需求，项目就越变越庞大以致超过其计划安排及预算范围。计划并不总是贴近项目需求规模与复杂性的实际情况、风险、开发生产率及需求变更情况，这使得问题更难解决。实际上，问题根源在于用户对需求的改变和开发者对新需求所作的修改。
要控制变更范围的不断扩展，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，这也将有助于所有风险承担者明白业务决策的合理性，为何进行某些变更，以及相应消耗的时间、资源或特性上的折中。
产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码也使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作也不完善的话，收回变更和删除特性也会带来问题。如果你能尽早区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它，这样设计阶段需求变更不会直接导致补丁代码，同时也有利于控制因变更导致质量的下降。
模棱两可是需求规格说明中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的也不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例和重做许多测试。
来源：https://www.cnblogs.com/BUANG/p/5064292.html