系统的基本组织，体现在其组件，彼此之间以及与外界环境的关系以及支配其设计和演化的原则上。
系统的表示形式，包括功能到硬件和软件组件的映射，软件体系结构到硬件体系结构的映射以及与这些组件的人机交互。
分配的物理元素安排，可为消费产品或生命周期过程提供设计解决方案，以满足功能体系结构和基线的要求。
一个体系结构由最重要，最普遍的，xxx的，战略性的发明，决策及其与总体结构有关的基本原理（即基本要素及其关系）以及与之相关的特征和行为组成。
计算机系统设计和内容的描述。如果有记录，它可能包括诸如当前硬件，软件和网络功能的详细清单之类的信息；长期计划和将来购买的优先级的描述，以及升级和/或更换陈旧设备和软件的计划。
对系统的正式描述，或在组件级别上指导系统实施的详细计划。
产品及其生命周期过程的设计体系结构的组合。
组件的结构，它们之间的相互关系以及支配其设计和随时间演变的原理和准则。

系统组织架构与公司组织架构的关系：

可以将系统架构视为现有系统的一组表示。

整个系统（如5G网络）的网络架构类似一个集团公司的组织架构。

单个网元（如基站）的系统的架构，类似一个公司的组织架构。

这些表示最初描述了一般的高级功能组织（组织架构），并逐渐完善为更详细和具体的描述（系统设计）。如下图所示：

2.2 什么软件架构

架构(Architecture) 一词来源建筑领域，鉴于软件工程和建筑工程一样是一项系统的工程性工作，

计算机领域引入这个概念后，软件架构就成为描述软件设计技术的专有名词。

1972年图灵奖获得者(计算机领域的诺贝尔奖)、荷兰计算机科学家Edsger Dijkstra(最短路径算法的发明者)早在二十世纪六十年代(计算机诞生没多久)就已经提及软件架构这个概念了。到了二十世纪九十年代，众多学者和专家都对软件架构做过定义，但都没有一个统一的定义。这里选用卡耐基梅隆大学软件工程研究所的Len Bass及其同事对软件架构的定义，他们在使用软件架构成为一门学科方面发挥了关键作用。该定义是：计算机系统的软件架构是构建这个系统所需要的一组结构和规则，包括软件元素、它们之间的关系以及两者的属性。

上面的描述显然太过抽象。但其本质：是将应用程序的架构分解为元素(element)和这些元素之间的关系(relation)。由于以下两个原因，分解很重要：

(1) 它促进了劳动和知识的分工。它使具有特定专业知识的人员或团队能够高效地协同工作。

(2) 它定义了软件元素的交互方式。

将软件分解成元素以及定义这些元素之间的关系，决定了软件的能力。

简单来说，软件架构是一个用于指导系统编码实现的一系列的草图的结合，这个草图越详细，对系统实现的指导意义就越重要，且贯穿于软件的整个生命周期。但草图越详细，泛化能力越小。

2.3 “技术影响分析”的本质

“技术影响分析”与目标系统内部的软硬件架构密切相关，因为“技术影响分析”，本质就分析一个新的业务需求，对现有的软硬系统架构的冲击和影响。不同的需求，对系统架构的大小是不同的，冲击的点也相同。

2.4 为什么要做技术影响分析

目的是标识出分析功能需要对软硬件架构和内部功能组件是否有技术影响。

此时并不关注技术影响细节，只关注哪些模块或组件有影响，可能的影响点是什么。

之所以在撰写软硬件需求规范之前，先实施技术影响分析这个环节。这是因为，在大型系统开发中，系统被划分成很多的功能组件，甚至几十个功能组件，每个功能组件由不同的团队负责。

而不同的需求，对系统中组件的影响范围和程度是不一样的，有些需求，对系统中的大部分组件有影响，有些只对个别的组件有影响。在项目执行中，需要为每个需求组建开发团队，这些团队包括系统规范、软件、测试。如果没有“技术影响分析”是项目管理人员是无法确定，为该需要组件什么样的开发团队，该开发团队中包含哪个组件的人员。因此，有了技术影响分析“这个环节”，就可以标识出，要组件开发团队，需要包含哪些组件的开发人员，需要哪些职能部门出人。

有了这个阶段的输出，产品经理就可以有针对性地找相关的职能部门评估人力资源的影响、找相应的职能部门申请对应的人力资源。

“技术影响分析”适合如下组织：

目标系统庞大复杂，并划分了大量的技术领域
不同的专业技术领域，由不同的专业技术人员实施
大部分研发人员只能实施自身技术领域的工作，无法跨领域实施。
大量的需求并行开发。
不同的需要需要不同领域的专业技术人员

“技术影响分析”不适合如下组织：

小型团队，负责所有的客户需求
目标系统专业技能单一，每个团队都具有开发所有功能需要的能力
需求单一，串行开发

2.5 本阶段分析的输入

（1）前一个阶段FS0的决策（是否需要进行技术分析）

（2）需要范围和定义（本阶段最主要的输入依据）

（3）按优先级顺序排列的用户故事（本阶段最主要的输入依据）

（4）期望的目标软件版本

（5）产品系列的类型，如5G, 4G, 3G, 2G等。

（6）需要的技术分类，如平台，硬件、无线资源管理，安全，OAM等。

（7）商业潜力的初步估计

（8）软硬件的系统架构

该阶段的技术分析人员，除熟悉业务知识，即客户的需求：包括需求的范围和定义、用户故事。

同时，该阶段技术分析人员，必须熟悉目标软件或硬件系统的架构和内部组件的划分与职责或功能划分。

只有同时具备这两个领域的技能与知识，才能识别，该需要对系统中的哪些模块有技术影响。

所谓“有影响”：就是需要更改代码或文档，以支持该需要所支持的功能。

2.6 本阶段分析的主要活动

（1）评估该功能的实现难度：是否在一个软件版本中能够实现，还是需要跨越多个软件版本才能实现。

（2）更新功能范围和定义

（3）更新用户故事并确定其优先级

（4）完整的技术分析*

2.7 本阶段分析的输出

（1）评估该功能的实现难度：

是否在一个软件版本中能够实现，还是需要跨越多个软件版本才能实现。

（2）修正后的需要范围和定义

（3）修正后的按优先级顺序排列的用户故事

（4）工作量估算（FS0EE）：初步预计的投入

人力资源的投入
其他投入

此阶段的人力资源的投入估计还是比较粗糙的，在后续的阶段会进一步的细化和精确。

备注：如何评估所需的人力资源，后续再进一步探讨。

（5） FS1决策建议

（6）完整的技术分析报告

第3章技术影响分析报告的主要内容

3.1 基本信息

（1）ID号

（2）名称

（3）产品领域

（4）目标发布版本

（5）作者或负责人

（6）修订版本

（7）撰写人员名单

（8）评审人员名单

3.2 功能范围和目的

（1）这里描述客户功能需求。

（2）用户故事。

（3）对系统软硬件的需求。

（4）针对新需要总体的技术解决方案。

3.3 依赖关系

（1）外部网元的依赖关系

（2）与其他需求、功能、特征的依赖关系（dependency）

（2）与其他需求、功能、特征的交互关系（interaction）

这一块其实是难点，在一个复杂的系统中，一个新的功能需求，很难做到与其他功能与已有的、正在开发的、计划开发的功能需要没有交互而独立存在，有交互，就容易出错，需要考虑的因素也比较多。

3.4 技术影响分析

技术影响分析主要关注的是：

识别出该需要对目标系统的主要网元以及网元内的主要组件是否有影响。

而不关心技术影响的技术细节，技术影响的细节在后续的需求规范中进一步的明确。

（1）系统架构的影响

无线接入网
终端
核心网
网管中心

（2）系统性能的影响

吞吐率
最高速率

（3）技术风险分析

（4）单网元内部架构的影响

平台
OAM
RF
L1
L2
L3
传输

（5）需求规范工程师的人力资源工作量的评估

在技术影响面分析过后，从需求的角度来看，就需要根据技术影响面分析的结果，找到不同领域的需要工程师，来编写详细的系统级需求规格说明书了。这就需要从职能部门申请系统工程师的资源，而职能部门就会问：需要什么技术领域的需求规范工程师？需要多大的工作量？有了这两个信息，项目管理人员才能与系统部职能部门申请到相应的资源。