RUP：通过用例应用需求管理(上) 软件测试
如果您对需求管理一无所知或者一知半解，但有志于改进需求过程，那么本文将为您提供一个框架，您可以利用它开发自己的方案。
用例和软件需求规约 (SRS)
为了让读者更好地理解需求管理工作流程，作者从 Rational Software 的 Unified Process 以及工业标准统一建模语言特地挑选了一些文档类型和需求管理工件予以说明。Unified Process 和统一建模语言都推荐使用一种用例驱动的软件工程流程。
因此，本文描述了一种用于指定软件需求的用例驱动方案。这些工作流程还可代替用例模型和用例，或作为它们的补充，与更传统的软件需求规约(如 IEEE 标准)一起使用。
流程时代的软件和系统开发
对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪 90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重建的的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。
既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢?即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢?随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量?
像往常一样，答案就在于该行业的人员、工具和流程。需求管理通常在软件开发出现问题时作为解决方案提出来，但对于这门学科的改进则较少关注。
本文介绍有效需求管理流程的元素，特别强调成功实施需求管理所面临的障碍。
需求管理除了应用于纯软件项目以外，同样也应用于软件只占最终结果的一部分或根本不包括在内的项目。为方便起见，本文以后将使用“系统”这个词来指代任何或所有这些项目。然而，正是软件开发的抽象本质本身，或者和硬件一起，使需求管理复杂化了，因此本文的重点在于软件开发。
为什么要管理需求?
简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。
以下最近收集的证据很有说服力：
Standish Group 从 1994 年到 1997 年的 CHAOS Reports 证实，导致项目失败的最重要的原因与需求有关。[1]
1997 年 12 月，Computer Industry Daily 报导了 Sequent Computer Systems 公司的一项研究，该公司对美国和英国 500 名 IT 经理作调查后发现，百分之七十六的受访者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败的原因就是“变更用户需求”。[2]
为什么要管理需求?避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。
什么是需求?
理解需求管理的第一步就是对什么是需求管理达成共识。Rational 把需求定义为“(正在构建的)系统必须符合的条件或具备的功能”。电气和电子工程师学会使用的定义与此类似。
著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件：
“软件需求可定义为：
文章来源于领测软件测试网 https://www.ltesting.net/