在企业级业务架构实施阶段，除了从架构规划直接产生的项目，业务部门会提出各类业务需求。如何处理这些需求？如果还是按老办法处理，那么新的业务需求的提出，就是企业级业务架构崩坏的开始。使用业务架构有效管理业务需求成为保证企业级架构稳定、长期有效的重要基础性工作。

（一）架构、项目与需求的关系

业务架构是对业务的结构化表达，是一种高级的需求管理方法。业务架构定义了业务的结构，包括有哪些业务组件，以及组件和组件之间的关系。一旦业务架构规划完成，业务架构就相对固定下来，作为一段时间内从业务到技术的“作战地图”，指导从业务需求到技术实现的过程。

业务需求是随时都会存在的，是动态变化的。过去的信息化建设模式是需求驱动的，就是业务部门提出需求，科技部门提出解决方案并开发系统，结果是形成了一个又一个烟囱，导致系统割裂、数据孤岛。企业级业务架构是对公司业务的整体结构化描述。在架构指导下的信息化建设模式下，需求要按照业务架构进行管理，所有业务需求都要在业务架构中找到自己的位置。

项目是对需求的实施，包括业务实施、数据实施和系统实施。在项目过程中实现了需求，同时保证了架构遵从，部分情况下也更新了架构资产。

项目实施完毕，将项目成果部署到实际业务当中。然后在业务运行又会产生新的需求，不断往复循环。

（二）需求的三个层次

需求是分层的，不同环节处理的需求层次不同。

世界公认的软件需求工程专家Karl Wiegers在其经典著作《软件需求》中将需求分为业务需求，用户需求和系统需求等三个层次。

1.业务需求（Business Requirements）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求。这份文档有时也被称作项目宪章（project charter）或市场需求（market requirement）文档。

2.用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件-响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。其产出是《用户需求说明书》和交互原型。

3.系统需求（system requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。系统需求描述的是开发人员需要实现什么，满足哪些功能需求和非功能需求。其产出是《软件需求规格说明书》文档。

（三）使用业务架构管理业务需求

1.主要精力应投入到新流程、新系统的建设当中来，旧系统在保证其运行正常的前提下做最少维护。这是最基本的原则，必须遵守。不然目标和资源之间就无法匹配，有失败的可能性。

2.要做好业务需求的入口管理，对原始需求进行筛选，明确“做不做”。要从企业级视角审视业务需求，需求有没有业务价值，是否符合公司发展战略，有没有可衡量可评价的业务目标，业务逻辑是否走得通，技术上有没有可行性，这些都需要进行考量，筛选出有价值的业务需求进入到下一环节。互联网行业中对需求也有一个筛选标准，就是“高频、刚需、痛点”，高频就是使用次数很多，不断重复，刚需就是没有不行，痛点就是存在困扰客户或用户的重大问题，符合这些条件的需求是好需求，满足了这些需求，会提高客户/用户满意度，会带来较高的业务价值。这一阶段处理的需求层次是业务需求。需要建立需求池或需求存储库来记录和管理所有业务需求。

3.做好企业级架构管控，对新的业务需求意向要进行统筹分析。必须按照业务架构方法进行解构，明确其所属的业务组件。所有业务需求都应该纳入到业务架构中，在业务架构中找到自己的位置。大部分业务需求可以直接在业务架构中找到明确的业务组件，少部分则需要对业务架构进行扩展设计，将其容纳进来。

4.PMO分配项目任务给组件开发团队。业务需求各就各位了，再由PMO根据业务优先级确定实施顺序，匹配资源，形成项目任务。实施团队也是按照业务组件来划分的，包含了业务人员、需求人员和技术人员。PMO将项目任务分配给组件开发团队，该团队负责对同一个业务组件进行建设、维护和持续升级。

5.组件开发团队进行需求分析，形成解决方案。组件开发团队对同一业务组件的多个业务需求进行分析，进行需求的归并整合，形成解决方案，纳入到业务组件的模型当中来。模型本身有升级的，要沉淀到架构资产当中来。需求调研、需求分析和撰写需求文档的工作是由组件开发团队完成的，这一阶段处理的需求层次是用户需求和系统需求。