vern@2006-12-06:/var% ls tags

或许我们不应该“写”需求

h4. 摘要

在本专栏里, David Gelperin提出了一个我们很多人都熟悉的问题——记录需求最好的办法是什么?本文阐述了静态模板的局限性,那么我们怎么能更好地管理一些更大量的、多维的需求信息呢?

 

h4. David Gelperin

我们计划开发一个项目,我正在考虑过去的项目中开发需求的方法。我们通常的做法是创建一个需求文档,但这一次这可能不是最好的办法。

对于我们过去的较小的项目,使用文档管理需求效果很好,通过二、三十页纸需求能够被详细说明。我们在本单位或者网上可以获得很多模板,这些模板为需求文档的不同信息提供了编辑样式,然而,文档的效力却无法准确衡量。

大型文档检查和使用都是有困难的。 因为文档的组织形式是固定的,作者必须选择简单的最好的方法组织信息。不幸的是,对于大量的信息,没有简单的、最好的方法甚至是较好的方法。同样的需求信息用不同的方式来组织以满足不同的需要,包括满足正确性和完整性校核的需要。随着需求页数的增加和 涉众数量的增加,以一种可以改变的而不是固定的、组织好的方式―即:使用数据库的需要逐步增长。

例如,我的妻子 Sharon和我最近为儿子的婚礼建立了一份客人名单。我们曾用过的字处理工具,当名单上只有二、三十人的时候工作的很好。由于邀请了大约 130人,我就使用了一个电子制表软件来管理,除姓名、地址和关系信息之外,我们还输入了回复和饮食偏好信息。电子制表软件的分类功能使我能够很容易测算出 (1)选择蔬菜类用餐、鱼类用餐和肉类用餐的人数;(2) 外地宾客以及他们从何处来。电子制表软件的计算功能为我提供了一个重要的导出数据:接待的总数。

当我用关系排序的时候,我注意到计划邀请的一些堂兄不在单子上。虽然这些遗漏的堂兄从按字母排序的名单中能被检查出来,但用关系来做分类排序使得检查这种遗漏容易得多。

需求信息也需要以不同的方式进行聚合。例如包括 (1)所有的关键需求, (2) 来自某个涉众的所有需求,(3) 所有未完成的需求,(4) 所有的接口需求。更大量的、多维需求信息最好应该用能计算、能查询、能重组的工具来管理。

计算能力支持导出信息。例如,允许从测试 到源需求的直接链接,允许从源需求信息到测试链接。这显著提高了对于频繁变更的链接信息的多种组织方式的可管理能力。

既然规模较大的需求应该使用电子制表软件或数据库来开发,我现在必须决定使用文档还是数据库能更好地服务于我们的项目。

我通常把电子表格软件看作是功能受限的数据库(有超强计算能力)。他们之间的如何选择应该主要考虑需求的规模。如果要处理带有数十个属性的需求信息,电子制表软件也变得 文档一样难于使用。因此我们在工具的使用上大致可以这样分工:文档和数据库分别负责需求规模小的和规模大的、电子制表软件用来处理中等规模的需求信息。你是如何考虑的?我非常想听听你用什么工具、是怎么考虑的?

h4. 读者评论

Erik Petersen **

David,你曾提到过敏捷软件开发的问题,很显然我们在这讨论的很多系统需求是有关数量很大的信息需求的,不包含把需求写在索引卡片上和 Alistair Cockburn的"两人在白板前讨论"这类敏捷开发方法。如果你用敏捷开发方法开展这些大项目,那种一小步小步的做法,对于处理大系统本身具有的复杂性,很可能是完全不够的。似乎没人提到由于市场压力和其他原因,要求软件的信息能够 被自由地传递,需求的状态需要随时被了解.... 从我了解的情况看,还没有工具能解决这个问题。Paul Gerrard在这方面已经做了很多工作

Malcolm Stenning **

David,如您所知( 我来自 RESG, University College London, Oct-2002), 过去几年我一直在研究用于获取需求的分级事件驱动用例建模技术。尽可能的,每个需求都使用基于特定业务情形有明确目的的、详细描述目标如何满足的、不包含 解决方案的用例。我发现使用分级方法,使对大量的需求信息的可管理性明显加强。对我来说,做出使用数据库还是文档的决定是非常简单的,每次都选择了数据 库,如果你需要所有的或部分需求的拷贝,你简单地运行一下查询,就会产生相应的报告。当你设计数据库结构的时候,你可以把支持你要使用的查询的必不可少的 属性加进去。我接触过很多需求数据库,包括上边很多人的回复里提到的Rational公司的产品,然而我主要使用 Telelogic DOORS,我极力推荐这个工具。然而,不管你决定使用的管理需求信息的工具是哪一种,文档还是数据库,对于开发的成功最重要的因素是写高质量的需求。关于这个主题有一本很有用的书,是由 SuzanneJames Robertson 编著的《掌握需求过程》(Mastering the Requirements Process)(ISBN 0-201-36046-2)(编注:此书中译本已经由人民邮电出版社出版,译者为 UMLChina讨论 组长Sealw),一本非常好的书,祝你好运。 (10/11/02 )

Robert E. Lee**

关于需求的生命周期和载体的讨论,这段时期以来似乎是硕果累累。(10/11/02 )

Judy Murphy**

我花费数年时间为航天项目开发了数千条需求。我们有大量的资料和许多需求文档。所有这些资料都是被手工创建和管理的——包括跟踪。据我所知在我离开航天项目之前都是这么做的。在商业的领域里我发现的一些事情令我感到恐怖。竟然能够忽略需求文档,忽略需求!我现在只用 Rational RequistePro工作,我喜欢这个工具,它支持创建需求文档,也可以把需求信息存储在数据库中。其情形是,在数据库中需求能够进行分类、过滤,能够生成报告。然而,需求组织的真正的不足之处在于创建"好"的需求,不是注重形式,而是内容本身。如果需求疏于管理,那你的需求在哪存放就没有什么差别了。以电子制表软件管理的质量很差的需求是有害的,使用数据库、文档还是其他工具也是一样。 (10/10/02 )

专家回复―David Gelperin

Judy,你说内容的质量比数量和包装重要的多,显然这是对的。如果在数量少的文档形式的好需求和数量大的数据库形式的劣质的需求之间选择,根本无须选择。 (10/10/02 )

Joseph Dubowski**

这儿的观点都很好。我根本就不熟悉市场上的需求工具(自动化的),尽管如此,我还是想说,我正在寻找的工具的特点是易于使用、具有可搜索能力(按照David 提出的说法)、跟踪能力,能够进行冗余检查和变更控制。任何自动化的解决方案都会给需求强加一个规范的模式。我认为《竞争工程》(Competitive Engineering )对于使用工具支持写文档,可能是一个有益的技术框架。(10/09/02 )

Mahendra Gupta David, 的确,庞大的需求文档一般来说帮助不大。但是如果我们回顾文档的确切目的,感觉到它规范了开发流程。因此,当一个组织在工程方面逐步成熟的时候,这些需求 文档也需要基于所从事项目的类型进行复查和校订。因此文档可以基于相关项目类型分类。影响文档效果的另一个因素是将要使用文档的最终用户对这些文档的理解 程度。因此基于最终用户反馈信息起草文档时应该更及时,当用户需求需要改变的时候应该总是反映到需求文档中。只有当人们坚持这些原则,并共享同一个文档视 图的时候,文档质量才能得到保证。(10/08/02 )

专家回复―David Gelperin

Mahendra:目前我正在阅读Alistair Cockburn 编著的《敏捷软件开发》"Agile Software

Development "一 书。和往常一样他写得漂亮,讲述了很多重要的内容。如果你不熟悉敏捷开发方面的理论,我向你推荐这本书。可能你会发现对其中的一些理论很难接受,但是我认 为这个理论应该从更广的角度来理解。我的上述建议主要是针对你"文档的目的是规范开发流程"的观点而提出的,敏捷开发理论与你这些意见是不一致的。敏捷开 发理论者会说文档减慢了开发进度。最重要的问题应该被研究和讨论,给文档以适当的角色定位就是这样一个问题。感谢你提出的意见。( 10/10/02)

April Anderson**

最近我们用Access数据库(自定义的、曾用于其他项目)来管理需求,并使用 Word的合并功能把需求的文本内容输出到Word 文档模板中。一旦需求库建立起来,由开发人员进行一些配置,进行需求更新和复查还是很不错的。使用中存在多用户访问同一个数据库受限制的问题,我们采用 Microsoft的共享功能来帮助消除这个问题,但是当进行大量数据更新或创建新表的时候,数据库仍然需要被加锁。另一个限制是版本控制。我们也在 bug跟踪工具中跟踪需求变更,这个工具允许我们一直跟踪到更新输出的文档,这对于需求文档进行版本标识是有用的。 (10/08/02)

专家回复―David Gelperin

谢谢你,让我们分享你的经验的细节之处。 (10/10/02 )

John Daughety**

在我工作的几个公司里,工作中我一直忍受者冗长的、令人痛苦的文档的折磨,就没变过样,我一直在考虑如何解决需求文档化的问题。当我最终决定选择数据库,当时间紧张时选用带超链接 EXCEL的时候,我感到对我最重要的是文档化什么内容。许多需求文档化的成果成了巨大的、蚕食时间的怪物,因为需求从没有被反复推敲过。在我最后的公司里我们正在定义支持 DWDM光纤网络设备的产品的特征需求。最终我们形成了数千个需求,通过使用access 数 据库它们被很好地组织起来,但也产生了一些问题,其中许多需求对我们的应用系统来说太详细了,从没被使用过。其余的公司认为搞清楚所有的需求信息将花掉开 发计划阶段所有的时间,后来,这些产品因为没有满足真正的需求不得不进行了一些重大改变。当我回顾这些的时候,我感到现在DWDM 设备的5页长度的 Powerpoint需求图表是非常有效的。对于作为建立项目需求文档的有效媒介,我会对图表投上一票。应该先看看什么内容需要建立文档,然后选择最适宜的方法建立文档。我的 8级英语教师在我们正开始考试时说的那样,"写所有需要写的内容,只写需要写的内容。"在我目睹的太多的案例中,是把需求本身作为目标的,而不是为了需求开发过程运作得更好而使用哪个工具。 把需求移到数据库格式的一个危险是建立更多的资料变得比较容易,创建更多的而非对用户有用的信息的风险变得更大。我敢打赌,当你写参加婚 礼客人名单的时候,在你的头脑里你已经有了"需求"如何支持你的"项目"的想法,婚礼一定是成功的、毫无麻烦的婚礼。在我最近的项目里,没人对建立需求文 档感兴趣,我是把最少限度的时间花费在如此"奢侈"的工作上的唯一的测试者。我使用数据库,开始写我认为需要写的内容,这项工作是我们的产品必然会取得成 功的五个因素之一。然后我把这些信息与选定的项目组的成员共同分享,从中再分析出哪些部分还有更多的信息被需要,采用这种迭代的方法建立需求,最终我建立了规模较小但很全面的需求数据集。采用这样的方法,数据库是理想的媒体。 (10/08/02)

专家回复―David Gelperin

想法非常好。你提供了这么多观点,下面我打算把它们总结一下,请直接指出我的误解或者多余的部分:1为了开发真正正确的需求,要依据合理的判断,集中精力研究项目的目标与任务。2) 需求太多可能比需求太少效果还要差。3一些需求信息最好使用图表来表述;4 采用数据库方法引进过多却不是必不可少的需求信息可能是危险的; 5从另一个角度看,数据库的组织方式能够使大量的信息变得条理清晰、便于复查,利于验证正在开发的需求。 (10/10/02 )

ofer prat

Hi.在市场上有一些需求管理工具(e.g. Calibar RM).哪位有这些工具的经验吗? ( 10/08/02)

专家回复―David Gelperin

Ofer prat问过,"市场上有一些需求管理工具(比如, Caliber RM),哪位有这些工具的使用经验吗?"我无法设想不使用需求工具怎么来做需求分析。我们公司正在评估 CaliberRMRational RequisitePro 。我非常喜欢CaliberRM ,它允许我定义需求,显示它与其他需求的关系,为需求创建属性,以Word 形式打印精美的报告。我给你举个例子:在先前的公司,我们评估差别很大的两个程序,对我们考察的每个需求,我给它设定一个数值作为属性,如果这个程序能完全满足该需求,设定值为"2 ",如果这个程序能部分满足该需求,设定值为"1 ",如果这个程序不能满足该需求,设定值为"0 "。然后我把所有这些需求的值加起来,打印一个报告,给出每个程序的最后得分,也列出分值为"0"的需求项。 (10/08/02 )

Peter Cornish**

David把我们引到了这个主题上。当需求变得有点复杂的时候,就有许多其他相关的变化趋势问题应当考虑: 1) 需求变更的增长率; 2) 已审定的变更增长的数目。这两个问题都影响我们采取什么解决方案。只要我能支付得起购买、维护、培训的费用!( 10/08/02)

Laura Murphy**

从文档升级到电子表格软件,再升级到数据库,你的选择过程是对的。当我们的公司太小而不能发挥工具的威力的时候,我们曾试图使用RationalRequisite Pro那样功能强大的需求管理工具。如果你的项目和你的项目组太小,创建并维护一个需求数据库所付出的劳动与项目的预算和时限是不成比例的。除非所有项目都要求使用数据库,否则是不值得的。我们降低要求直接使用 word处 理文档,感觉到在我们的公司规范和项目的约束下工作的很好。现在我们公司规模变大了,如你所说,在进行充分的需求跟踪,横向参考不同类型的需求文档方面, 文档已经不够用了。我们现在已升级到具有链接、文档交叉参考功能的电子制表软件。这是需要使用需求数据库并采用其文档模板支持的先兆。我认为我们最终会由 于项目规模过大而超出电子制表软件的能力,而不得不使用需求管理软件。然而,基于经验,我确信必须使用与你的项目和项目组规模成比例的存储方法。过于强调工具将损害你的产品和利润。不使用工具也可以产生同样的结果。窍门是所用工具的层次与你的开发项目的层次相匹配。 (10/08/02)

Clay Givens**

这是一个关于需求管理和不断变更的大型文档的有趣的专栏。我一直认为管理随意建立的厚厚的需求文档犹如噩梦。以我的经验看,100 页以上的word格 式的测试需求文档使用起来将是非常耗时的,在这方面已经超过了它所能带来的好处。还有个问题就是小的需求调整修订经常发生。文档维护简直就如同家务杂事。 我天性懒惰,因此我喜欢依靠直觉来执行我的很多测试内容,但不全是这样的,我也采用电子制表软件作为要求详细测试内容的管理工具。每一个测试用例都有三个 文本栏目:一是"一般步骤"栏,包括基本的测试步骤;二是"特别步骤"栏,为区别于其他用例的部分;三是"预期结果"栏,便于使用者理解需求的信息。这样 做,我就不至于只关注了小树而忽略了整个森林。目前我正在为一个很复杂的应用系统写测试用例和需求,这个系统包括三个数据库的集成和三个不同平台下用户认证会话转换。测试场景包含许多内容,测试是复杂的,相关资料很容易丢失,为此我使用 excel来管理需求。相比对于数据库,我发现在没有建立图形界面的情况下,使用数据库太慢而无法进行手工更新,那将花费很多时间。我唯一的使用数据库的时机是把它作为自动化工具的一部分。我成功地使用 MySQL作为后台数据存储器,自动化的前端工具为results capturingmedium(SilkTest and PHP)。我仍然认为对于我工作的敏捷应用开发类型的开发环境,带有基本功能以及拆分功能(数据库规范化)的电子制表软件,是管理需求的最好解决方案。 (10/08/02 )

Andrew Raybould**

David,当任何信息的数量太大而不能看一看就基本了解的时候,就需要被组织起来。在某些情形中电子制表软件是比较合适的工具。但我发现超 链接很有 效,特别是对于需求的跟踪能力(包括设计和实现)、对于捕捉需求的依赖性和其他关系。一般来说,图表能够解决文本方式存在的单一化的缺点,图表对于阐述关 系是一个好办法,但单纯的图表形式缺乏表现力、充分的说明和自然语言的推理能力(除非你用逻辑判断图)。单纯的图表形式的需求说明(或设计说明)几乎可以 肯定是不全面的。最后一点,当然如果你的问题需要大量的严密逻辑,应该使用严格的数学方法。(10/08/02 )

Sam Shober**

我认为,这篇文章将为以可视化的形式显示需求信息提出一个可行的方法,或者是为需求文档化提出一 种通用方法。我认为使用电子制表软件或者是关系型数据库的观点是明智的。任何时候,如果你需要对包含多个子系统和它们的边界的系统建立功能文档的时候,都 应该小心谨慎。通过对实体间的关系进行研究,你能较早地理清相关问题。你也能更全面地评估这个项目,你和开发人员能更准确地估算带有所有这些新功能的系统 上市将花费的时间。 这种形式的文档还有两个缺点: (1) 设计并维护一个传统的文档可能需要花费大量的时间; (2) 你仍然需要挑选一种格式,把需求内容上会展示讨论,因为你可能还没有完全掌握客户方的真正需求。( 10/08/02)

Daniel SUCIU**

David的问题的答案对我来说似乎是显而易见的:采用需求管理工具,关键是"管理"。我认为比较好的做法是在项目生命周期的需求开发阶段就描述出所有的业务活动。工具能够解决 David提到的所有问题(从不同的角度进行查询、为不同的目的采用不同的格式 /模 板,计算能力),特别是与其他工具并行工作,进行版本控制、变更管理、设计、自动测试。无论如何,甚至是单独使用,一个需求管理工具结合了数据库的优点和 字处理器的性能,有友好的用户界面,带有内部逻辑,包含需求管理必不可少的规则,工具能够进行自定义,以满足特定的环境、业务规则甚至模板。据我所知,这 样的工具有许多,但我唯一熟悉的是Rational公司的产品,它包含用于需求管理的 RequisitePro。 事实上,使用特定模板、电子制表软件和数据库,都带有特定的查询,带有特定的业务规则,在每个组织中,这也是任何需求工具的核心功能,但是他们没有(或比 较少)自动化功能和友好的用户界面。唯一的问题可能是购买工具的花费。如果对于规模大、预算大的项目,可以支付得起自动化工具的相关费用。对于较小的项目 支出可能要受到控制。我希望在不远的将来,有更多的这类工具可供选择,花费很低甚至是免费的,许多缺陷跟踪工具,自动化似乎是比需求管理更远的一步。我不是说需求管理工具将永远代替技术专家(某些人认为的那样)。它只能帮助她 /他组织数据,使其集中精力于重要的问题。( 10/08/02)

Hans Thelosen**

管 理需求与发布需求是不同的,我喜欢以文档形式发布需求(容易使用)。然而如果你管理需求(创建、改变、讨论、推迟),这是操作需求相关属性的问题。这种情 形下选择使用文档是错误的。那么为什么不用一个知识库呢?一些工具能够用作知识库来管理需求,并能在完成需求时生成文档。( 10/08/02)

sameer nigam

你认为在Designer中使用业务过程模型( Business Process Model 和业务功能模型(Business Function Model)对获取有用的需求有帮助吗? (10/08/02 )

Alberto López Navarro**

我感觉这个专栏很有意思。我在一个规模相当大的电信公司工作,公司项目涉及的范围很广,必须按职能区域分成多个部分设置不同的组织分别定义和实现。当所有的相关人员不得不象鱼儿觅食般在整个文档中(尽管只有一小部分与他们的领域有关)寻找需求时,是非常麻烦的事情。这个议题的讨论结果可能是微不足道的,似乎这只是技术 /工具及其提供的数据处理能力的问题,但是我认为这样简单的改变很可能对软件生产力产生很大的、值得关注的影响。 (10/08/02)

Fiona Williams**

我不得不说对于写需求(或其他任何文档)我曾经得到的最好的帮助来自于一门信息规划课程。它真正集中说明了写需求的办法,它使文档易于快速阅读,文档被设计得能快速浏览,因此查找需要的信息时快得难以置信。我非常想推荐这种方法,关于这种方法的和步骤的更多信息请参阅: :http://www.infomap.com/(10/08/02 )

Sandy Flann**

我曾看到的最好的需求模板来自于RUP。每一项内容都被分别编号并分类管理。但这仍然是一个"文本"文档,从中我也能看到使用电子制表软件可能存在的问题。 (10/07/02 )

Kevin Priest**

不管是使用字处理器、电子制表软件,还是数据库,最终都是在"写"需求。基于这个专栏题目,我有一个提议——"画"需求("drawing" requirements ),即采用图形化的而不是文本的需求表述方式。在费力地读完数页描述应用的模式间转换的需求说明之后,绘制一个状态转换图将大大地简化需求,并且通常会暴露出一些矛盾和错误。作为一个测试者,你多少次通过绘图阐明了叙述性的文字说明?有多少次你发现了开发者在做同样的事情?更重要地是,你的图形多少次满足了开发者的需要?我喜欢的需求描述工具不是字处理器、电子制表软件,也不是数据库,而是绘图工具。任何类型的绘图工具,必要的时候也包括纸和铅笔。当然一些表示语言(比如:数据流一致性检验)的知识有助于使用工具,但即使没有它,图形也比单纯叙述性的语言强得多 !(10/07/02 )

专家回复―David Gelperin

Kevin:我本应该提到图表 ( 状态转换图、行为图和基本类图) ,对于展示需求信息的外部形式来说,它们是最好的方法。但是就你所知道的,既然没有最好的需求规格说明方法,它们也不是最好的方法。比如,在概要层,绝大多数的非功能性需求需要叙述性的文本描述。 在细节层,通过接收外部信息/系统测试过程,能被最好地阐释。另一个例子是复合状态的细节定义,例如:客户必须符合某 一特别类 型的保险单的条件,"条件"是由包含客户的多个基本状态的逻辑表达式定义的复合状态。这个保险单可能被诸如年龄、性别、婚姻状况、住宅所有权等因素的某种 组合所限定。对于说明逻辑表达式,图表不是有效的方法,叙述性文本也不是,因此我们使用数学方法。有效的需求说明方法要求实施一个不同的策略,为每一种不 同类型的需求信息找到一种最清楚明了的表达方法。也就是说,我们都有我们喜欢的工具。 感谢你参与讨论。 (10/10/02)

Gene Fellner**

以平面文件记录一个上百万美元的需求,就制鞋商本人却打着赤脚走路一样。( 10/07/02)

Chris DeNardis**

首先我对这个标题感到非常奇怪,为什么叫"或许我们不应该写需求"呢?或许这个标题应该被改成"获取需求的多种方法"或其他什么。在一篇文章里你说的那样,需求是本已存在的,然而用于建立文档的工具会有所不同, EXCEL不同于WORD ,或许甚至power point更多的作为概念图来概略说明需求。我们的做法是用 Word作为需求文档的主体,但是在WORD 里边有图表——有时一些内嵌的EXCEL工作表,有时是图片,来自于 Visio 或者Powerpoint 。当我们进行测试的时候,这些文档被用来检验需求,同时通过运行已提供的相关的、已校核并得到审批的测试用例来测试。( 10/07/02)

专家回复―David Gelperin

谢谢你又提出了记录需求的另一种选择。我们可以用 (1)字处理器, (2) 电子制表软件, (3) 你提到的多种组合 ,(4)数据库; (5)需求管理平台( 可以看作是浓缩的数据库)(10/10/02)

专家简介

David Gelperin ( sqegelp@aol.com) 是位于佛罗里达橙色公园大街的软件质量工程协会(sqe.com) 的创始人之一 David 在软件工程方面有30 年以上的经验,重点关注了软件质量控制。他曾担任的角色有程序员、项目主管,测试主管、质量监控经理、测试咨询和讲师。他主持制定了ANSIIEEE两个组织的软件测试标准,推动了《软件测试与质量控制》( Software Test and Quality Engineering magazine)期刊的创立。他在俄亥俄州大学 Carleton 学院读完了数学专业之后,又继续深造获得了计算机科学专业的硕士和博士学位。