“喂，是phil吗？我是人力资源部的maria，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成Sparkle Starlight，而系统不允许，你能帮帮忙吗？”

　　“她嫁给了一个姓Starlight的人吗？” phil问道。

　　“不，她没有结婚，而仅仅是要更改她的名字，”maria回答。“是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”

　　“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”phil说。

　　maria说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则， Sparkle将不能支付她的账单。你能在此前修改好这个错误吗？“

　　“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声音）。“我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”

　　“那我怎么跟Sparkle说呢？” maria追问道，“如果她不能支付账单，那她只能挂帐了。”

　　“maria，你要明白，这不是我的过错。”phil坚持道，“如果你一开始告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想法（需求）责备我。”

　　maria不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修改好了，马上打电话告诉我，行吧？”

　　如果作为客户有过类似的经验，你一定知道：一个不能进行一项基本操作的软件产品是多么令人烦恼。尽管开发者终会满足你的要求，你也不会感谢他。但从开发者角度来看，在整个系统已经完成后，用户再提出对功能的进一步要求是多么烦人的事。同时，修改系统的请求迫使你放下当前的项目，而且往往修改请求还要求你优先处理，也是令人很不愉快的。

　　其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误带来的。例如上面的phil和maria，出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假设，不完善的需求文档，以及突发的需求变更过程。

　　对大多数人来说，若要建一幢2 0万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（L e ffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。

　　在软件工程中，所有的风险承担者（stakeholder）都感兴趣的是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者好是采用本书提供的有效的需求分析过程。

　　本章将帮助你：

　　• 了解软件需求开发中使用的一些关键名词。

　　• 警惕在软件项目中可能出现的与需求相关的一些问题。

　　• 知道的需求规格说明应该具有的特点。

　　• 明白需求开发与需求管理之间的区别。

　　1.1 软件需求的定义

　　软件产业存在的一个问题是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次的需求从不同角度与不同程度反映着细节问题。