一、引言软件需求是软件开发全生命周期的起始环节定义为系统必须完成的功能和必须具备的品质是后续设计、开发、测试、验收全流程的核心依据。在软考中级信息系统管理工程师考试中需求管理属于系统分析与设计模块的核心考点每年选择题和案例分析题占比约 8-12 分。需求工程的发展经历了三个阶段1970-1990 年为萌芽阶段需求被视为软件开发的前置附属环节1990-2010 年为体系化阶段形成了需求获取、分析、规格说明、确认、变更的完整过程框架2010 年至今为敏捷适配阶段衍生出用户故事、需求迭代等适配敏捷开发的需求管理方法。本文将从需求层次、核心方法、实施流程等维度系统梳理相关知识点覆盖考试全部考点要求。二、需求的层次体系需求是多层次的结构化概念从上到下分为业务需求、用户需求、系统需求三个层级各层级边界清晰且存在严格的推导关系。一业务需求业务需求是组织机构对系统的高层次目标要求核心回答 “组织为什么要开发系统” 的问题来源包括项目投资人、客户单位管理层、市场营销部门等。业务需求的输出是项目视图与范围文档明确项目的边界、核心价值和总体目标。例如某零售企业提出的 “通过供应链系统将库存周转率提升 30%” 即为典型的业务需求该需求直接决定了后续所有需求的方向。二用户需求用户需求描述具体用户要求系统完成的任务核心回答 “用户用系统能做什么” 的问题通常通过用户访谈、问卷调查、场景观察等方式获取。用户需求必须体现直接业务价值避免模糊描述。例如 “仓库管理员可以通过系统查询某类商品的实时库存数量” 即为合格的用户需求。三系统需求系统需求是从技术角度对软件的具体要求分为三类功能需求也称为行为需求规定开发人员必须实现的软件功能是用户完成任务的载体例如 “系统在收到查询请求后 1 秒内返回对应商品的库存数值”。非功能需求描述系统的质量属性和外部约束包括易用性、可维护性、效率、兼容性等例如 “系统页面平均响应时间不超过 2 秒” 属于效率类非功能需求。约束对开发过程和产品设计的限制分为设计约束例如 “系统必须采用国产化数据库”和过程约束例如 “开发过程必须符合等保 2.0 三级要求”。需求三层架构示意图从上到下展示业务需求、用户需求、系统需求的推导关系和包含内容三、需求转化核心方法质量功能部署质量功能部署QFD是一种将用户需求转化为软件技术需求的结构化技术核心目标是最大化用户满意度被纳入 ISO9000 质量管理体系标准。QFD 将需求分为三类一常规需求常规需求是用户明确提出的功能或性能要求实现程度与用户满意度正相关实现越多满意度越高。例如用户提出的 “支持按商品名称模糊查询库存” 即为常规需求若实现该需求用户满意度会对应提升。二期望需求期望需求是用户默认系统应该具备、但未明确描述的功能若未实现会导致用户严重不满。例如用户通常默认库存系统支持数据导出功能若未提供该功能即使未在需求中明确提及用户也会产生负面评价。三意外需求意外需求也称为兴奋需求属于用户要求范围外的功能实现后会大幅提升用户满意度未实现也不影响核心购买决策。例如库存系统额外提供库存积压预警的 AI 分析功能超出用户预期属于典型的意外需求。三类需求的管理策略不同常规需求需 100% 实现期望需求需通过行业经验主动识别补充意外需求需评估投入产出比后选择性实现。QFD 三类需求与用户满意度关系曲线图横轴为需求实现程度纵轴为用户满意度四、需求工程核心流程需求工程分为需求开发和需求管理两大分支包含需求获取、需求分析、需求规格说明、需求确认、需求变更、需求跟踪六个核心环节。一需求获取需求获取是开发人员与用户之间的交流过程核心目标是全面收集需求信息常见方法包括用户访谈、问卷调查、现场观察、竞品分析、文档考古等。需求获取阶段的常见风险是领域理解偏差该问题通常在开发后期才会暴露会导致 30% 以上的项目延期。例如某医疗系统项目中开发人员误将 “患者就诊记录” 理解为单次就诊信息而用户实际需求是包含历史所有就诊记录该偏差直到测试阶段才发现导致项目延期 2 个月。二需求分析需求分析是对获取的需求进行提炼、审查的过程输出的合格需求需具备无二义性、完整性、一致性、可测试性、可跟踪性、正确性、必要性 7 个核心特性。主流分析方法分为结构化分析和面向对象分析两类结构化分析SA结构化分析是面向数据流的分析方法核心是数据字典包含三个层次的模型1数据模型采用实体关系图E-R 图表示核心元素为实体矩形、属性椭圆形、联系菱形标注 1:1、1:n、m:n 三类联系类型用于描述数据的静态结构。2功能模型采用数据流图DFD表示核心元素为数据流箭头、处理矩形、数据存储平行线、外部项圆角矩形从数据传递和加工角度描述系统功能。DFD 建模步骤为确定系统范围→构建顶层 DFD→逐层分解得到分层 DFD→检查确认一致性。3行为模型采用状态转换图STD表示核心元素为初态实心圆、中间状态圆角矩形、终态同心圆描述系统状态的转换规则。数据字典是结构化分析的核心用于定义和描述数据流图中的所有元素包括数据项、数据结构、数据流、数据存储、处理过程五类条目。面向对象分析OOA面向对象分析是基于对象的分析方法核心是识别问题域中的类和对象模型包含主题层、对象类层、结构层、属性层、服务层 5 个层次以及标识对象类、标识结构、定义主题、定义属性、定义服务 5 个核心活动。OOA 的基本原则包括抽象核心为数据抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析 9 项。OOA 的实施步骤为确定对象和类→确定分类结构和组装结构→定义主题→定义属性→定义方法。两类分析方法的对比如下结构化分析适合数据流程清晰的事务型系统优点是学习成本低、模型直观缺点是扩展性弱应对需求变更的成本高面向对象分析适合业务逻辑复杂的系统优点是复用性高、扩展性强缺点是建模难度大对分析人员能力要求高。结构化分析方法体系框架图展示数据字典、E-R 图、DFD、STD 的关联关系三需求规格说明书软件需求规格说明书SRS是需求分析阶段的最终输出文档是后续开发、测试、验收的核心依据符合 GB/T 9385-2008《计算机软件需求规格说明规范》要求。SRS 的核心内容包括范围、引用文件、需求描述、合格性规定、需求可追踪性、尚未解决的问题、注解、附录 8 个部分。四需求确认需求确认也称为需求验证核心目标是确保 SRS 符合需求的良好特性通过需求评审和需求测试两类活动完成。需求评审是由项目干系人共同参与的文档审查活动分为正式评审和非正式评审需求测试是通过编写测试用例验证需求的可测试性和正确性。五需求变更需求变更是软件开发中的常见场景需遵循严格的变更控制流程问题分析和变更描述申请人提交书面变更申请明确变更内容和原因。变更分析和成本计算技术团队评估变更的技术可行性、对进度、成本、质量的影响输出评估报告。变更决策由变更控制委员会CCB评审变更申请决定是否批准变更。CCB 是决策机构而非作业机构成员通常包含用户代表、项目方代表、技术负责人负责裁定变更是否实施但不提出具体变更方案。变更实现开发团队根据批准的变更方案实施变更同步更新相关文档和代码。六需求跟踪需求跟踪采用双向跟踪机制确保需求与后续工作成果的一致性正向跟踪是检查每个需求是否在后续的设计、开发、测试环节都得到实现逆向跟踪是检查设计文档、代码、测试用例是否都能追溯到对应的需求来源。需求跟踪通过需求跟踪矩阵实现矩阵中记录每个需求与设计、编码、测试工作成果的对应关系。需求变更控制流程图展示从申请到实现的全流程节点和参与角色五、需求管理工具与体系建设企业级需求管理体系的建设需匹配组织的开发模式和业务特点核心工具和技术包括一主流需求管理工具文档类工具包括 Word、Excel适合小型项目优点是成本低、易于使用缺点是版本管理困难、跟踪能力弱。专业需求管理工具包括 Jira、Confluence、禅道、IBM Rational DOORS支持需求版本管理、需求跟踪、变更流程自动化适合中大型项目优点是管理能力强、集成度高缺点是学习成本高、 license 成本高。敏捷需求工具包括 Trello、PingCode支持用户故事管理、迭代需求规划适合敏捷开发项目。二需求管理体系优化策略建立需求分级分类机制根据需求的重要性和紧急程度分为 P0-P3 四个优先级优先保障核心需求的实现。建立需求评审准入准出标准明确需求文档必须达到的质量要求才能进入评审环节评审通过率达到 90% 以上才能进入开发阶段。定期开展需求回溯每个迭代结束后复盘需求实现情况分析需求偏差的原因优化需求管理流程。企业级需求管理体系框架图展示组织层、流程层、工具层的组成部分六、前沿发展与考试趋势当前需求管理领域的发展趋势主要包括三个方向敏捷需求管理采用用户故事、需求拆分、迭代规划等方法适配敏捷开发的快速迭代需求用户故事的 3C 要素卡片、对话、确认已成为近年考试的新增考点。AI 辅助需求分析通过大语言模型自动提取需求文档中的核心要素、生成需求跟踪矩阵、识别需求冲突大幅提升需求分析效率。需求工程标准化国内已发布《信息技术 软件工程 需求工程》GB/T 38634-2020 国家标准对需求工程的过程、方法、文档提出明确规范。在软考中级考试中需求模块的考点呈现三个变化一是结构化分析的 E-R 图、DFD 图的绘制和正误判断在案例分析题中出现频率提升二是需求变更流程、CCB 的职责是高频考点通常结合项目管理案例考察三是 QFD 的三类需求区分、需求跟踪的双向机制是选择题的常考易错点。需求管理技术演进路线图展示从传统方法到敏捷、AI 辅助的发展历程七、总结与备考建议一核心知识点提炼需求分为业务需求、用户需求、系统需求三层系统需求包含功能需求、非功能需求、约束三类。QFD 将需求分为常规需求、期望需求、意外需求其中期望需求未实现会导致用户不满。结构化分析的核心是数据字典包含 E-R 图数据模型、DFD功能模型、STD行为模型三个模型。需求变更需遵循变更控制流程由 CCB 决策是否批准变更CCB 是决策机构而非作业机构。需求跟踪采用双向跟踪机制通过需求跟踪矩阵实现需求与工作成果的对应。二考试重点提示高频考点包括需求三层架构的区分、系统需求的三类组成、QFD 三类需求的特点、结构化分析的三个模型及元素、DFD 的建模步骤、CCB 的职责、需求双向跟踪的含义。易错点包括业务需求与用户需求的区分、期望需求与意外需求的区分、DFD 元素的正误判断、CCB 的职责边界。三实践与备考建议备考阶段需重点掌握 E-R 图、DFD 的绘制方法能够识别常见的图错误例如数据流未经过处理、数据存储只有输入没有输出等。实践中需求获取阶段需覆盖所有关键干系人避免遗漏用户的期望需求降低后续变更风险。需求变更必须严格执行流程严禁私下变更需求所有变更必须留下书面记录并同步更新需求文档和跟踪矩阵。八、课后小测系统需求是从系统的角度来说明软件的需求包括功能需求、非功能需求和等。A. 期望需求B. 性能C. 约束D. 逻辑答案C。解析系统需求包括功能需求、非功能需求和约束三类期望需求属于 QFD 的需求分类性能属于非功能需求的子类逻辑不属于系统需求的分类。
一、引言软件需求是软件开发全生命周期的起始环节定义为系统必须完成的功能和必须具备的品质是后续设计、开发、测试、验收全流程的核心依据。在软考中级信息系统管理工程师考试中需求管理属于系统分析与设计模块的核心考点每年选择题和案例分析题占比约 8-12 分。需求工程的发展经历了三个阶段1970-1990 年为萌芽阶段需求被视为软件开发的前置附属环节1990-2010 年为体系化阶段形成了需求获取、分析、规格说明、确认、变更的完整过程框架2010 年至今为敏捷适配阶段衍生出用户故事、需求迭代等适配敏捷开发的需求管理方法。本文将从需求层次、核心方法、实施流程等维度系统梳理相关知识点覆盖考试全部考点要求。二、需求的层次体系需求是多层次的结构化概念从上到下分为业务需求、用户需求、系统需求三个层级各层级边界清晰且存在严格的推导关系。一业务需求业务需求是组织机构对系统的高层次目标要求核心回答 “组织为什么要开发系统” 的问题来源包括项目投资人、客户单位管理层、市场营销部门等。业务需求的输出是项目视图与范围文档明确项目的边界、核心价值和总体目标。例如某零售企业提出的 “通过供应链系统将库存周转率提升 30%” 即为典型的业务需求该需求直接决定了后续所有需求的方向。二用户需求用户需求描述具体用户要求系统完成的任务核心回答 “用户用系统能做什么” 的问题通常通过用户访谈、问卷调查、场景观察等方式获取。用户需求必须体现直接业务价值避免模糊描述。例如 “仓库管理员可以通过系统查询某类商品的实时库存数量” 即为合格的用户需求。三系统需求系统需求是从技术角度对软件的具体要求分为三类功能需求也称为行为需求规定开发人员必须实现的软件功能是用户完成任务的载体例如 “系统在收到查询请求后 1 秒内返回对应商品的库存数值”。非功能需求描述系统的质量属性和外部约束包括易用性、可维护性、效率、兼容性等例如 “系统页面平均响应时间不超过 2 秒” 属于效率类非功能需求。约束对开发过程和产品设计的限制分为设计约束例如 “系统必须采用国产化数据库”和过程约束例如 “开发过程必须符合等保 2.0 三级要求”。需求三层架构示意图从上到下展示业务需求、用户需求、系统需求的推导关系和包含内容三、需求转化核心方法质量功能部署质量功能部署QFD是一种将用户需求转化为软件技术需求的结构化技术核心目标是最大化用户满意度被纳入 ISO9000 质量管理体系标准。QFD 将需求分为三类一常规需求常规需求是用户明确提出的功能或性能要求实现程度与用户满意度正相关实现越多满意度越高。例如用户提出的 “支持按商品名称模糊查询库存” 即为常规需求若实现该需求用户满意度会对应提升。二期望需求期望需求是用户默认系统应该具备、但未明确描述的功能若未实现会导致用户严重不满。例如用户通常默认库存系统支持数据导出功能若未提供该功能即使未在需求中明确提及用户也会产生负面评价。三意外需求意外需求也称为兴奋需求属于用户要求范围外的功能实现后会大幅提升用户满意度未实现也不影响核心购买决策。例如库存系统额外提供库存积压预警的 AI 分析功能超出用户预期属于典型的意外需求。三类需求的管理策略不同常规需求需 100% 实现期望需求需通过行业经验主动识别补充意外需求需评估投入产出比后选择性实现。QFD 三类需求与用户满意度关系曲线图横轴为需求实现程度纵轴为用户满意度四、需求工程核心流程需求工程分为需求开发和需求管理两大分支包含需求获取、需求分析、需求规格说明、需求确认、需求变更、需求跟踪六个核心环节。一需求获取需求获取是开发人员与用户之间的交流过程核心目标是全面收集需求信息常见方法包括用户访谈、问卷调查、现场观察、竞品分析、文档考古等。需求获取阶段的常见风险是领域理解偏差该问题通常在开发后期才会暴露会导致 30% 以上的项目延期。例如某医疗系统项目中开发人员误将 “患者就诊记录” 理解为单次就诊信息而用户实际需求是包含历史所有就诊记录该偏差直到测试阶段才发现导致项目延期 2 个月。二需求分析需求分析是对获取的需求进行提炼、审查的过程输出的合格需求需具备无二义性、完整性、一致性、可测试性、可跟踪性、正确性、必要性 7 个核心特性。主流分析方法分为结构化分析和面向对象分析两类结构化分析SA结构化分析是面向数据流的分析方法核心是数据字典包含三个层次的模型1数据模型采用实体关系图E-R 图表示核心元素为实体矩形、属性椭圆形、联系菱形标注 1:1、1:n、m:n 三类联系类型用于描述数据的静态结构。2功能模型采用数据流图DFD表示核心元素为数据流箭头、处理矩形、数据存储平行线、外部项圆角矩形从数据传递和加工角度描述系统功能。DFD 建模步骤为确定系统范围→构建顶层 DFD→逐层分解得到分层 DFD→检查确认一致性。3行为模型采用状态转换图STD表示核心元素为初态实心圆、中间状态圆角矩形、终态同心圆描述系统状态的转换规则。数据字典是结构化分析的核心用于定义和描述数据流图中的所有元素包括数据项、数据结构、数据流、数据存储、处理过程五类条目。面向对象分析OOA面向对象分析是基于对象的分析方法核心是识别问题域中的类和对象模型包含主题层、对象类层、结构层、属性层、服务层 5 个层次以及标识对象类、标识结构、定义主题、定义属性、定义服务 5 个核心活动。OOA 的基本原则包括抽象核心为数据抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析 9 项。OOA 的实施步骤为确定对象和类→确定分类结构和组装结构→定义主题→定义属性→定义方法。两类分析方法的对比如下结构化分析适合数据流程清晰的事务型系统优点是学习成本低、模型直观缺点是扩展性弱应对需求变更的成本高面向对象分析适合业务逻辑复杂的系统优点是复用性高、扩展性强缺点是建模难度大对分析人员能力要求高。结构化分析方法体系框架图展示数据字典、E-R 图、DFD、STD 的关联关系三需求规格说明书软件需求规格说明书SRS是需求分析阶段的最终输出文档是后续开发、测试、验收的核心依据符合 GB/T 9385-2008《计算机软件需求规格说明规范》要求。SRS 的核心内容包括范围、引用文件、需求描述、合格性规定、需求可追踪性、尚未解决的问题、注解、附录 8 个部分。四需求确认需求确认也称为需求验证核心目标是确保 SRS 符合需求的良好特性通过需求评审和需求测试两类活动完成。需求评审是由项目干系人共同参与的文档审查活动分为正式评审和非正式评审需求测试是通过编写测试用例验证需求的可测试性和正确性。五需求变更需求变更是软件开发中的常见场景需遵循严格的变更控制流程问题分析和变更描述申请人提交书面变更申请明确变更内容和原因。变更分析和成本计算技术团队评估变更的技术可行性、对进度、成本、质量的影响输出评估报告。变更决策由变更控制委员会CCB评审变更申请决定是否批准变更。CCB 是决策机构而非作业机构成员通常包含用户代表、项目方代表、技术负责人负责裁定变更是否实施但不提出具体变更方案。变更实现开发团队根据批准的变更方案实施变更同步更新相关文档和代码。六需求跟踪需求跟踪采用双向跟踪机制确保需求与后续工作成果的一致性正向跟踪是检查每个需求是否在后续的设计、开发、测试环节都得到实现逆向跟踪是检查设计文档、代码、测试用例是否都能追溯到对应的需求来源。需求跟踪通过需求跟踪矩阵实现矩阵中记录每个需求与设计、编码、测试工作成果的对应关系。需求变更控制流程图展示从申请到实现的全流程节点和参与角色五、需求管理工具与体系建设企业级需求管理体系的建设需匹配组织的开发模式和业务特点核心工具和技术包括一主流需求管理工具文档类工具包括 Word、Excel适合小型项目优点是成本低、易于使用缺点是版本管理困难、跟踪能力弱。专业需求管理工具包括 Jira、Confluence、禅道、IBM Rational DOORS支持需求版本管理、需求跟踪、变更流程自动化适合中大型项目优点是管理能力强、集成度高缺点是学习成本高、 license 成本高。敏捷需求工具包括 Trello、PingCode支持用户故事管理、迭代需求规划适合敏捷开发项目。二需求管理体系优化策略建立需求分级分类机制根据需求的重要性和紧急程度分为 P0-P3 四个优先级优先保障核心需求的实现。建立需求评审准入准出标准明确需求文档必须达到的质量要求才能进入评审环节评审通过率达到 90% 以上才能进入开发阶段。定期开展需求回溯每个迭代结束后复盘需求实现情况分析需求偏差的原因优化需求管理流程。企业级需求管理体系框架图展示组织层、流程层、工具层的组成部分六、前沿发展与考试趋势当前需求管理领域的发展趋势主要包括三个方向敏捷需求管理采用用户故事、需求拆分、迭代规划等方法适配敏捷开发的快速迭代需求用户故事的 3C 要素卡片、对话、确认已成为近年考试的新增考点。AI 辅助需求分析通过大语言模型自动提取需求文档中的核心要素、生成需求跟踪矩阵、识别需求冲突大幅提升需求分析效率。需求工程标准化国内已发布《信息技术 软件工程 需求工程》GB/T 38634-2020 国家标准对需求工程的过程、方法、文档提出明确规范。在软考中级考试中需求模块的考点呈现三个变化一是结构化分析的 E-R 图、DFD 图的绘制和正误判断在案例分析题中出现频率提升二是需求变更流程、CCB 的职责是高频考点通常结合项目管理案例考察三是 QFD 的三类需求区分、需求跟踪的双向机制是选择题的常考易错点。需求管理技术演进路线图展示从传统方法到敏捷、AI 辅助的发展历程七、总结与备考建议一核心知识点提炼需求分为业务需求、用户需求、系统需求三层系统需求包含功能需求、非功能需求、约束三类。QFD 将需求分为常规需求、期望需求、意外需求其中期望需求未实现会导致用户不满。结构化分析的核心是数据字典包含 E-R 图数据模型、DFD功能模型、STD行为模型三个模型。需求变更需遵循变更控制流程由 CCB 决策是否批准变更CCB 是决策机构而非作业机构。需求跟踪采用双向跟踪机制通过需求跟踪矩阵实现需求与工作成果的对应。二考试重点提示高频考点包括需求三层架构的区分、系统需求的三类组成、QFD 三类需求的特点、结构化分析的三个模型及元素、DFD 的建模步骤、CCB 的职责、需求双向跟踪的含义。易错点包括业务需求与用户需求的区分、期望需求与意外需求的区分、DFD 元素的正误判断、CCB 的职责边界。三实践与备考建议备考阶段需重点掌握 E-R 图、DFD 的绘制方法能够识别常见的图错误例如数据流未经过处理、数据存储只有输入没有输出等。实践中需求获取阶段需覆盖所有关键干系人避免遗漏用户的期望需求降低后续变更风险。需求变更必须严格执行流程严禁私下变更需求所有变更必须留下书面记录并同步更新需求文档和跟踪矩阵。八、课后小测系统需求是从系统的角度来说明软件的需求包括功能需求、非功能需求和等。A. 期望需求B. 性能C. 约束D. 逻辑答案C。解析系统需求包括功能需求、非功能需求和约束三类期望需求属于 QFD 的需求分类性能属于非功能需求的子类逻辑不属于系统需求的分类。
