在使用你编写的职员系统时遇到一个问题，
一个职员想把她的名字改成Sparkle Starlight，而系统不允许，你能帮帮忙吗？”
“她嫁给了一个姓Starlight 的人吗？” P h i l问道。
“不，她没有结婚，而仅仅是要更改她的名字，”M a r i a回答。“就是这问题，好
像我们只能在婚姻状况改变时才能更改姓名。”
“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉
我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能
进入更改姓名的对话框。”Phil 说。
M a r i a说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的
姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则， S p a r k l e将不能支
付她的账单。你能在此前修改好这个错误吗？“
“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新
的性能检测系统，并且还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声
音）。“我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有
类似情况，请早一些告诉我并把它们写下来。”
“那我怎么跟S p a r k l e说呢？” M a r i a追问道，“如果她不能支付账单，那她只能挂
帐了。”
“M a r i a，你要明白，这不是我的过错。”P h i l坚持道，“如果你一开始就告诉我，
你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想
法（需求）就责备我。”
M a r i a不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。
等你修改好了，马上打电话告诉我，行吧？”
如果作为客户有过类似的经验，你一定知道：一个不能进行一项基本操作的软件产品是
多么令人烦恼。尽管开发者最终会满足你的要求，你也不会感谢他。但从开发者角度来看，
在整个系统已经完成后，用户再提出对功能的进一步要求是多么烦人的事。同时，修改系统
的请求迫使你放下当前的项目，而且往往修改请求还要求你优先处理，也是令人很不愉快的。
其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程
中的手续和作法（方法）失误带来的。例如上面的P h i l和M a r i a，出现的问题涉及到非正式信
息的收集，未确定的或不明确的功能，未发现或未经交流的假设，不完善的需求文档，以及
突发的需求变更过程。
对大多数人来说，若要建一幢2 0万美元的房子，他一定会与建房者详细讨论各种细节，
第一部分软件需求：
是什么和为什么
他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，
人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析
阶段埋下的“祸根”（L e ffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不
合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得
到的软件存在着巨大期望差异。
在软件工程中，所有的风险承担者（ s t a k e h o l d e r）都感兴趣的就是需求分析阶段。这些风
险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客
户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客
户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发
者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上
的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用
本书提供的有效的需求分析过程。
1.1 软件需求的定义
软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义
的“需求”对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来
说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不
同程度反映着细节问题。
I E E E软件工程标准词汇表（ 1 9 9 7年）中定义需求为：
（1）用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的
条件或权能。
（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。
1.1.1 一些关于“需求”的解释
I E E E公布的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）
来阐述需求。
关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者，
客户被迫与新的需求分析者坐到一起。分析人员说：“我们想与你谈谈你的需求。”客户的第
一反应便是：“我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统”。而
实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、
贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。
另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”
（Jones 1994）。需求分析专家Alan Davis （1 9 9 3）拓展了这个概念：“从系统外部能发现系统
2 第一部分软件需求：是什么和为什么
所具有的满足于用户的特点、功能及属性等”。这些定义强调的是产品是什么样的，而并非产
品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性（ S o m m e r v i l l e
and Sawyer 1997）：
需求是⋯⋯指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，
是在开发过程中对系统的约束。
从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存
在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）
仅是一个模型，一种叙述（ Lawrence 1998）。我们需要确保所有项目风险承担者在描述需求
的那些名词的理解上务必达成共识。
转摘自：ITPUT.NET