注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模型、代码。例如设计文档、数据模型等。参考RUP的Artifact。
评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需求。做好需求的方法有很多（参见拙作需求的实践），但这并不是我们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发来设计架构，这就是保证软件可用性的一个基本的保证。
Context
我们如何开始我们的架构设计工作？
Problem
我们在进行架构设计的时候，往往主要考虑的都是平台、语言、开发环境、数据库等一些基本问题，可是对于和客户的具体情况密切相关的一些问题却很少系统的考虑。甚至还存在一种误区，认为架构设计无非就是写一些空话，套话。这样子做出来架构设计，如何用于指导软件的实现呢？
IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术？
每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益的架构？
软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往很难做到，但是如果不解决问题，风险又居高不下。
Solution
针对需求设计架构。
架构设计就是铺设软件的主管道（例1）。我们根据什么来制定主管道的粗细、路径等因素呢？很明显，是根据城市的人口、地理位置、水源等因素来决定的。对应到软件设计也是一样的。城市的各因素就是软件中的各种需求：功能需求、非功能需求、变化案例等等。
一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化案例决定架构的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术架构要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个架构的范围。
从例2中，我们看到自已字处理软件的几种需求的范例。真正的字处理软件要复杂的多。而我们最主要的就是必须认识到，架构是来自于需求的。有什么样的需求就有什么样的架构。试想一下，如果我们没有对速度的要求，我们还需要考虑这方面的设计吗？我们上面提到了几种类型的需求对架构的影响，其实还有一个很重要的需求，就是环境的需求。这并不是一个很重要的需求，但是对于部署（deployment）架构设计来说就特别重要。毕竟，我们开发出的软件是要上"战场"的，充分的考虑部署问题是非常有必要的。
例1：城市中自来水管的架设是一项非常的复杂的工程。为了需要满足每家每户的需要，自来水管组成了一个庞大的网络。在这样一个复杂的网络中，如何完成铺设的任务呢。一般的做法是，先找出问题的根源，也就是水的源头。从水源铺设一条管道通至城市，然后根据城市的区域划分，设计出主管道，剩下的就是使用的问题了，每家每户的管道最终都是连到主管道上的。因此，虽然自来水网络庞大复杂。但是真正的主管道的非常简单的。
例2：我们打算开发一个字处理软件，功能需求可以简单概括为格式化用户输入的文字，非功能需求可能是格式化大小为1000K的一段文字的处理速度不能低于10S，变化案例可能是推出多种语言版本。那么我们在设计业务架构的时候，我们会集中于如何表示文字、图象、媒体等要素，我们该需要有另外的技术架构来处理速度问题，比如缓冲技术，对于变化案例，我们也要考虑相应的架构，比如把字体独立于程序包的设计。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
