【软考高级·系统分析师全链路通关实战】第 26 篇需求工程总论——需求层次与需求工程过程本系列定位面向有开发经验、从零备考软考高级「系统分析师」的工程师以《系统分析师教程第 2 版》为主线按「综合知识 → 案例分析 → 论文」三科组织需求工程与 UML 建模深拆60 篇带你从考试小白到三科同过。本篇你将学到需求的严格定义与三个层次业务需求、用户需求、系统需求功能 非功能需求工程过程的五大活动获取 → 分析 → 规格说明 → 验证 → 管理及其螺旋迭代的本质需求错误的高昂代价1:10:100 的错误放大规律论文金句素材系统分析师在需求工程中的角色定位与能力要求云诊通需求工程全流程预告后续七篇的实战主线图学完本篇你将建立起整个模块六第 26-33 篇共 8 篇的知识地图——需求工程是系统分析师区别于其他高级证书的核心主战场这 8 篇值得你投入全系列最多的复习时间。考点热力表|| 知识点 | 综合知识 | 案例分析 | 论文 ||--------|:—:—:—| 需求的定义与层次 | ★★★ | ★★ | ★★ || 需求工程过程五活动 | ★★★ | ★★★ | ★★★ || 功能需求与非功能需求辨析 | ★★★ | ★★★ | ★★ || 需求错误代价与放大规律 | ★ | ★ | ★★★ || 需求工程与系统生命周期的关系 | ★★ | ★ | ★★ |一、什么是需求定义与层次1.1 一个严格的定义IEEE 对需求的经典定义需求是为了解决用户的问题或达成业务目标系统必须满足的条件或能力。这个定义有两个要点需求锚定在「用户的问题/业务目标」上不是拍脑袋的功能清单且表现为「系统必须满足的条件或能力」可验证的承诺。工程师最常见的误区是把需求等同于「用户要的功能清单」。功能只是需求的解决方案形态真正的需求是问题与约束本身——患者说「我要在手机上看到报告」其背后的问题是「跑医院取纸质报告太耗时」。把需求停在功能层就会失去判断「这个功能是否真的解决问题」的依据。1.2 需求的三个层次层次回答的问题典型表述文档载体业务需求为什么要建这个系统「将复诊患者线上分流比例提升至 40%」项目章程/愿景文档用户需求各类用户要用系统完成什么任务「患者能在线预约 7 家医院的号源」用例/场景描述系统需求系统必须具备的条件与能力功能 非功能「系统在 3 秒内返回可用号源列表」SRS 需求规格说明书三层次是逐步求精的关系业务需求定方向承接第 23 篇的战略推导用户需求定任务系统需求定可实现的规格。综合知识常考「给一句表述判断属于哪一层」——判据是抽象层级谈目标与价值是业务层谈用户任务是用户层谈系统行为与质量指标是系统层。系统需求再分两支功能需求系统要做什么预约、问诊、开方与非功能需求系统做得怎么样性能、安全、可用性、合规约束。非功能需求常被低估但云诊通恰恰是「非功能决定成败」的典型——等保三级、处方实时上报、留痕审计全部是非功能需求第 28 篇详述分类框架。求精求精求精业务需求为什么建用户需求用户要完成什么任务功能需求系统做什么非功能需求做得怎么样: 质量约束SRS 需求规格说明书外部约束牌照/等保/监管二、需求工程过程五大活动2.1 过程总览需求工程Requirements Engineering是应用于需求活动的、相互衔接的系统化过程教材将其划分为五大活动活动核心任务产出详述篇目需求获取从干系人处收集原始需求原始需求条目第 27 篇需求分析归类、建模、协商优先级、消解冲突需求模型 分析后需求第 28 篇需求规格说明按规范文档化SRS第 29 篇需求验证评审、测试化检验需求的正确性评审通过的需求第 30 篇需求管理基线、变更控制、双向跟踪需求基线 跟踪矩阵第 31 篇2.2 螺旋迭代的本质教科书式的过程图是一条流水线但真实的需求工程是迭代螺旋分析中发现的矛盾要回到获取补充提问验证中暴露的歧义要回到规格说明修改管理中登记的变更会触发新一轮获取与分析。理解这一点的实践意义不要追求「一次把需求做完」而要在每轮迭代中收敛——每轮把不明确、不一致、不完整的问题减少一半3-4 轮即可达到可基线化的程度。迭代不等于无边界。云诊通的做法需求获取按业务域分波次推进预约挂号域 → 问诊域 → 处方域……每个业务域内部走完「获取→分析→规格→验证」小循环全部域收敛后统一建立需求基线第 31 篇再进入受控变更阶段。不通过: 修改后重验通过变更请求批准发现信息缺口需求获取第27篇需求分析第28篇需求规格说明第29篇需求验证第30篇需求基线第31篇管理变更控制评估-决策-实施2.3 需求工程的「V 字」位置需求工程处于系统生命周期的最上游但它的影响贯穿全程需求是测试依据验收测试用例从需求导出第 30 篇、设计输入架构驱动力来自非功能需求第 34 篇、项目管理基线范围、估算、跟踪都以需求为基准第 20 篇。一句话需求质量决定了下游一切工作的上限。三、需求错误的代价1:10:100 规律软件工程的大量实证研究给出一个稳定的量级规律在需求阶段修复一个错误的成本约为编码阶段的 1/10约为运行维护阶段的 1/100 甚至更低。原因有两层返工链长度需求错误在编码后发现要回退「需求修改 → 设计修改 → 代码修改 → 回归测试」全链条在运行期发现还要加上现场处置、数据修复、用户沟通的成本错误放大一个错误需求会被下游多个设计决策和代码模块继承放大成多处缺陷云诊通的真实风险场景若「处方必须实时上报」这条合规需求在获取阶段被遗漏等到上线前联调才发现则处方域的数据模型缺上报流水表、服务交互缺异步上报链路、安全设计缺上报链路的等保审计全部要返工且压缩本就紧张的测试窗口。反之这条需求在评审阶段第 30 篇被监管方代表一句「上报及时率怎么保证」揪出修复成本只是一次需求澄清会议。论文用法这段 1:10:100 规律 项目中的具体反例/正例是需求工程类论文如「论需求获取方法」「论需求管理」论证「我为什么在需求上投入重兵」的标准理论支点务必内化成自己的语言。四、系统分析师在需求工程中的角色需求工程不是分析师一个人的独角戏但分析师是全程的组织者与技术责任人对业务方需求的翻译者与追问者——把口语诉求转成可验证条目把「系统要快」追问成「95% 的号源查询在 3 秒内返回」对开发团队需求的解释者与守门人——澄清歧义、评审设计是否符合需求、拒绝无变更手续的范围扩张对项目治理基线与变更流程的执行者——维护跟踪矩阵让每条需求「来有影去有踪」第 31 篇对合规与风险刚性约束的第一识别人——牌照、等保、监管上报这类约束必须在需求中显式建模不能默认「上线再说」能力要求对应了本系列模块的编排沟通与引导第 27 篇、抽象与建模第 25、28、32 篇、文档工程第 29 篇、质量意识第 30 篇、治理意识第 31 篇。案例分析第 1 题通常考需求工程正是对这些能力的纸面检验。五、云诊通需求工程全程预告云诊通的需求工程按 11 个月工期中的前 4 个月组织第 1-2 月集中获取与分析、第 3-4 月规格化与验证迭代期受变更控制后续七篇将用同一项目完整走一遍篇目云诊通实战内容第 27 篇面向六类干系人的差异化获取策略医生忙、监管刚第 28 篇100 条原始需求的归类与「实时性 vs 留痕合规」冲突调解第 29 篇在线问诊功能需求的 SRS 规范写法第 30 篇问诊需求评审会发现的三类典型缺陷第 31 篇监管新规引发的处方需求变更全过程第 32 篇在线问诊用例 → 边界/控制/实体分析类推导第 33 篇需求工程案例真题的两道完整演练需求总量口径六类干系人 × 七大业务域初步获取原始需求 100 余条经分析与合并收敛为 80 余条系统需求功能 60 余、非功能 20 余这个数字链条在后续篇目保持一致。需求工程知识地图第26-33篇总论 第26篇需求三层次五活动螺旋1:10:100规律获取 第27篇六类干系人访谈问卷JAD原型分析 第28篇DFD与UML建模MoSCoW优先级规格说明 第29篇GB/T 8567结构好需求写法验证 第30篇评审检查单需求测试化管理 第31篇基线与CCBRTM双向跟踪OOA 第32篇用例驱动边界控制实体案例实战 第33篇三段式答题真题模式真题风格自测题1. IEEE 需求定义锚定的对象是 。A. 系统的技术架构 B. 用户的问题或业务目标 C. 开发团队的能力 D. 项目预算约束2. 「将复诊患者线上分流比例提升至 40%」属于 。A. 功能需求 B. 用户需求 C. 业务需求 D. 接口需求3. 「系统在 3 秒内返回可用号源列表」属于 。A. 业务需求 B. 功能需求 C. 非功能需求性能 D. 用户需求4. 需求工程的五大活动按经典顺序排列是 。A. 获取→分析→规格说明→验证→管理 B. 分析→获取→验证→管理→规格说明 C. 管理→获取→分析→验证→规格说明 D. 获取→验证→分析→规格说明→管理5. 关于需求工程过程的正确理解是 。A. 严格线性一次通过 B. 获取与分析等活动迭代交织、螺旋收敛 C. 管理只在项目末期进行 D. 验证可以完全推迟到系统测试6. 需求阶段、编码阶段、运行阶段修复同一需求错误的成本比例关系通常是 。A. 大致相等 B. 逐阶段递减 C. 大致呈 1:10:100 逐级放大 D. 与阶段无关7. 下列不属于非功能需求的是 。A. 处方实时上报监管平台 B. 系统 7×24 小时可用率 99.9% C. 达到等保三级 D. 支持在线预约挂号8. SRS需求规格说明书主要承载的需求层次是 。A. 业务需求 B. 用户需求与系统需求 C. 仅项目章程内容 D. 详细设计决策9. 需求验证通过后的需求集合进入 。A. 需求基线此后变更须走变更控制 B. 直接作废重写 C. 开发自由裁量区 D. 测试用例库10. 系统分析师在需求工程中对其解释需求、守门范围扩张的对象是 。A. 业务方用户 B. 开发团队 C. 监管机构 D. 投资方11. 「患者能在线预约 7 家医院的号源」这一表述属于 。A. 业务需求 B. 用户需求 C. 非功能需求 D. 数据需求12. 简答为什么说「把需求等同于功能清单」是危险的请结合需求层次说明。参考答案1.B 2.C 3.C 4.A 5.B 6.C 7.D 8.B 9.A 10.B 11.B 12. 功能只是需求的解决方案形态需求的本体是用户问题与业务目标业务需求层只记功能清单会丢失两层信息——一是「为什么」无法判断功能是否真正解决业务问题易做无用功能二是质量与约束非功能需求如性能、合规、安全这些不出现在功能清单里却往往决定系统成败因此需求必须分层获取与表述功能需求须可追溯到用户需求与业务需求。本篇小结知识点核心内容需求定义解决用户问题/达成业务目标系统必须满足的条件或能力需求三层次业务需求为什么→ 用户需求做什么任务→ 系统需求功能非功能五活动获取 → 分析 → 规格说明 → 验证 → 管理螺旋迭代收敛非功能需求性能/安全/可用性/合规约束云诊通成败的关键维度错误放大规律需求:编码:运行 ≈ 1:10:100需求投入是回报最高的投资分析师角色翻译者、追问者、守门人、变更治理者、约束识别人云诊通口径六类干系人 × 七大业务域100 原始需求收敛为 80 系统需求下篇预告第 27 篇需求获取技术——面向六类干系人的实战方法需求工程第一步是把需求「挖出来」访谈、问卷、JAD、原型、观察、文档考古六种技术的适用场景与优缺点以及云诊通对「忙碌的医生」与「刚性的监管方」的差异化获取策略。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。
