什么是软件需求
对大多数人来说，若要建一幢数百万元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”(Leffingwell 1997)。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟(期望差异)—开发者开发的与用户所想得到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者(stakeholder)(这个词很有意思，原义是赌金保管者。我看过很多的翻译，有翻译成涉众的，也有的翻译成参与者的，但是我想他的主要意思就是和这个项目有密切相关利益的人)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用有效的需求分析过程。 软件需求的定义
IEEE软件工程标准词汇表(1997年)中定义需求为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
需求的层次
下面这些定义是需求工程领域中常见术语的定义说明。
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。
作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。
虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些曰子中，我甚至得了一种电话铃音恐惧症。
需求风险
下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。
2. 用户需求的不断增加
在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
产品开发中不断延续的变更会使其整体结构曰渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。
最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。
IEEE软件工程标准词汇表(1997年)中定义需求为：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明。
需求的层次
下面这些定义是需求工程领域中常见术语的定义说明。
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图所示。
作为补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 值得注意的一点是，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。
Frederick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents ofSoftware Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：
开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。
为什么这么说呢，因为在大多数的软件系统中，最终用户可能都不清楚他的需求是什么，这是千真万确的。如果你的用户告诉你需求就是这些了，不要相信他，继续刨根问底，直到你们都筋疲力尽了。
虽然听上去有些不可思议，但这是教训之谈，在我从事的项目之中，没有一个用户在软件接近完成的时候打电话对我说，我看了你们的软件，我想我必须改动一些地方。在那些曰子中，我甚至得了一种电话铃音恐惧症。
需求风险
下面列出了在做需求分析时一些很危险的做法，如果你发现你的一些做法与之相似，那么，给自己一些时间，好好思考一下，这些做法会对你的软件产生致命的影响。
1. 无足够用户参与
客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。 最重要的就是用户必须要重视他的软件，必须让他明白：如果失败，他的损失最大(当然你的损失也不小，但这时候你必须让他重视这项工作)。如果用户不够重视，想办法解决，否则你就不用再继续了。
2. 用户需求的不断增加
在开发中若不断地补充需求，项目就越变越庞大以致超过其计划及预算范围。这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。要想把需求变更范围控制到最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。
产品开发中不断延续的变更会使其整体结构曰渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。
最糟糕的莫过于用户觉得如果不再加点什么功能就对不起自己。我曾经看过一个数据仓库的一期工程，在设计阶段没有很好的定义范围，当我向项目管理者提出这个问题的时候，他认为都已经说好了，合同上也写清楚了，并没有加以重视。可是最后，用户提出的修改意见已经远远超出了范围，项目时间也延长了一倍。整个的项目组成员疲惫不堪，可是却不断的接到用户投诉说项目失败。
