【系统架构师设计（五）】需求工程上：需求开发与需求管理概述、结构化需求分析法

一、需求工程概述

软件需求是用户对系统在功能（如系统应具备哪些操作和业务逻辑 ）、行为（如系统响应外部事件的方式 ）、性能（如运行速度、资源占用 ）、设计约束（如技术选型限制、硬件要求 ）等方面的期望，它是软件开发的出发点。

需求工程不是简单的需求收集，而是一个完整的工程化过程。它包含需求开发和需求管理两大核心活动，前者负责需求的获取、分析和规格化，后者确保需求在整个软件生命周期中得到有效控制。这种系统化的方法确保了软件产品能够真正满足用户的实际需要，避免开发过程中的方向性错误。

 

需求工程主要活动阶段

需求开发：

• 需求获取：通过访谈、问卷调查、观察用户工作流程等方式，收集用户对软件的各类需求信息，从用户处挖掘出他们的真实期望。
• 需求分析：对获取的需求进行梳理，分析需求间的关联、优先级，识别并消除需求中的模糊、冲突部分，将用户的原始需求转化为清晰、可实现的需求描述。
• 形成需求规格（SRS）：把分析后的需求以规范的文档形式呈现，即软件需求规格说明书（SRS），它是软件开发团队与用户沟通需求的重要依据，明确界定软件要做什么。
• 需求确认与验证：与用户、开发团队等相关方共同评审SRS，确保需求准确无误且符合各方预期，评审通过后的SRS形成需求基线，作为后续开发的基准。

 
需求管理：

针对需求基线开展工作，包括

• 变更控制（管理需求的变更请求，评估变更影响并决定是否实施 ）、
• 版本控制（记录需求版本变化，方便追溯和管理 ）、
• 需求跟踪（跟踪需求在设计、编码、测试等阶段的实现情况 ）、
• 需求状态跟踪（掌握需求处于已实现、待实现、变更中等状态 ），

保证需求在整个软件生命周期内得到有效管理 。

 

二、需求获取

 

1、需求分类

不同层次的需求

1. 业务需求：从整体、全局角度出发，描述组织或业务对软件的需求，体现软件在业务层面要达成的目标 。
2. 用户需求：站在用户视角（不同职能，不同使用功能下的），反映用户对软件功能、操作等方面的期望和要求 。
3. 功能需求（系统需求）：关注软件计算机化后的具体功能，是软件要实现的业务逻辑和操作功能。进一步细分为：
   • 功能需求：软件应具备的具体功能点。
   • 性能需求（非功能）：如软件的响应时间、吞吐量、可靠性等性能指标 。
   • 设计约束：对软件设计的限制条件，如技术选型、硬件要求等 。

 

从项目管理维度划分

1. 基本需求（明示，常规需求）：明确表述、常规的需求，是软件必须满足的基础要求 。
2. 期望需求（隐含）：用户未明确提出，但期望软件具备的需求 。
3. 兴奋需求（多余）：超出用户预期，若实现会让用户非常满意的需求 。

 

2、需求获取：挖掘真实需求的艺术

需求获取的本质是理解用户的真实意图，而不是简单地记录用户说出的每一句话。用户往往无法准确表达自己的需求，或者表达的需求与实际需要存在差距。因此，需求获取需要采用多种方法，从不同角度深入挖掘用户的真实期望。

1. 用户面谈是最直接有效的方法，特别适合针对1-3个有代表性的用户进行深入交流。通过面对面的沟通，可以深入了解用户的主观想法，交互性好，能够及时澄清模糊点。然而，这种方法成本较高，且要求实施者具备相关领域知识，才能有效引导和理解用户需求。

2. 联合需求计划（JRP） 是一种高度组织化的群体会议方法，各方人员共同参与，可以充分了解各方想法，消除分歧。这种方法特别适合需要协调多个利益相关者的复杂项目，但组织成本较高，需要精心策划和协调。

3. 问卷调查适用于用户数量众多、难以进行逐一访谈的情况。通过设计结构化的问卷，可以大规模收集用户意见，成本相对较低。但这种方法缺乏交互性，难以深入挖掘复杂需求。

4. 现场观察是了解用户真实工作流程的有效方法，通过实地观察用户的操作过程，可以直观了解用户的实际需求和痛点。这种方法特别适合针对复杂流程和操作进行需求获取。

5. 原型化方法通过构建简易系统，帮助解决早期需求不确定的问题。让用户在原型基础上提出更明确的需求，这种方法能够有效减少需求理解的偏差。

6. 头脑风暴法鼓励发散思维，激发新观点产生，特别适合挖掘潜在需求和创新功能。一群人围绕新业务展开自由讨论，往往能够产生意想不到的好想法。

 

三、需求分析概述

需求分析需要分析需求间的关联关系，确定需求的优先级，识别并消除需求中的模糊、冲突部分，最终形成清晰、可实现的需求描述。
 

如下对需求分析的方法分为：结构化分析方法与对象分析方法：

一、 结构化分析方法通过数据流图、状态转换图、E-R图等工具，从不同角度分析系统需求。

• 数据流图关注数据的流动和处理过程
• 状态转换图描述系统的行为逻辑
• E-R图则关注数据实体及其关系

这些不同的视角相互补充，形成了对系统的全面理解。

 

二、 面向对象分析方法则从对象的角度理解系统，通过类图、用例图、顺序图等UML工具，将系统分解为相互协作的对象。这种方法更接近人类的思维方式，能够更好地处理复杂系统的建模问题。

 

四、需求分析法之一：结构化分析方法

1、 概述

结构化分析方法是以数据为中心，通过分解、抽象和建模将复杂系统或问题转化为可理解的结构化组件，用于分析、设计与描述的方法。

核心特点

1. 层次性：将系统或问题按层级分解，从整体到局部逐步细化，形成“顶层-中层-底层”的结构体系。例如分析一个业务系统时，先明确整体目标，再拆解为子系统、模块、具体功能等。
2. 数据驱动：重点关注数据的流动、存储和处理过程，通过数据字典、数据流图等工具描述数据在系统中的流转逻辑。
3. 标准化建模：使用统一的工具和符号（如数据流图、实体-关系图、结构化英语等）进行建模，确保分析过程和结果的规范性、可读性。
4. 模块化：将系统拆分为相互独立又相互关联的模块，每个模块完成特定功能，便于单独分析和优化。

常用工具与技术

1. 数据流图（DFD）：通过“数据流、加工、数据存储、外部实体”四个基本要素，直观展示数据在系统中的处理流程和传递路径，分为顶层DFD（整体概览）和底层DFD（细节拆解）。
2. 数据字典（DD）：对数据流图中涉及的所有数据项、数据结构、数据流、数据存储等进行详细定义，确保数据描述的一致性和准确性。
3. 实体-关系图（ER图）：用于描述系统中实体（如“用户”“订单”）、属性（如用户的“姓名”“ID”）及实体间关系（如“用户下单”），常用于数据库设计阶段。
4. 结构化语言：结合自然语言、程序设计语言的逻辑结构（如“如果…那么…否则”“循环”），描述加工逻辑，避免歧义。

应用步骤

1. 需求收集与梳理：明确系统或问题的目标、范围、输入输出及约束条件，收集相关业务规则和数据需求。
2. 系统分解：将整体系统按功能或业务流程拆解为多个子系统或模块，明确各部分的边界和职责。
3. 数据流程分析：绘制数据流图，标识数据的来源、处理过程、存储位置和去向，梳理数据在各模块间的流转关系。
4. 数据细节定义：通过数据字典对数据流图中的数据元素进行详细说明，包括名称、类型、长度、取值范围等。
5. 逻辑建模与验证：使用ER图等工具建立数据逻辑模型，验证各组件之间的一致性和完整性，确保无遗漏或冲突。
6. 文档化与迭代优化：将分析结果整理为规范文档（如需求规格说明书），并根据反馈迭代调整结构和模型。

适用场景

• 结构化程度高、业务流程稳定的系统分析（如传统金融系统、库存管理系统）。
• 数据流程清晰、规则明确的问题拆解（如财务报销流程、订单处理流程）。
• 需严格遵循标准化规范的开发或设计场景（如软件工程中的结构化开发方法）。

局限性

• 对动态变化的系统或模糊需求适应性较弱，难以处理非结构化问题（如创新业务模式、复杂人际关系分析）。
• 过度强调数据和流程的结构化，可能忽略用户体验、灵活性等非功能性需求。

总之，结构化分析方法通过“分解-建模-验证”的逻辑，为复杂系统提供了清晰的分析框架，是解决规范化、数据密集型问题的有效工具。

 

2、数据流图（DFD）

这是在线教育平台系统的数据流图（DFD），属于需求工程中需求开发的需求分析部分，运用结构化分析（SA）方法。以下是对图中内容的解读：

整体架构：自定向下

• 顶层DFD（0层）：展示在线教育平台系统与外部实体（培训部、辅导老师、学员）的交互。培训部提供课程安排数据给系统；学员向系统发送注册请求，系统反馈课程安排；系统向辅导老师提供类别列表。
• 分解后的DFD（1 - 3层）：将顶层系统功能进一步细化。

 
各元素说明

• 外部实体：培训部、辅导老师、学员，是与系统交互但处于系统外部的对象 。
• 数据流：如课程安排数据、注册请求、课程安排、类别列表等，代表数据在系统与外部实体或系统内部不同加工之间的流动方向 。
• 加工：
  • 安排课程（1）：接收培训部的课程安排数据，进行课程安排相关处理。
  • 学员注册（2）：处理学员的注册请求，结合课程和学员信息完成注册操作，并反馈课程安排给学员。
  • 产生类别列表（3）：依据学员注册信息等，生成类别列表提供给辅导老师 。
• 数据存储：图中虽未明确画出数据存储符号，但可理解课程、学员等信息存在相应存储，供各加工环节调用 。

该数据流图通过分层方式，从整体到局部逐步细化在线教育平台系统的功能和数据流转，有助于清晰分析系统需求 。

 

3、行为模型：状态转换图（STD）

该状态转换图通过展示学员在在线教育平台系统中的状态变化以及触发状态转换的事件和条件，清晰呈现了学员从注册到学习再到测试的业务流程需求，有助于准确理解系统的行为逻辑 。

状态：描述了用户当前操作的状态以及下一步的流程

• 注册：学员完成注册操作后的状态，是流程起始状态之一。若学员没有交费，则停留在注册状态；若已交费，系统开通课程，进入学习状态。
• 学习：学员进行课程学习的状态。当学员学完指定教材后，进入测试状态；若测试不合格，则返回学习状态继续学习。
• 测试：学员完成学习后进行测试的状态。测试合格，流程结束；测试不合格，返回学习状态。

 
事件与条件：描述了触发事件所需的条件

• 没有交费：导致学员停留在注册状态的条件。
• 开通课程[已交费]：学员已交费这一条件满足时，触发从注册状态到学习状态的转换事件。
• 已学完指定教材：触发从学习状态到测试状态转换的事件。
• 测试不合格：测试结果为不合格时，触发从测试状态回到学习状态的转换。
• 合格：测试结果合格，流程结束。

 

4、数据建模：E-R

这张图展示了需求工程中需求开发的需求分析部分，使用实体 - 联系（E - R）图来描述不同实体间的联系：

实体联系类型

1. 1:1的联系：
   实体A和实体B之间是一对一的关系，即一个实体A对应一个实体B，反之亦然 。例如，一个身份证对应一个公民，一个公民也仅有一个有效的身份证 。
2. 1:n的联系：
   实体A和实体B之间是一对多的关系，一个实体A可以对应多个实体B，但一个实体B只对应一个实体A 。比如，一个班级对应多个学生，而一个学生只属于一个班级 。
3. m:n的联系：
   实体A和实体B之间是多对多的关系，多个实体A可以对应多个实体B，反之亦然 。像学生和课程，一个学生可以选修多门课程，一门课程也可以被多个学生选修 。
4. 同一实体集内一对多的联系：
   以“职工”实体为例，存在“领导”联系，表明一个职工（领导）可以管理多个职工（被领导），是同一实体集内部的一对多联系 。

实际场景示例

1. 供应商 - 工程 - 零件：
   展示了供应商、工程和零件三个实体间的联系。供应商为工程供应零件（m:n 联系 ），工程会订购零件（l:p 联系 ），体现了复杂业务场景下实体间的关联关系 。
2. 供应商 - 工程 - 零件：
   简化展示了供应商、工程和零件之间的订购联系，供应商和工程之间是多对多的订购关系 。

E - R图通过图形化方式清晰呈现系统中实体及其联系，帮助分析人员准确理解和梳理业务数据关系，为数据库设计等后续工作奠定基础 。