关于DOORS 的常见问题

    这是对我们经常被问到的需求管理问题的背景知识。无论你是否是DOORS的用户，我们都希望能够对您有所帮助。DOORS 是世界领先的需求工具，它采用最新的技术来组织与展示信息，可以使你能够控制机构中的大量信息。本文解释了需求背后的概念以及DOORS 处理需求的方法。为什么需求对质量很重要？用 Crosby 的话说，“质量是与需求保持一致”。 Juranii 对质量的定义是“符合目的”，也是类似的说法。为了建造高质量的系统，我们首先必须定义需求，然后使开发来满足需求。无论我们处于什么角色－－经理、最终用户或专家
－－我们都要发出需求或接受需求。需求不仅仅是对技术人员很重要，对其他人也很重要，需求工具也必须使管理人员与系统工程师能够使用。Standish 集团的分析显示，无效的需求管理是项目失败的最主要的原因。一半以上的项目失败原因是与需求相关的。同样的研究显示，好的需求管理是项目成功的关键。需求采用非技术术语的方式来定义问题，说明每个人在项目中要做的工作，使个人就可以了解自己的工作背景。用户需求以用户的视点来表达系统，软件或系统需求使用系统语言来表述系统－－这是抽象定义问题的第一步。需求也适用于开发、验证和所制造的产品。系统必须遵守公司与法律规范，同时项目也受时间和资金的约束。需求是验收所交付系统的基础，验收试验也必须基于这些需求。所以试验的质量取决于需求的质量。缺乏好的需求，我们就无法确信系统是否已经完成。在项目中（特别是在渐进式的设计周期中），需求要被逐个审核。管理人员通过需求的状态来了解当前的状态与未来的计划。

项目为什么会失败
1 不完整的项目需求 13.1%
2 缺乏用户参与 12.4%
3 缺乏资源 10.6%
4 不现实的期望 9.9%
5 缺乏管理层的支持 9.3%
6 变更需求 8.7%
7 缺乏计划 8.1%
8 不再需要了 7.5%
16% 成功
31% 部分成功
53% 失败
很低的成功率
平均成本超预算 89％
平均时间超出 122％
计划是不现实的，所以就不必做计划
不必了，谢谢
45％的从未被使用过
失败的项目用掉了$810亿
超出预算 $590亿
实实在在的资金
问题的实质
50％ 与需求相关
30％ 与管理相关

结构化需求的优点是什么？

    结构化是组织复杂信息的最好方式，以使这些信息便于管理与学习。缺乏结构，我们就很难发现遗漏与重复。当我们对结构化系统的一部分有了了解之后，我们就会对整个系统产生概念。如果系统缺乏结构，我们就必须死记硬背或由于无法了解而干脆放弃。结构化的系统很容易升级、测试与可视化。它们通常也很紧凑，因为清晰的视图有利于在系统中重复使用组件。用户需求与系统需求的区别是什么？在许多开发中常常混淆用户与系统需求。分析人员过分重视定义系统功能以至于忽略用户的想法。系统需求定义抽象的解决方案，而用户需求定义问题或系
统对用户产生的结果。用户应该拥有用户需求并且应该使用他们能够理解的语言来描述。分析人员生成系统需求，它是对用户需求的直接响应。定义问题与解决方案需要不同的组织。如果混在了一起就会混淆用户与开发人员的需求。无法区分相应的责任。
    约束（非功能需求）也具有同样的特点。用户有非功能需求，如他们所要使用的系统的交付时间。在软件需求阶段，其它约束来源于专业领域如安全、可靠性或开发标准。DOORS 能够使你在功能与约束之间建立关联。假想你去购买汽车，他们向你展示带有数据与控制流程的功能框图与性能特点，你会因此而购买吗？当然不会 －－你希望他们能以你所能够理解的方式来向你介绍产品－－车速多快、舒适性、花销、安全性等。这些才是用户需求。

我的用户从不提供结构化的需求

    用户不必提供结构化的需求。但用户必须“拥有”用户需求，并会帮助你生成一致的需求集合。你可以根据他们的描述文档来建立结构化的需求并形成完整的可跟踪性。然后以他们能够理解的方式向他们展示文档中的内容。我的项目很紧，没有时间来做需求经验表明最快的做事方式是以恰当的方式去做――不要有“如果”，不要有“但是”等意外情况发生。世上有两种类型的经理，第一类经理相信无需需求就可以把事情做好。第一类经理知道需求只会占用很少的资源与时间，没有需求就无从度量项目的进展。经历了一些失败的项目后，很多第一类经理都转变为第二类经理了。

有背后的方法论吗?

    不像其它工具，DOORS 不会对你的工作强加一种预先定义的方法论，它采用标准的方法。如果你喜欢，你也可以使用它们（如ESA 的 PSS-05）。DOORS使用了用于组织信息的所有基本原理。这有助于分层、结构化、抽象、可跟踪地来管理信息。这使得DOORS 可以清晰地分析信息。这些原理是系统或软件开发的基础。这些组织信息的基本原理可以用于任何种类的结构化方法。

    DOORS 最初是建立在欧洲航天局软件工程标准（ESA 的 PSS-05）的框架之上的。这是欧洲最通用的标准，被成千上万的软件工程师所采用。这个标准覆盖了整个的软件生命周期。它指导工程师必须做什么而不是指挥他们怎样去做。

    DOORS 提供ESA 的标准模板，并可以直接实施PSS－05 标准。Telelogic 参与了几个系统工程标准化组织的工作。
采用传统系统工程的经验，这些软件工程标准已经被扩展到系统工程领域。
使DOORS 适用于你的机构的方法很简单――使用DXL 脚本语言来改变模板，这也就是几分钟的事。编写模板就如同写文章的目录。需求适用于项目的所有领域，项目的状态必须能够被经理所监视。

DOORS 适用于哪些客户?

    DOORS 是第一个为经理与系统工程师而不仅仅是技术专家所设计的可以直接使用的需求工具。DOORS 支持“客户角色”，例如，生成需求，检查输出与需求的一致性，在整个生命周期中监视进展。通常来讲，需求一般受控于理解需求方法的一个小组，并由他们集中管理。相对很少的一部分人会频繁接触需求，很大的一部分经理与系统工程师则希望能够查阅整个需求。DOORS 允许将需求分区管理，由不同的小组来控制。例如，产品质量保证部门可以控制需求的约束部分，而用户小组则可以管理用户需求
DOORS 是为应用于项目的初期而设计的工具。它可以帮助用户生成高质量的、结构化且无歧异的需求文档。它是第一个以客户的角度来恰当组织需求并覆盖整个生命周期的工具。其它的工具都是以开发商的角度关注可跟踪性问题。技术人员也许可以处理关系数据库的报表，但是管理人员则需要实时的在线信息。DOORS 提供的高质量且易用的展示功能使需求更容易被管理。有些工具来源于只关心可跟踪性的合法性的开发商。他们所假设的是从客户哪里收到的是没有定义好的需求，而他们的工作只是把需求与CASE 工具建立简单的链接。这种工具所依赖的方法论与质量毫无关系。

    DOORS 的不同之处是，它是为整个生命周期而设计的，可跟踪性只是其中的一部分。当使用DOORS 时，开发商无需重新构造没有定义好的需求。这可以节省大量的时间，更重要的是，用户需求可以被恰当地表达并评审。这种设计理念为项目中的用户到开发商的需求的顺利交接提供了极大的方便。
因为DOORS 起始于项目的初期，它可以非常好地支持投标过程，为用户和投标单位节省大量的时间。

DOORS 能够帮助解决哪些问题?

DOORS 能帮助你解决以下问题：
　项目缺乏高质量的需求;
　仅从系统设计开始管理;
　无法确定产品的测试依据;
　需要先生产简单的版本，然后逐步增加功能 (迭代开发)
　需要根据费用与效益比来评估几种设计方案;
　需要根据费用与变更比来评估变更;
　需要检查是否系统需求与设计满足了用户需求;
　需要把非功能需求与系统功能结合起来;
　需要演示可跟踪性并控制专业领域如软件或集成电路设计。
　需要在不同系统中重用组件 (测试系统,需求,设计单元)