一、引言
需求工程与系统设计是软考高级系统架构设计师考试的核心模块，在案例分析题和论文题中占比超过 30%，是架构设计的前置核心环节。需求工程的核心目标是将模糊的用户诉求转化为可验证、可落地的精确规格，是避免架构设计方向性错误的基础；系统设计则是基于需求完成技术方案的抽象与落地，直接决定系统的质量属性与生命周期。
从发展脉络来看，需求工程与系统设计经历了三次重要演进：20 世纪 70 年代结构化方法主导阶段，以数据流图、模块化设计为核心；90 年代面向对象方法普及阶段，UML 成为行业标准建模语言；2010 年之后敏捷与领域驱动设计融合阶段，需求迭代与领域建模深度结合。本文将系统梳理需求工程全流程、UML 建模体系、结构化与面向对象设计原则，覆盖考试所有高频考点。
二、需求工程核心体系与实施方法
需求工程是覆盖需求全生命周期的系统性活动，分为需求开发与需求管理两大分支，共包含 6 个核心阶段。
（一）需求开发核心流程
需求获取
需求获取是从用户、业务场景、现有系统等多来源收集原始需求的过程，核心目标是全面覆盖显性与隐性需求。常用获取方法包括：
- 用户访谈：分为结构化访谈（预设问题清单）和非结构化访谈（开放式交流），适用于获取核心业务规则，通常需要覆盖决策层、业务层、操作层三类用户。某银行核心系统改造项目中，通过分层访谈挖掘出监管合规类隐性需求 17 项，占总需求的 23%。
- 联合需求计划（JRP）：组织跨角色团队集中研讨，2-5 天内完成需求共识，适用于需求冲突较多的复杂系统，效率比分散访谈提升 40% 以上。
- 原型法：通过快速搭建可交互原型验证需求，分为抛弃式原型和演进式原型，适用于需求模糊的创新型系统，可减少后期需求变更率 60%。
- 其他方法：问卷调查（覆盖大样本用户）、现场观察（获取操作类隐性需求）、头脑风暴（挖掘创新型需求）。
需求分析
需求分析是对原始需求进行建模、澄清、校验的过程，核心目标是消除歧义、识别冲突、建立需求逻辑模型。主流分析方法包括两类：
- 结构化分析：以过程和数据为核心，通过三类模型完成需求描述：数据流图（DFD）描述系统功能与数据流转，状态转换图（STD）描述系统行为状态变化，ER 图描述业务实体关系。该方法适用于流程稳定的政务、金融核心系统。
- 面向对象分析：以业务对象为核心，通过 UML 建立对象模型、用例模型、动态模型，适用于业务迭代快的互联网、企业级应用系统。
需求定义
需求定义是输出正式需求规格说明书（SRS）的过程，有两类实现思路：
- 严格定义法：假设需求可在前期完全明确，SRS 包含完整的功能、性能、接口、约束等所有需求项，适用于需求稳定的嵌入式、工业控制系统。
- 原型法：承认需求在前期难以完全明确，通过迭代完善原型逐步细化 SRS，适用于 ToC 互联网产品、创新型业务系统。
需求验证
需求验证是确认需求正确性、完整性、可行性的过程，核心方法包括需求评审（由技术、业务、测试等多角色参与的正式评审）、原型测试、需求一致性检查等。依据 CMMI 3 级标准，需求验证通过率需达到 100% 才能进入设计阶段。
（二）需求管理核心机制
- 需求跟踪
建立需求全链路跟踪矩阵，实现需求与后续工作产品的双向追溯：正向跟踪可确认每个需求都被实现，反向跟踪可确认每个设计、代码、测试用例都有对应的需求依据。某电商平台订单系统中，需求跟踪矩阵覆盖 327 项需求、1245 个设计模块、8923 个测试用例，需求遗漏率从 15% 降至 2%。 - 需求变更控制
建立标准化变更流程：第一步为问题分析与变更描述，明确变更原因、影响范围；第二步为变更分析与成本计算，评估变更对工期、成本、质量的影响；第三步为变更实现，由变更控制委员会（CCB）审批后执行变更。需求变更率需控制在 10% 以内，超过阈值需重新评估项目可行性。
需求工程全流程架构图，展示需求开发与需求管理各阶段的输入输出、核心活动、参与角色
三、软件建模方法体系与选型策略
软件建模是连接需求与设计的核心桥梁，主流建模方法分为三类，不同方法有明确的适用场景。
（一）三类建模方法对比
- 结构化建模
以过程为中心，核心工具为数据流图，将系统分解为多层处理过程与数据流向。优点是逻辑清晰、符合人类对流程的认知，缺点是对需求变化的适应性弱，过程调整会导致整体模型重构。适用于工业控制、金融核心交易等流程稳定的系统。 - 信息工程建模
以数据为中心，核心工具为 ER 图，聚焦业务实体、属性与实体间关系的建模。优点是数据模型稳定性高，缺点是缺乏对业务逻辑的表达能力。适用于数据仓库、大数据平台等数据驱动型系统。 - 面向对象建模
将数据与处理逻辑封装为对象，核心工具为 UML，通过对象的交互实现系统功能。优点是可复用性高、需求适应性强，缺点是建模复杂度较高。该方法是当前行业主流，也是软考考试的核心考点。
（二）建模方法选型原则
选型需依据系统特性确定：流程稳定的系统优先选择结构化建模，数据密集型系统优先选择信息工程建模，业务迭代快的系统优先选择面向对象建模。复杂系统通常采用混合建模方式，如核心交易流程用结构化建模，业务实体用信息工程建模，业务交互用面向对象建模。
三类建模方法对比表，包含核心思想、工具、优点、缺点、适用场景五个维度
四、UML 核心知识与应用场景
UML（统一建模语言）是 OMG 发布的行业标准建模语言，当前最新版本为 2.5，包含 13 种图与 4+1 视图体系，是面向对象分析与设计的核心工具。
（一）UML 13 种图分类与应用
UML 图分为静态结构图和动态行为图两大类，每类有明确的应用场景：
结构图（静态，描述系统的组成结构）
- 类图：描述类的属性、方法以及类之间的关系（关联、依赖、继承、实现），是面向对象设计的核心，用于定义系统的静态模型。
- 对象图：类的实例化描述，用于验证类模型的正确性。
- 构件图：描述系统的组件以及组件之间的依赖关系，用于组件级设计。
- 部署图：描述系统硬件节点以及软件在节点上的部署关系，用于系统部署架构设计。
- 其他结构图：制品图描述系统的物理制品，包图描述模型的分层组织，组合结构图描述类的内部结构。
行为图（动态，描述系统的运行行为）
- 用例图：描述参与者与系统功能的交互关系，用于需求阶段的功能建模。某电商系统的用例图包含用户、商家、管理员三类参与者，覆盖 27 个核心用例。
- 顺序图：描述对象之间按时间顺序的交互关系，用于接口设计、流程逻辑验证。
- 通信图：描述对象之间的消息交互与协作关系，与顺序图语义等价但聚焦对象关联。
- 定时图：描述消息交互的时间约束，用于实时系统的时序设计。
- 状态图：描述对象的状态变化与触发条件，用于复杂业务实体的行为建模，如订单状态流转。
- 活动图：描述业务流程的活动与分支，用于业务流程建模，替代传统的流程图。
- 交互概览图：活动图与顺序图的结合，用于描述复杂交互流程。
（二）UML 4+1 视图体系
4+1 视图是描述系统架构的标准方法，从 5 个互补的视角完整呈现系统特性：
- 逻辑视图：关注系统的功能需求，通过类图、对象图实现，面向最终用户。
- 进程视图：关注系统的运行时特性、并发与性能需求，通过状态图、活动图实现，面向系统集成人员。
- 实现视图：关注系统的组件组织与配置管理，通过构件图、包图实现，面向开发人员。
- 部署视图：关注系统的物理部署、硬件拓扑，通过部署图实现，面向运维人员。
- 用例视图：作为核心连接其他四个视图，描述系统的场景需求，通过用例图实现，覆盖所有干系人。
UML 4+1 视图关系示意图，展示五个视图的核心内容、使用的 UML 图、面向的角色
五、系统设计核心原则与实践方法
系统设计是将需求转化为技术方案的过程，核心目标是构建满足功能需求与质量属性的系统架构，包含人机界面设计、结构化设计、面向对象设计三类核心内容。
（一）人机界面设计黄金三法则
人机界面设计需遵循 ISO 9241-110 标准提出的三大原则：
- 置于用户控制之下：支持用户自定义操作路径、允许撤销操作、提供操作反馈，避免强制用户按照固定流程操作。
- 减少用户的记忆负担：信息可见、操作符合用户习惯、提供上下文提示，避免用户需要记忆大量操作规则。
- 保持界面一致：相同功能的交互方式、视觉风格保持一致，避免不同模块的操作逻辑差异过大。
符合三原则的界面可降低用户学习成本 30% 以上，操作错误率降低 40%。
（二）结构化设计核心原则
结构化设计的核心目标是实现模块独立性，遵循高内聚、低耦合的设计准则：
内聚类型（从高到低排序，设计优先选择高内聚）
- 功能内聚：模块完成单一完整的功能，是最优的内聚类型，如订单支付模块。
- 顺序内聚：模块内的处理元素与同一功能相关，且必须顺序执行，如订单创建模块先校验库存再生成订单。
- 通信内聚：模块内的所有处理元素使用相同的输入数据或产生相同的输出数据，如用户统计模块基于用户数据生成多个报表。
- 过程内聚：模块内的处理元素按照特定流程执行，如用户注册模块按顺序执行信息校验、账号创建、通知发送。
- 时间内聚：模块内的功能在同一时间点执行，如系统初始化模块启动时加载所有配置。
- 逻辑内聚：模块内的功能逻辑相关，如报表生成模块支持多种类型报表的生成。
- 偶然内聚：模块内的功能没有关联，是最差的内聚类型，需要完全避免。
耦合类型（从低到高排序，设计优先选择低耦合）
- 非直接耦合：模块之间没有直接交互，通过上层模块调度，是最优的耦合类型。
- 数据耦合：模块之间通过参数传递简单数据，如用户查询模块传递用户 ID 给用户信息模块。
- 标记耦合：模块之间传递数据结构，如订单模块传递订单对象给支付模块。
- 控制耦合：模块之间传递控制信号，如一个模块控制另一个模块的执行逻辑，应尽量避免。
- 外部耦合：模块依赖外部系统的协议、接口，如对接第三方支付系统，需统一封装适配层。
- 公共耦合：多个模块访问同一公共数据区，如共享全局变量，会导致难以排查的错误，应严格限制使用场景。
- 内容耦合：一个模块直接修改另一个模块的内部数据或代码，是最差的耦合类型，必须完全禁止。
结构化设计还需遵循模块大小适中（通常代码行数在 100-500 行之间）、多扇入（尽量多的模块调用该模块，提升复用性）、少扇出（模块调用的其他模块数量控制在 3-5 个，降低复杂度）、深度与宽度适中（架构分层控制在 3-7 层，每层模块数量不超过 10 个）的辅助原则。
内聚与耦合类型对比示意图，展示不同类型的定义、示例、适用要求
（三）面向对象设计黄金七法则
面向对象设计的核心是构建稳定、可扩展的对象模型，包含基础过程与七大设计原则：
基本设计过程
- 第一步：识别边界类、控制类、实体类三类核心类。边界类负责系统与外界的交互，如用户界面、外部接口；控制类负责业务逻辑与流程控制，如订单支付逻辑；实体类对应业务实体，保存持久化数据，如订单、用户对象。
- 第二步：定义类的属性与方法，明确类的职责边界。
- 第三步：定义类之间的关系，包括关联、依赖、继承、实现。
- 第四步：基于设计原则优化调整类模型，提升可扩展性与可维护性。
七大设计原则
- 单一职责原则：一个类只负责一个功能领域，避免类的职责过多导致修改相互影响。如用户类只负责用户属性与核心操作，用户统计功能单独封装为用户统计类。
- 开闭原则：对扩展开放，对修改封闭，通过抽象与扩展实现新需求，避免修改现有代码。如支付系统通过抽象支付接口，新增支付方式时只需要新增实现类，不需要修改现有支付逻辑。
- 李氏替换原则：子类必须可以替换其父类，继承时不能破坏父类的原有逻辑，避免子类重写父类核心方法导致逻辑异常。
- 依赖倒置原则：依赖抽象而非具体实现，高层模块不依赖底层模块，二者都依赖抽象。如业务逻辑层依赖数据访问抽象接口，而非具体的 MySQL 实现，可轻松切换为 Oracle 数据库。
- 接口隔离原则：使用多个专门的接口，而非单一的总接口，避免接口的实现类不需要实现多余的方法。如用户接口拆分为用户查询接口、用户管理接口，查询服务只实现查询接口。
- 组合复用原则：优先使用组合而非继承实现代码复用，避免继承带来的父类变更影响子类、类层次过深的问题。如汽车类通过组合发动机类实现动力功能，而非继承发动机类。
- 迪米特法则（最少知识原则）：一个对象对其他对象有最少的了解，只与直接朋友交互，降低类之间的依赖复杂度。如订单类只与支付服务类交互，不直接调用支付服务内部的账户类。
面向对象设计原则应用场景示意图，展示每个原则的核心逻辑、错误示例、正确示例
六、前沿发展与考试趋势
当前需求工程与系统设计的发展呈现三个核心趋势：
- 需求工程与领域驱动设计（DDD）深度融合，通过事件风暴、用户旅程等方法将需求分析与领域建模合并，需求不再是独立的文档，而是直接转化为领域模型，大幅缩短需求到设计的转换周期。某互联网公司的业务系统采用该方法后，需求到设计的转换效率提升 50%，领域模型与需求的一致性达到 95%。
- 低代码 / 无代码平台的普及，需求分析人员可直接通过可视化工具完成原型与基础模型设计，系统设计的重点从基础功能实现转向核心业务逻辑与架构特性设计。
- 智能化需求分析工具的应用，通过大模型自动提取需求、生成初始模型、检查需求一致性，需求分析效率提升 40% 以上。
在软考考试中，该模块的考点呈现三个变化：一是 UML 建模与 4+1 视图的结合考查增多，通常在案例分析题中要求根据需求选择合适的 UML 图并绘制核心模型；二是设计原则的场景化考查，要求分析实际案例中违反的设计原则并给出优化方案；三是需求变更控制的综合考查，结合项目管理知识评估变更影响并给出处理流程。
需求工程与系统设计技术演进路线图，展示从结构化到面向对象到 DDD 融合的发展路径
七、总结与建议
（一）核心知识点提炼
- 需求工程分为需求开发（获取、分析、定义、验证）和需求管理（跟踪、变更控制）两大分支，需求变更控制需遵循标准化流程，由 CCB 审批。
- UML 包含 7 种结构图、6 种行为图共 13 种图，4+1 视图从逻辑、进程、实现、部署、用例五个视角完整描述系统架构。
- 结构化设计核心是高内聚低耦合，优先选择功能内聚、顺序内聚，优先选择非直接耦合、数据耦合，避免最差的内聚与耦合类型。
- 面向对象设计七大原则包括单一职责、开闭、李氏替换、依赖倒置、接口隔离、组合复用、迪米特法则，是架构设计的核心准则。
（二）考试与实践建议
- 备考重点：UML 图的适用场景、4+1 视图的内容、内聚与耦合的类型排序、面向对象七大原则的应用是高频考点，需要重点掌握，案例分析题中通常会要求结合场景判断违反的设计原则并给出优化方案。
- 实践建议：需求阶段优先采用原型法验证核心需求，建立需求跟踪矩阵，控制需求变更率；设计阶段优先遵循面向对象设计原则，复杂系统采用混合建模方法，提升架构的可扩展性与可维护性。
- 学习路径：先掌握需求工程的全流程方法，再学习 UML 建模工具的使用，最后深入理解设计原则的应用场景，通过实际项目案例练习将理论转化为实践能力。