需求分析先决条件

需求详细描述了一个软件系统需要解决的问题，这是找到问题答案的第一步。这项活动也 被称作“需求分析”、“需求定义”等。

3.3.1 为什么要有正式的需求

明确的需求是很重要的，因为：

明确的需求可以保证是由用户而不是程序员决定系统的功能。如果需求是很清楚的，那么 用户可以对其进行评定，并确认自己是否同意。如果需求不很清楚，那么程序员在编程过程中 就不得不自己决定系统功能，明确的需求防止对用户需求进行猜测。

明确的需求也可以避免引起争议。在开始编程之前，系统的范围已经明确确定了。如果在 编程过程中，两个程序员对系统干什么有争议，那么只要查阅一下写好的需求分析，问题就解

决了。

注意需求定义，也可以使得在开发工作开始之后，对系统作的改动最小、如果你在编码时 发现某几行有误，那么改掉这几行就是了。而如果在编码阶段发现需求有误，那么你很可能不 得不改变所有的代码以适应新的需求。

一些设计不得不被丢掉，是因为按它们的要求写好的代码不具备兼容性。新设计可能要花 费很长的时间，被一同扔掉的还有受到需求变更影响的代码和测试用例，即使未受影响的代码 部分也不得不进行重新测试，以确认其他地方的变动没有引入新的错误。

IBM、GTE、TRW 的数据表明．修正在总体结构阶段发现的需求错误，将比当时就发现并 修正的成本要高出 5 倍，如果是在编码阶段，要高出 10 倍，在单元或系统测试阶段，高 20 倍，

在验收测试阶段，高 50 倍，而在维护阶段，竟要比原来高出多达 100 倍！在较小规模的计划中，

在维护阶段修正错误的放大因子可能是 20 而不是 100，因为这时管理费用较低。但无论如何没 有人愿意从自己的收益中拿出这笔钱来。

充分进行需求分析是一个项目成功的关键，很可能比使用有效的创建技术还重要。关于如 何进行需求分析有许多好的论著。因此，我们不打算在随后的几部分中探讨如何进行需求分析。

我们只想告诉你如何确定需求分析已经完成，如何最充分地利用需求分析。

3.3.2 稳定需求的神话

稳定的需求可以说是软件开发的法宝。有了稳定的需求，软件开发工作可能从结构设计到 详细设计到编码，都平稳、顺利的进行。这简直是造就了软件开发的天堂。你可以预测开支，

不必担心最终会冒出一个让你多花 100 倍钱的错误来。

用户一旦接受了写好的需求文件，便再也不会提出更改需求，这简直是太好了。然而事实 上，在实际项目中，用户在代码写出来之前，往往并不能确切可靠地描述出他想要的到底是什 么，这倒并不是说用户是一种低级生物。正如随着工作的进行，你对其理解越来越深刻一样，

用户对自己想要的东西，也是随着项目的进行而越来越清楚的，这也是需求变动的主要原因。

－个从不变更需求的计划，事实上是一个对用户的需求不予理睬的计划。

典型的变动有多少呢？根据 IBM 的调查，对于一个典型的有一百万字的需求分析，大约 25%的内容在开发过程中要进行变动。

或许你认为卡迪拉克小汽车是空前绝后的，帝国大厦将万古永存，如果真是这样的话，那 你就相信你的项目需求永远不会更好了。如果不是这样，那么或许我们可以采取一些措施，使 得由于需求变更所造成的冲击最小。

3.3.3 在创建阶段如何对付需求变化

以下是在创建阶段，为应付需求变化而应该采取的措施。

用本部分后面的检查表来评估你的需求分析质量

如果你的需求分析不是很好，那么，停止继续工作，重新返回到需求分析阶段。当然，这 样会使人觉得你已经落后了。但是，如果你在开车从芝加哥到洛杉矶的途中，发现自己到了纽 约市郊，那么停下车来看一下地图是浪费时间吗？当然不是。因此，如果你发现方向不对，赶 紧停下来检查你的方向。

让每个人都知道由于变化需求所付出的代价

雇员们往往由于自己有了新的设计想法而激动不已。在这种兴奋驱使之下，他们往往会热 血沸腾，得意忘形。什么讨论需求的会议，什么签约仪式、什么需求文件，统统都会被他们扔 在一边。对付这种人最简单办法就是对他说：“喂，先生，你的想法不错，但是由于它不在需求 文件之中，我想先做一个变动后的进度和成本估计，然后我们再决定是立刻就采用这个想法还 是以后再说”。“时间进度”和“成本”这两个词往往比咖啡和泼冷水更管用，这样说，往往会 把许多“立刻采用”变成“最好采用”。

如果你的组织机构还没有认识到需求分析的重要性，那么就请引述本章前面“进行创建活 动前满足先决条件的安全和必要论据”一节的内容，告诉他们，在需求阶段变更设计是成本最 低的办法。

建立一套更改控制过程

如果雇员们坚持更改的热情高涨，则可以考虑建立一个审查这种更改建议的正式委员会。

用户改变主意，意识到他们的软件需要更强的功能是非常正常的。但如果他们频繁地改变主意 以至于你无法跟上他们的速度，那就不正常了。这时如果拥有一套控制更改的正式过程，那将 使大家都会感到宽慰。你感到宽慰是因为现在你只在特定的时候处理变动问题。顾客也感到宽 慰是因为有专门机构处理他们的意见，会使他们感到自己倍受重视。

用开发的方法来容纳变动

一些开发方法可以极大地扩展你应付变更需求的能力。原型化开发的方法可能帮助你在 全力以赴投入工作以前，首先了解系统的需求。渐进开发的方法是指按阶段公布系统。每次你 只做一点儿，从用户那里得到一些反馈后，你再做一些调整的改动，然后再增加一些内容。这 种方法的关键是使用短周期开发方法，以便你对顾客的需求变更迅速作出反应。

放弃项目

如果需求特别稀奇古怪或者反复无常，上面那些办法全都不起作用，那就放弃这个项目。

即使你并不能真正地砍掉这个项目，你也可以考虑一下这样做会怎么样。考虑在你砍掉这个项 目之前，事情会发展到什么地步。假如在某一情况下，的确可以把这个项目扔进垃圾箱，那么 还可以考虑一下有或没有这个项目会造成什么区别。

3.3.4 检查表

需求

这个需求检查表包含一系列关于你的项目需求的自测题。本书并没有论及如何提出一份 好的需求文件，这个检查表也同样没有。但用这个检查表，你可以检验一下在创建工作时，你 的工作基础是否牢固可靠。

并不是表中所列出的每一个问题都适用于你的项目。如果你正在从事一个非正式项目，你 会发现根本不需要考虑这个问题，你也会在其中发现一些需要考虑但并不需要回答的问题。但 如果你正在从事一个大型的正式项目，我们建议你最好还是仔细考虑每一个问题。

需求内容

・ 系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？

・ 系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？

・ 所有的报告格式都定义了吗？

・ 所有的硬件与软件接口都定义了吗？

・ 所有的通信界面都定义了吗？包括握手、错误检查以及通信约定？

・ 是否从用户的观点出发，定义了所有必要操作的反应时间？

・ 是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？

・ 是否对用户所要求完成的任务都作出了规定？

・ 每项任务所需用到和产生的数据都规定了吗？

・ 规定保密级别了吗？

・ 规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误 测试和恢复策略。

・ 规定所需最大内存了吗？

・ 所需最大存储容量规定了吗？

・ 对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的 接口等方面变化的适应能力规定了吗？

・ 是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折 衷？

・ 是否制定了系统成败的标准？

关于需求的完善性

・ 在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？

・ 需求定义是否已经完善到了可以成为软件标准的地步？

・ 需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和 用户才加进来的内容？

关于需求的质量

・ 需求是否是用用户的语言制定的？用户也这样认为吗？

・ 需求中是否每一条之间都尽量避免冲突？

・ 需求中是否注意了避免规定设计工作？

・ 需求在详细程度方面是否保持了一致性；有没有应该更详细些的需求？有没有应该更 简略些的？

・ 需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？

・ 是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？

・ 是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满 足需求？

・ 是否对可能的改动作出了规定？包括每一改动的可能性？

关于需求定义的进一步阅读

以下是一些给出了如何进行需求定义的书：

以下是一些给出了如何进行需求定义的书：