《Designing the Requirements》作者访谈

IT 需求 设计

摘要

在《Designing the Requirements: Building Applications that the User Wants and Needs》一书中，作者Chris Britton开辟了另外一条从理解需求到交付正确解决方案的道路。

正文

本文要点：

• 在本书中，Chris Britton提出了另外一种方法，“构建用户想要且需要的应用程序”；
• 作者建议，许多实现都是败在需求上，尤其是需求识别的方式；
• 一种从其他工程实践引入的层次化设计方法被应用于IT应用程序设计；
• 了解这个模型如何在一个飞速变化的世界里帮助我们处理变化的需求；
• 让业务管理人员和IT应用程序设计人员一起参与到设计工作中。

在《Designing the Requirements: Building Applications that the User Wants and Needs》一书中，作者Chris Britton开辟了另外一条从理解需求到交付正确解决方案的道路。

据Britton介绍，整本书所描述的策略都基于这样一个事实，就是许多IT实现的失败都与需求识别过程有关。他指出，需求应该是源于需求设计工作，而不是需求收集工作。作者详细介绍了一种上下文驱动的设计方法和一种层次化设计方法，它们有助于保证交付的解决方案的一致性和完备性。

InfoQ采访了Chris Britton，详细了解本书所提出的方法以及如何将这些方法应用到现在这个快节奏的世界，让组织可以快速高效地接纳变化。

InfoQ：从问题的角度讲，您为什么要写这本书？

Britton：我认为，对于应用程序设计的话题，我可以提供一些有用的东西。显然，虽然有多年的学习和经验，但许多IT应用软件实施项目都失败了，我觉得我知道为什么。简单来说，原因是IT应用程序的需求应该来自设计工作，而不是需求收集工作。如果你只是简单地收集需求，则很容易错过一些重要的东西或者引入不一致性。许多IT专业人士耸耸肩膀说，“如果是，那也是他们自己的选择”。对此，我首先要说的是，你至少可以告诉他们，如何做才恰当。但是也要知道，修复应用程序设计或实现问题的最佳方式是改变业务人员使用应用程序的方式。将整个业务/IT应用程序作为单个的设计问题为你提供了处理这类反馈的框架。最后要注意——即使你完全按照业务人员的要求进行实现，他们还是会把失败的责任推到你身上。

InfoQ：这本书是讲设计的，这是一个很宽泛的词。您在这本书中对“设计”做了怎样的定义？

Britton：在这本书里，我将设计定义为“将你希望构建的东西或系统概念化。”这是一个非常笼统的定义，适用于任何设计。它涵盖了许多情况，设计可以是某人头脑中的一个想法，可以是一系列的图纸，或者可以是所设想的最终产品的黏土模型。

显然，本书讲的是IT应用程序设计，但是长期以来，我一直觉得很奇怪，IT设计就应该和其它东西的设计，如设计一座建筑物，有如此大的不同吗？例如，你从来都不会采用增量方式设计一栋房屋；比如说，先设计一堵墙，然后展示给客户，问他们这是否是他们想要的，如果客户对此表示满意，则给客户展示另一堵墙，以此类推。当许多年之前，我开始从事这一行业的时候，我想知道IT设计和“平常”的设计到底有什么不同，为什么会有这样的差别。我首先注意到的是，建筑物或机器的设计是层次化的。层次化可以提供可追溯性——如果某个东西变了或者坏了，你可以沿着层次结构往上走，了解它对设计的其他部分的影响。每一个有经验的程序员都会告诉你，有那么一些情况，当你修改了某个地方，应用程序的其他部分就遭到了破坏，而且完全出乎意料。这让我觉得，也许存在一个我们现在由于某种原因尚未看到的层次结构。对于这样一个复杂的问题，其解决方案是，进一步讨论隐藏在我们下面将要讨论的层次化设计中的答案。

另一个困扰我的问题是，为什么IT设计不是真正的工程设计，工程设计到底是什么。我总结出了三种可以实现我所谓的设计的方法：

1. 临时设计：尚未正式设计——换句话说，设计还在你的头脑中；
2. 计划设计：设计已经绘制或描述出来；
3. 工程设计：设计已经进行了错误分析。在构建某个东西之前的设计阶段，工程师就针对负载、平衡、地震等等因素对设计进行了分析。这让我感到奇怪，我们该如何分析IT应用程序的设计。好处很明显——更好的设计意味着更少的意外和重复工作。

我和工程师及架构师都探讨过设计，这种对设计本质的过度关注在他们看来有些陌生。相反，他们的做事方式都是根深蒂固的。虽然设计方法有许多，但显然，在IT领域并非如此。对于IT应用程序设计，我所做的，可以看成是后退几步，找到一条新的前进路径。

InfoQ：对于应用程序设计，有许多方法可以采用。您能描述下您提出的方法吗？

Britton：我的方法和其它方法的第一个不同点，可以这么说，是业务起点很高。IT应用程序不是存在于真空里；它们必须为业务提供支撑。就我的方法而言，关键是业务流程和服务的设计，IT任务如何为它们提供支撑。这点之所以重要，是因为业务设计在设计层次的顶端，如果不实现此类设计，就无法弄清楚修改设计的后果。

第二点不同是，即使在最上层，我也会同时对“行为（actions）”（如果你愿意，也可以说成是“活动（doing）”）和数据进行描述。尤其是，我希望了解业务人员如何收集和使用数据。这和用例图只专注于行为不同。

第三点不同是，我希望尽早地分析设计，减少设计错误。例如，由于我在业务设计中描述了数据以及行为，所以我可以提出这样的问题——这些数据可以支撑这个流程，而这个流程可以支撑这些数据吗？

还有一个重大的不同点是技术设计的方法。你应该从框架方面考虑技术设计。我认为，你应该尽早构建应用程序的框架，尽早进行破坏性测试。这在复杂的多层环境中尤为重要。我听说过，一些大型项目，在几乎完成的时候才发现，它们在性能方面不达标。还有一些其他的方面，类似安全和弹性，也需要尽早考虑，不要在最后了才突然提出来。

实际上，具体的实现和敏捷开发多少有些相似，但是，你有更高层次的设计方案，并且有方案的设计者作为中间人，而不必和业务管理人员直接打交道。层次较高的设计方案通常不需要花多长时间（除非它因为业务存在问题无法达成一致而陷入停滞）。

InfoQ：您认为，在某些时候，“描述业务人员想要的东西相当复杂”。可以请您介绍一些您用来减轻这项任务的技术吗？

Britton：想象一下，假如你是CEO办公室墙上的一只苍蝇，无意中听到了关于IT应用程序提议的讨论。对于应用程序目标的描述通常会简单明了，如“如果我们这样做，应该可以减少成本”，“我们想要更多地了解我们的客户，那样我们就可以向他们出售更多的服务”，或者“如果我们在线提供这项服务，就很可能在一项新业务中占得先机”。这些愿望的实现很复杂，我在回答前面的问题时已经提到过，复杂性既存在于业务中，也存在于IT应用程序中。换句话说，CEO层的需求是设计层次中最上层的需求。你必须问问相关的干系人，弄清楚CEO层对这个项目的要求。难点在于，如果你问许多管理人员他们想要什么，那么他们会告诉你他们倾向于采用的解决方案（在业务层面），而不是问题，你可能得引导他们描述问题以及解决方案。了解CEO层的需求非常重要，因为当你问另外一名管理人员时，他们很可能会告诉你他们倾向于采用的解决方案，但这个方案可能会与其他管理人员的解决方案冲突。CEO层的需求可以帮助你说服那两名管理人员。

InfoQ：在您的书中，专门有一章介绍“设计的层次结构”。您能分享下有关这个主题的想法吗？

Britton：设计的层次结构是探讨工程师如何完成设计。如果没有设计的层次结构这样一个概念，就很难将设计想象成一艘航空母舰或一座大楼；这是它们应对复杂性的方式。在工程设计的每个层面上，都可以对设计进行错误分析。每项设计的需求都可能是来自外部，但主要还是来自更高层次的设计。例如，在设计一座桥时，柱子的设计要求很大程度上是由桥的高层次设计决定的。中间会有反馈，比如，当你进行柱子设计时，可能会发现，由于地质原因，桥很难建造或者成本很高，你需要回到更高层次的设计上，把桥的位置移一下。层次化设计的概念是一种非常有用的方法，你不禁要问——我们为什么不能把它应用到IT应用程序设计中呢？现在，让我们看下传统的IT应用程序设计。它是“平的”——没有层次，有些隐藏的复杂性很晚才会暴露，这种糟糕的意外会导致项目延期。我意识到，IT应用程序设计不是平的，但缺失了上面的层次，因为它停留在业务设计上，而不是IT应用程序设计。IT应用程序设计的主要问题是，说服业务管理人员参与到设计工作，而不是一厢情愿的思维运动。我发现，这并不容易。在业务管理人员看来，我通常是一个总是在找问题的令人讨厌的家伙。

这就是说，IT应用程序设计不同于传统的工程设计。工程师在使用工程图纸描述高层设计的同时，也使用它描述组件设计及子件设计。我发现，构建IT设计层次的最佳方法是将设计分成不同的层次，每个层次以不同的方式描述问题。如此一来，高层设计——即上下文设计——包含流程和任务图，而用户接口设计则用来描述界面及界面流。数据库设计的成果是数据库模式（或者类似非数据库的持久化数据），而技术设计的成果是框架的可工作代码。这样，上下文设计就转化成了三种设计，每一种展示了整个系统的不同方面。我之所以用整整一章的篇幅来描述层次化设计，其中一个原因是为了说明这种IT应用程序设计方法仍然支持追踪分析。

InfoQ：您为什么认为“用户界面设计可以留到项目后期进行？”

Britton：我知道，这是一个有争议的话题，我应该澄清一下，我所说的是详细的外观设计（颜色、按钮的大小/位置等），而不是确定界面、数据输入和输出、界面流。在理想情况下，可以设计用户界面的功能，但不考虑界面的布局，而在一个Web应用程序项目中，那正是我们想做的。用户界面设计人员拿到Web页面的源代码和我创建的CSS文件，以此为基础开展他们的工作，但不改变应用程序的逻辑。尽管如此，颇具讽刺意味的是，在我最近的一个项目里，用户界面设计人员似乎不懂这种划分，完全从视觉角度看待应用程序，不断地向应用程序添加新特性。

InfoQ：让我们继续谈应用程序设计，您能描述下您所提出的“六盒模型（The Six-Box Model）”吗？

Britton：六盒模型是IT应用程序的层次化设计。最上层是上下文设计，概述了应用程序和业务如何协同。下面一层是集成设计，概述了该应用程序与其他应用程序如何整合。这里所说的集成设计是对应用程序如何整合的逻辑描述，而不是技术描述。之所以要有这个步骤，是因为你可能会发现，你所设计的东西在其他某个地方已经存在了，最好是和已有的集成，而不是从头重新设计。自然地，如果你这样做，就可能会发现，自己需要作出妥协，而这需要反映在上下文设计中。接下来的三种设计会将上下文设计沿着三个维度进行细化：用户界面设计描述输入和输出系统的信息，以及界面如何整合在一起；数据库设计是针对持久化数据（所有持久化数据，而不只是存储在传统数据库中的数据）；技术设计描述使用什么技术以及如何使用。最后就是实现了。

这些设计的目的是说明如何考虑应用程序设计。那些步骤并不是项目所必须的。用户界面设计、数据库设计和技术设计，即使彼此之间存在联系，也或多或少可以并行。在层次化设计模型中，设计过程中的反馈可能会引起高层设计的变化。例如，在技术设计期间，你可能会发现应用程序的实现成本太高，因此，你会重新回到上下文设计，稍微做些修改。

InfoQ：世界发展很快，需求不断变化，随着时间推移，使用什么技术和方法才能保证设计的准确性呢？

Britton：首先，许多需求变更实际上是因为缺少“需求设计”。换句话说，它们是为了修补后来在业务设计中发现的缺陷。有一个经过全面分析的上下文设计应该可以减少这样的变更。

但当然无法完全消除。当你可以从业务设计追踪到代码，从代码追踪到业务功能，变更就容易处理得多了。这在有关需求变更处理的主题中有更详细的讨论。

理论上讲，在项目完成后处理变更的过程和在项目进行过程中并没有什么不同。当然，在实践中，你可能无法再找到关于应用程序的专业技能，丢失了——或者从来没有——上下文设计，无法从业务的角度了解应用程序的功能。因此，你可能不得不去了解一个或多个已有的应用程序，构建一个上下文模型（类似上下文设计，但是针对已有的应用程序）是个不错的起点。

需要强调的一点是，处理变更的技术有助于预防意外的结果。

处理变更的另一个方面是应用程序整体的架构设计。在项目中，之所以要那么早的完成集成设计，其中一个原因就是为了让新应用程序有机会成为应用程序组合的建设性部分。例如，我们希望确保在整个组合中没有不必要的功能重复，同时也希望有一种策略可以确保数据有一个一致的值。

InfoQ：您是如何评估需求变更的影响的？

Britton：六盒模型的一个重要特性是帮你评估变更的影响，因为它让你可以从业务任务跟踪到用户界面，再到数据库字段和记录。例如，如果你希望数据库记录中有一个新字段可以用于管理报告，那样你就可以快速弄清楚，为了输入数据和展示数据，哪个界面需要修改。知道了界面，你就可以确定哪项业务任务可能会受变更影响。如果业务任务受到了影响，那么它是否会引发业务流程的连锁反应。你可以轻松指出变更的结果。一旦变更了设计，针对每种设计的分析技术就可以帮你检查新设计的一致性和完整性。最后，变更范围可以帮助你确定应用程序的哪些部分需要重新测试。

InfoQ：关于设计质量和审核，您有什么想法？您建议检查完整性、一致性和可追溯性。您能分享一些完成这些检查的技术吗？

Britton：关于质量和审核，有大量的文献资料，其中大多数都适应于应用程序实现。除了表示赞成，我几乎没有什么可以补充的。但是我觉得，对于大多数IT应用程序开发人员而言，设计质量是一个陌生的话题。业务流程分析可以保证所有的路径都有一个终点，永远不出现循环。另外，可能还会有业务流程完整性约束。例如，一个处理在线购物和发货的流程会有一个完整性原则，客户只需要为实际交付时状态正常的货物付款。当你考虑了破损、缺货及其他造成混乱的情况时，就很容易发现，这样一个约束并不那么容易实现。上下文设计描述了如何通过任务实现业务流程和服务。任务需要数据——业务应用很大程度上就是存储和使用数据——这就有一个重要的问题——数据来自哪里以及用在哪里？接着又要问——用户是否有输入数据的信息以及如何确保数据的准确性？一项很好的分析技术是考虑安全问题——谁有权查看每一项数据以及数据落入坏人之手会有什么后果？为此，你要考虑不同类型的用户以及每一种用户的操作。从用户的角度来看，有一个问题——在作出决策时，他们是否有决策所需的信息？对于功能性需求，可以做大量的分析，我想我并没有把它们找全。

InfoQ：您提到“借助上下文驱动设计可以更好地理解自己在项目中所处的确切阶段”。您能为我们解释下这是为什么吗？

Britton：有两个原因。一个原因是上下文设计中会检查一致性和完备性。这就是说，降低了你遇到不大量重写就无法解决的问题的可能性。另一个原因是技术设计的方法。前面已经说过，我建议你从框架的角度来考虑技术设计，然后构建框架，并在进行大量的功能实现之前反复对它进行研究。这种方法大大减少了应用程序因为性能或弹性原因而重写的可能性。我发现，测试框架的代码通常可以逐步演化成测试应用程序的代码。

InfoQ：在本书的最后一章，您探讨了应用程序开发的未来。您认为上下文驱动设计对其有什么影响？

Britton：我希望上下文驱动设计的思想成为主流，同时我也希望人们开发出支持这种思想的工具。我也会希望看到，业务部门发布和共享上下文设计。对将要开发新应用程序的业务部门而言，那会有很大的帮助。在技术层面上，我认为框架的概念可以进一步发展，而且可以构建开发工具来提供支持。如果高层设计可以从一个库中获取，则有可能可以对设计进行自动分析——至少一部分可以——并生成可以测试实现的测试。

InfoQ：从解决方案的角度讲，您能总结下如何“设计需求”可以帮助人们“构建用户想要且需要的应用程序吗？”

Britton：简单来说，这本书就是关于如何让业务管理人员参与进来，与IT应用程序设计人员一起开展设计工作，从而构建起更好的合作关系。这可以迫使人们在实现应用程序之前进行深入的思考，做出更好的业务决策，更慎重地选择要实现的特性。具体的实现阶段也会更快，因为很少需要回去返工。

关于作者

Chris Britton是一名资深IT专家。过去五年里——出乎他的意料——他发现自己一直在为初创企业设计和实现Web应用程序。在此之前，他在Unisys工作了多年，从事过各种工作，包括系统软件设计、架构顾问、修复损坏的大型数据库、项目管理，甚至市场营销。就是在这段时间里，他完成了自己的第一本IT著作《IT Architecture and Middleware: Strategies for Builiding Large Integrated Systems》。

查看英文原文：Q&A With The Author on "Designing the Requirements”, an Alternative Approach