软件需求.pdf

下载 第一部分 软件需求： 是什么和为什么 第1章 基本的软件需求 “喂，是P h i l 吗？我是人力资源部的M a r i a ，我们在使用你编写的职员系统时遇到一 个问题，一个职员想把她的名字改成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 万美元的房子，他一定会与建房者详细讨论各种细节， 2 第一部分 软件需求：是什么和为什么 下载 他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发， 人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析 阶段埋下的“祸根”（L e ffingwell 1997 ）。可许多组织仍在那些基本的项目功能上采用一些不 合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得 到的软件存在着巨大期望差异。 在软件工程中，所有的风险承担者（ s t a k e h o l d e r ）都感兴趣的就是需求分析阶段。这些风 险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客 户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客 户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发 者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上 的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用 本书提供的有效的需求分析过程。 本章将帮助你： •