架构师之所以很关注需求，是因为两个原因：一是需求影响架构。因为需求影响解决方案的架构，而解决方案的元素是按照其是否能够满足规定的需求来挑选的。二是定义良好的需求导致高质量的架构。由于需求驱动架构的定义，所以，一组定义良好的需求比粗劣定义的需求更能产生高质量的架构。
由于以上两个原因，架构师在制定架构时特别关注需求。同时，架构也会影响需求。在定义架构时，架构师经常必须在不同的需求之间进行取舍，如平衡性能和成本。业务分析师得到这些反馈，从而对需求进行必要的调整。一些第三方商业系统（可以是某个插件），也会对系统的一些功能和质量产生约束。当架构分解为各个部分时，架构定义子系统的需求，尽管这个关系不那么明显。
尽管负责需求相关的任务是需求分析师的工作，而架构师在需求规范中仅涉及外围的工作，我们还是有必要了解一些需求如何产生的。下面的图很好的说明了这个问题。
在讲解定义需求之前，我们来细化一下需求的定义。需求分为功能性需求和非功能性需求。功能性需求描述了支持用户目标、任务和活动的（IT）系统的行为（功能或服务）。非功能性需求包括约束和质量。约束是对我们在提供解决方案时所拥有的自由度的一个限制。质量是利益相关者关心的系统特性和特点，因而影响其对系统的满意度。
约束包括业务（如规章制度和资源约束）和技术（如强制的技术标准和强制的解决方案因素）方面的约束。质量包括运行期质量（如性能和可用性）和非运行期质量（如可维护性和可移植性）的质量。
需求定义并不是只在项目开始时发生一次的事情，因为通常不可能事先理解并编写系统的所有需求文档。相反，对需求的提炼贯穿于整个项目生命周期，这意味着我们需要有效的需求管理。强调需求活动的最佳时机是在项目初始阶段的后期和细化阶段的初期。一些需求任务在构建阶段执行，如详细描述剩余需求；有些甚至在移交阶段执行，如根据用户反馈改进需求。
定义需求的活动任务步骤，如下图所示：
由于前面我们已经论述过需求相关的概念，要理解上面这些步骤中的内容，并不是很难。因此，我们仅针对上述步骤中一些特别的地方，进行简述，以求架构师们能最有效的处理这些需求。
1、收集利益相关者的要求
* 缺陷：把要求当作需求
* 缺陷：购物车式的思维方式
* 缺陷：调查问卷过于技术性
* 缺陷：要求过于笼统
* 缺陷：要求不可测量
* 缺陷：和不适当的人讨论
2、获取常用词汇
指一些专业术语。
3、定义系统上下文
确保理解所开发系统的边界以及确认与该系统交互的最终用户和外部系统。
4、概述功能性需求
包括系统范围内的功能性需求（用例）和用例无法表达的功能性需求，如系统安全。
5、概述非功能性需求
主要从可用性、稳定性、性能、支持能力、业务约束、架构约束和开发约束方面阐述相关的需求。
6、排定需求的优先级
7、详述功能性需求
#1 细化用例
将用例图由顶层向下逐级划分。
#2 细化用例数据项
#3 细化系统范围的功能性需求
#4 细化功能性需求场景
8、详述非功能性需求
细化非功能性需求场景
9、更新软件架构文档
将各种需求整理成文档。
10、与利益相关者复审需求
#1 定义工作产品的基线
#2 汇集工作产品
#3 复审工作产品
其实，在定义需求这些步骤中，每个环节都有很多的内容要写，不过毕竟这是写博客，而不是写书，所以只是概要的说明定义需求的步骤，希望能对那些想向架构师方向进军的人有一些帮助。如果您想了解更多的内容，我们可以私底下进行切磋。
