信息系统管理工程师-软件需求管理核心知识点详解

一、引言

软件需求是软件开发全生命周期的起始环节，定义为系统必须完成的功能和必须具备的品质，是后续设计、开发、测试、验收全流程的核心依据。在软考中级信息系统管理工程师考试中，需求管理属于系统分析与设计模块的核心考点，每年选择题和案例分析题占比约 8-12 分。 需求工程的发展经历了三个阶段：1970-1990 年为萌芽阶段，需求被视为软件开发的前置附属环节；1990-2010 年为体系化阶段，形成了需求获取、分析、规格说明、确认、变更的完整过程框架；2010 年至今为敏捷适配阶段，衍生出用户故事、需求迭代等适配敏捷开发的需求管理方法。本文将从需求层次、核心方法、实施流程等维度系统梳理相关知识点，覆盖考试全部考点要求。

二、需求的层次体系

需求是多层次的结构化概念，从上到下分为业务需求、用户需求、系统需求三个层级，各层级边界清晰且存在严格的推导关系。

（一）业务需求

业务需求是组织机构对系统的高层次目标要求，核心回答 “组织为什么要开发系统” 的问题，来源包括项目投资人、客户单位管理层、市场营销部门等。业务需求的输出是项目视图与范围文档，明确项目的边界、核心价值和总体目标。例如某零售企业提出的 “通过供应链系统将库存周转率提升 30%” 即为典型的业务需求，该需求直接决定了后续所有需求的方向。

（二）用户需求

用户需求描述具体用户要求系统完成的任务，核心回答 “用户用系统能做什么” 的问题，通常通过用户访谈、问卷调查、场景观察等方式获取。用户需求必须体现直接业务价值，避免模糊描述。例如 “仓库管理员可以通过系统查询某类商品的实时库存数量” 即为合格的用户需求。

（三）系统需求

系统需求是从技术角度对软件的具体要求，分为三类：

1. 功能需求：也称为行为需求，规定开发人员必须实现的软件功能，是用户完成任务的载体，例如 “系统在收到查询请求后 1 秒内返回对应商品的库存数值”。
2. 非功能需求：描述系统的质量属性和外部约束，包括易用性、可维护性、效率、兼容性等，例如 “系统页面平均响应时间不超过 2 秒” 属于效率类非功能需求。
3. 约束：对开发过程和产品设计的限制，分为设计约束（例如 “系统必须采用国产化数据库”）和过程约束（例如 “开发过程必须符合等保 2.0 三级要求”）。

需求三层架构示意图，从上到下展示业务需求、用户需求、系统需求的推导关系和包含内容

三、需求转化核心方法：质量功能部署

质量功能部署（QFD）是一种将用户需求转化为软件技术需求的结构化技术，核心目标是最大化用户满意度，被纳入 ISO9000 质量管理体系标准。QFD 将需求分为三类：

（一）常规需求

常规需求是用户明确提出的功能或性能要求，实现程度与用户满意度正相关，实现越多满意度越高。例如用户提出的 “支持按商品名称模糊查询库存” 即为常规需求，若实现该需求用户满意度会对应提升。

（二）期望需求

期望需求是用户默认系统应该具备、但未明确描述的功能，若未实现会导致用户严重不满。例如用户通常默认库存系统支持数据导出功能，若未提供该功能，即使未在需求中明确提及，用户也会产生负面评价。

（三）意外需求

意外需求也称为兴奋需求，属于用户要求范围外的功能，实现后会大幅提升用户满意度，未实现也不影响核心购买决策。例如库存系统额外提供库存积压预警的 AI 分析功能，超出用户预期，属于典型的意外需求。 三类需求的管理策略不同：常规需求需 100% 实现，期望需求需通过行业经验主动识别补充，意外需求需评估投入产出比后选择性实现。

QFD 三类需求与用户满意度关系曲线图，横轴为需求实现程度，纵轴为用户满意度

四、需求工程核心流程

需求工程分为需求开发和需求管理两大分支，包含需求获取、需求分析、需求规格说明、需求确认、需求变更、需求跟踪六个核心环节。

（一）需求获取

需求获取是开发人员与用户之间的交流过程，核心目标是全面收集需求信息，常见方法包括用户访谈、问卷调查、现场观察、竞品分析、文档考古等。需求获取阶段的常见风险是领域理解偏差，该问题通常在开发后期才会暴露，会导致 30% 以上的项目延期。例如某医疗系统项目中，开发人员误将 “患者就诊记录” 理解为单次就诊信息，而用户实际需求是包含历史所有就诊记录，该偏差直到测试阶段才发现，导致项目延期 2 个月。

（二）需求分析

需求分析是对获取的需求进行提炼、审查的过程，输出的合格需求需具备无二义性、完整性、一致性、可测试性、可跟踪性、正确性、必要性 7 个核心特性。主流分析方法分为结构化分析和面向对象分析两类：

1. 结构化分析（SA）  结构化分析是面向数据流的分析方法，核心是数据字典，包含三个层次的模型：  （1）数据模型：采用实体关系图（E-R 图）表示，核心元素为实体（矩形）、属性（椭圆形）、联系（菱形，标注 1:1、1:n、m:n 三类联系类型），用于描述数据的静态结构。  （2）功能模型：采用数据流图（DFD）表示，核心元素为数据流（箭头）、处理（矩形）、数据存储（平行线）、外部项（圆角矩形），从数据传递和加工角度描述系统功能。DFD 建模步骤为：确定系统范围→构建顶层 DFD→逐层分解得到分层 DFD→检查确认一致性。  （3）行为模型：采用状态转换图（STD）表示，核心元素为初态（实心圆）、中间状态（圆角矩形）、终态（同心圆），描述系统状态的转换规则。  数据字典是结构化分析的核心，用于定义和描述数据流图中的所有元素，包括数据项、数据结构、数据流、数据存储、处理过程五类条目。
2. 面向对象分析（OOA）  面向对象分析是基于对象的分析方法，核心是识别问题域中的类和对象，模型包含主题层、对象类层、结构层、属性层、服务层 5 个层次，以及标识对象类、标识结构、定义主题、定义属性、定义服务 5 个核心活动。OOA 的基本原则包括抽象（核心为数据抽象）、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析 9 项。OOA 的实施步骤为：确定对象和类→确定分类结构和组装结构→定义主题→定义属性→定义方法。  两类分析方法的对比如下：结构化分析适合数据流程清晰的事务型系统，优点是学习成本低、模型直观，缺点是扩展性弱，应对需求变更的成本高；面向对象分析适合业务逻辑复杂的系统，优点是复用性高、扩展性强，缺点是建模难度大，对分析人员能力要求高。

结构化分析方法体系框架图，展示数据字典、E-R 图、DFD、STD 的关联关系

（三）需求规格说明书

软件需求规格说明书（SRS）是需求分析阶段的最终输出文档，是后续开发、测试、验收的核心依据，符合 GB/T 9385-2008《计算机软件需求规格说明规范》要求。SRS 的核心内容包括：范围、引用文件、需求描述、合格性规定、需求可追踪性、尚未解决的问题、注解、附录 8 个部分。

（四）需求确认

需求确认也称为需求验证，核心目标是确保 SRS 符合需求的良好特性，通过需求评审和需求测试两类活动完成。需求评审是由项目干系人共同参与的文档审查活动，分为正式评审和非正式评审；需求测试是通过编写测试用例验证需求的可测试性和正确性。

（五）需求变更

需求变更是软件开发中的常见场景，需遵循严格的变更控制流程：

1. 问题分析和变更描述：申请人提交书面变更申请，明确变更内容和原因。
2. 变更分析和成本计算：技术团队评估变更的技术可行性、对进度、成本、质量的影响，输出评估报告。
3. 变更决策：由变更控制委员会（CCB）评审变更申请，决定是否批准变更。CCB 是决策机构而非作业机构，成员通常包含用户代表、项目方代表、技术负责人，负责裁定变更是否实施，但不提出具体变更方案。
4. 变更实现：开发团队根据批准的变更方案实施变更，同步更新相关文档和代码。

（六）需求跟踪

需求跟踪采用双向跟踪机制，确保需求与后续工作成果的一致性：正向跟踪是检查每个需求是否在后续的设计、开发、测试环节都得到实现；逆向跟踪是检查设计文档、代码、测试用例是否都能追溯到对应的需求来源。需求跟踪通过需求跟踪矩阵实现，矩阵中记录每个需求与设计、编码、测试工作成果的对应关系。

需求变更控制流程图，展示从申请到实现的全流程节点和参与角色

五、需求管理工具与体系建设

企业级需求管理体系的建设需匹配组织的开发模式和业务特点，核心工具和技术包括：

（一）主流需求管理工具

1. 文档类工具：包括 Word、Excel，适合小型项目，优点是成本低、易于使用，缺点是版本管理困难、跟踪能力弱。
2. 专业需求管理工具：包括 Jira、Confluence、禅道、IBM Rational DOORS，支持需求版本管理、需求跟踪、变更流程自动化，适合中大型项目，优点是管理能力强、集成度高，缺点是学习成本高、 license 成本高。
3. 敏捷需求工具：包括 Trello、PingCode，支持用户故事管理、迭代需求规划，适合敏捷开发项目。

（二）需求管理体系优化策略

1. 建立需求分级分类机制：根据需求的重要性和紧急程度分为 P0-P3 四个优先级，优先保障核心需求的实现。
2. 建立需求评审准入准出标准：明确需求文档必须达到的质量要求才能进入评审环节，评审通过率达到 90% 以上才能进入开发阶段。
3. 定期开展需求回溯：每个迭代结束后复盘需求实现情况，分析需求偏差的原因，优化需求管理流程。

企业级需求管理体系框架图，展示组织层、流程层、工具层的组成部分

六、前沿发展与考试趋势

当前需求管理领域的发展趋势主要包括三个方向：

1. 敏捷需求管理：采用用户故事、需求拆分、迭代规划等方法，适配敏捷开发的快速迭代需求，用户故事的 3C 要素（卡片、对话、确认）已成为近年考试的新增考点。
2. AI 辅助需求分析：通过大语言模型自动提取需求文档中的核心要素、生成需求跟踪矩阵、识别需求冲突，大幅提升需求分析效率。
3. 需求工程标准化：国内已发布《信息技术 软件工程 需求工程》GB/T 38634-2020 国家标准，对需求工程的过程、方法、文档提出明确规范。  在软考中级考试中，需求模块的考点呈现三个变化：一是结构化分析的 E-R 图、DFD 图的绘制和正误判断在案例分析题中出现频率提升；二是需求变更流程、CCB 的职责是高频考点，通常结合项目管理案例考察；三是 QFD 的三类需求区分、需求跟踪的双向机制是选择题的常考易错点。

需求管理技术演进路线图，展示从传统方法到敏捷、AI 辅助的发展历程

七、总结与备考建议

（一）核心知识点提炼

1. 需求分为业务需求、用户需求、系统需求三层，系统需求包含功能需求、非功能需求、约束三类。
2. QFD 将需求分为常规需求、期望需求、意外需求，其中期望需求未实现会导致用户不满。
3. 结构化分析的核心是数据字典，包含 E-R 图（数据模型）、DFD（功能模型）、STD（行为模型）三个模型。
4. 需求变更需遵循变更控制流程，由 CCB 决策是否批准变更，CCB 是决策机构而非作业机构。
5. 需求跟踪采用双向跟踪机制，通过需求跟踪矩阵实现需求与工作成果的对应。

（二）考试重点提示

高频考点包括：需求三层架构的区分、系统需求的三类组成、QFD 三类需求的特点、结构化分析的三个模型及元素、DFD 的建模步骤、CCB 的职责、需求双向跟踪的含义。易错点包括：业务需求与用户需求的区分、期望需求与意外需求的区分、DFD 元素的正误判断、CCB 的职责边界。

（三）实践与备考建议

1. 备考阶段需重点掌握 E-R 图、DFD 的绘制方法，能够识别常见的图错误，例如数据流未经过处理、数据存储只有输入没有输出等。
2. 实践中需求获取阶段需覆盖所有关键干系人，避免遗漏用户的期望需求，降低后续变更风险。
3. 需求变更必须严格执行流程，严禁私下变更需求，所有变更必须留下书面记录并同步更新需求文档和跟踪矩阵。

八、课后小测

系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和（）等。 A. 期望需求 B. 性能 C. 约束 D. 逻辑 答案：C。解析：系统需求包括功能需求、非功能需求和约束三类，期望需求属于 QFD 的需求分类，性能属于非功能需求的子类，逻辑不属于系统需求的分类。