当前位置：首页 > news >正文

软考-系统架构设计师需求工程详细讲解

news 2025/9/17 10:11:07

个人博客：blogs.wurp.top

一、需求工程的核心概念与重要性

1. 什么是需求工程？

需求工程是指系统化的、结构化的应用已证实的原则、方法、技术和工具来发现、分析、记录、验证和管理软件需求的过程。它不仅仅是“收集需求”，而是一个贯穿软件生命周期初始阶段的综合性工程活动。

2. 为什么需求工程对架构师至关重要？

设计的根本依据：架构设计的所有决策都必须以满足需求为首要目标。错误或不完整的需求会导致架构推倒重来，代价巨大。
项目成败的关键：据统计，高达50%以上的项目失败都与需求问题相关（如需求不明确、频繁变更）。
沟通的桥梁：需求是用户、客户、管理者、开发人员、测试人员之间沟通的共同语言和契约。

3. 需求的层次（必考知识点）

需求是分层次的，架构师必须清晰理解并逐层细化：

层次	描述	实例 (以电商系统为例)	关注者
业务需求	反映组织或客户的高层级目标， why to do。	“提升在线销售额20%”	决策层、投资人
用户需求	用户需要系统帮助他们完成什么任务， what to do。	“作为买家，我希望能够快速找到想要的商品”	用户、产品经理
功能需求	系统为了满足用户需求而必须提供的具体功能或服务， how to do。	“系统必须提供基于关键词的商品搜索功能”	开发人员、测试人员
非功能需求	系统运行时所表现出来的特性，即质量属性和约束条件。	“搜索结果的响应时间应小于2秒” (性能)	架构师（核心关注）

二、需求工程的过程：一个结构化的生命周期

需求工程不是一个一蹴而就的活动，而是一个包含以下核心活动的过程：

1. 需求获取 (Elicitation)

目标：从用户、客户、文档、现有系统等来源发现和汲取需求。
常用技术：
- 访谈：一对一深度交流，了解特定用户的深层次需求。
- 问卷调查：面向大量用户，快速收集普遍意见和统计信息。
- 专题研讨会：召集多方利益相关者，集中讨论，快速定义需求。
- 原型法：快速构建一个可操作的界面原型，帮助用户直观理解并提出意见。对澄清模糊需求极其有效。
- 观察：观察用户当前的工作流程，发现潜在需求。
- 文档分析：分析现有的业务文档、报表、规则等。

2. 需求分析 (Analysis)

目标：对获取的原始需求进行整理、提炼、建模，消除冲突、发现遗漏、确定优先级，形成一致、完整、无二义的需求模型。
核心活动：
- 分类与整理：将需求按功能、非功能、业务规则等分类。
- 冲突解决：发现并解决不同用户或利益相关者之间的需求矛盾。
- 优先级划分：使用MoSCoW法等确定哪些是Must-have, Should-have, Could-have, Won‘t-have。
- 建模：使用模型来精化和表示需求（详见第三部分）。

3. 需求规格说明 (Specification)

目标：将分析的结果文档化，生成《需求规格说明书》(SRS)。该文档是后续设计、开发、测试的依据，也是与客户之间的契约。
要求：文档必须做到清晰、准确、无二义性、完整、一致、可验证、可修改。
形式：可以是自然语言、形式化语言（如Z语言）或两者结合。通常包含功能需求列表、非功能需求说明、用例描述等。

4. 需求验证 (Validation)

目标：确保需求文档准确无误地反映了用户的真实意图，并且是高质量的。
常用方法：
- 需求评审：组织评审会，邀请各方代表逐条检查需求文档。
- 原型验证：让用户通过操作原型来确认需求。
- 测试用例推导：根据需求编写测试用例，若能写出，则需求很可能是可验证的。

5. 需求管理 (Management)

目标：在整个项目生命周期中管理需求的变化，并维护需求、项目计划、工作产品之间的一致性。
核心活动：
- 需求跟踪：建立需求跟踪矩阵（RTM），将每个需求与它的来源、设计模块、代码、测试用例关联起来。这是架构师控制变更影响范围的关键工具。
- 变更控制：建立正式的变更控制流程（CCB）。任何需求变更都必须经过申请、评估（对成本、进度、架构的影响）、审批、实施的流程。严禁“口头变更”。

三、需求建模方法（架构师的核心技能）

建模是需求分析的核心手段，旨在从不同视角清晰地描述系统。

1. 结构化分析方法（传统方法）

数据流图 (DFD)：描述数据的流动、处理、存储和来源/去向。是描述系统功能的利器。
- 元素：外部实体、过程、数据流、数据存储。
- 层次：顶层图、0层图、1层图…逐层分解。
数据字典 (DD)：定义DFD中所有数据流和数据存储的详细组成。
实体关系图 (ERD)：描述系统内部的静态数据结构及其相互关系。
状态转换图 (STD)：描述系统或实体对外部事件的反应，以及状态之间的转换条件。适用于实时控制系统。

2. 面向对象分析方法（现代主流）

用例图 (Use Case Diagram)：描述系统的功能范围，从用户视角看系统“做什么”。是捕获功能需求的绝佳工具。
- 元素：参与者（Actor）、用例（Use Case）、系统边界。
用例描述 (Use Case Description)：用例图的文字补充，详细描述一个用例的基本流、备选流、前置条件、后置条件等。这是功能需求说明的主要形式。
类图 (Class Diagram)：描述系统的静态结构，包括类、类的属性、方法以及类之间的关系（关联、泛化、依赖等）。是面向对象设计的起点。
活动图 (Activity Diagram)：描述一个业务或用例内部的操作流程，类似于流程图。
序列图 (Sequence Diagram)：描述对象之间基于时间的动态交互顺序，清晰展示一次交互中消息的传递过程。

四、非功能需求（架构师的设计约束与目标）

这是架构师在需求阶段最需要关注和明确的内容，它直接决定了架构的风格和技术选型。

性能：响应时间、吞吐量、并发用户数、资源利用率等。
安全性：身份认证、授权、数据加密、审计日志、防攻击能力等。
可靠性：平均无故障时间（MTBF）、平均修复时间（MTTR）、容错能力等。
可用性：系统可正常运行的时间比例（如99.99%）。
可维护性：模块化程度、代码可读性、易修改和扩展的程度。
可移植性：跨操作系统、跨平台的能力。
约束：对设计和实现产生的限制，如必须使用指定的技术栈、必须符合等保三级要求、必须与现有系统集成等。

架构师必须将模糊的非功能需求（如“系统要快”）转化为可量化的、可验证的指标（如“在1000用户并发下，核心页面响应时间<2秒”）。

五、软考考点总结与应用

选择题：
- 直接考查需求层次的区分（业务需求 vs. 用户需求 vs. 功能需求）。
- 考查需求工程各个过程（获取、分析、规格说明、验证、管理）的定义和常用技术。
- 考查各种需求建模图（DFD、用例图、ERD）的元素和作用。
- 考查非功能需求的类型。
案例分析题：
- 题目描述一个项目因需求问题陷入困境（如需求频繁变更、用户不满意、测试无法进行）。
- 问题1：分析该项目在需求工程方面存在的主要问题。（答：可能缺乏有效的需求获取和验证；没有建立需求变更控制流程；非功能需求不明确）。
- 问题2：请为你提出改进建议。（答题套路：1. 采用多种技术（如原型法、研讨会）进行需求获取；2. 使用用例图和用例描述来明确功能需求；3. 量化非功能需求；4. 建立需求跟踪矩阵（RTM） 和变更控制委员会（CCB） 来管理需求变更）。
- 问题3：作为架构师，你如何从需求中推导出架构设计的关键约束？（答：重点分析非功能需求和约束条件，例如高并发需求导向分布式架构，高安全需求导向严格的分层和加密设计）。
论文题：
- 可能围绕“论需求管理在某项目中的应用”、“非功能需求对系统架构设计的影响”、“用例驱动架构设计”等主题。
- 写作时，必须结合一个具体项目，详细论述：
  - 你如何获取和分析需求（使用了哪些技术？遇到了什么困难？）。
  - 你如何管理和控制需求变更（如何评估变更对架构的影响？）。
  - 非功能需求是如何成为你架构设计中的驱动因素和约束条件的。
  - 过程中的经验和教训（如早期对非功能需求重视不足导致后期重构）。