需求开发和需求管理需求工程包含需求开发和需求管理开发和管理的分界线是什么 —— 需求基线模糊需求⬇【 需求开发 】获取 → 建模分析 → 规格编写 → 评审⬇ 分水岭正式评审批准形成【需求基线 (Baseline)】 ⬇【 需求管理 】变更控制 → 版本管理 → 状态跟踪 → 需求跟踪在基线确立之前所有弄清楚“系统要做什么”的活动获取、建模、编写规格、评审都属于需求开发而在基线确立之后为了防止失控对变更、版本和实现的监控则属于需求管理。需求开发Requirements Development核心目的回答“系统做什么”属于构建过程。核心活动需求获取通过访谈、JRP联合需求计划、问卷、采样等收集用户诉求。需求分析与建模把自然语言转化为 DFD数据流图、用例图、ER 图等形式化模型需求定义编写标准规范的《软件需求规格说明书》SRS。需求验证/评审多方评审 SRS确保无二义性、完整与可验证。需求管理Requirements Management核心目的基线确立后应对变动、确保实现不跑偏。核心活动变更控制变更申请、影响分析、CCB 审批。版本控制维护 SRS 及相关文档的历史演进版本。需求状态跟踪跟踪每个需求从“已提出”到“已实现”、“已验证”的生命周期状态。需求跟踪建立需求与设计部件、代码、测试用例之间的双向映射需求跟踪矩阵。需求跟踪与变更控制需求跟踪与需求跟踪矩阵RTM需求跟踪是指编制每个需求与系统元素之间的联系文档。这些系统元素包括其它需求、体系结构、设计部件、源代码模块、测试用例、帮助文件和相关文档。需求跟踪的两种主要方式正向跟踪前向可追溯性路径用户原始需求 → 架构设计 → 代码模块 → 测试用例。目的检查是否有需求在下游被遗漏确保“该做的都做了”。反向跟踪后向可追溯性路径测试用例 / 代码模块 / 设计部件 → 原始需求。目的检查是否存在多余的代码或设计防止镀金确保“做的每一行代码都有据可查”。核心工具需求跟踪矩阵RTM在工程实践中通常使用一张二维表格来管理双向关联需求编号需求描述对应架构/设计组件对应源码文件/模块对应测试用例编号REQ-001用户扫码登录AuthComponentauth_service.pyTC-AUTH-001REQ-002订单超时自动取消OrderSchedulerorder_timer.pyTC-ORD-015需求变更控制流程案例分析考过标准变更控制流程提出变更申请由提出人填写书面的《需求变更申请单》严禁口头承诺。变更影响分析由技术骨干和架构师对变更的技术可行性、工作量、工期、成本及关联模块进行影响分析。CCB 审查与决策提交给变更控制委员会CCB进行正式评审决定“批准”、“拒绝”或“延期”。实施变更如果批准相关人员修改设计文档、更新源代码、调整测试用例。验证与确认测试人员执行测试验证变更内容是否符合预期且未引入新的缺陷。发布与基线更新更新需求跟踪矩阵RTM重新发布新的需求基线并通知所有相关干系人。真题【题干】 包括编制每个需求与系统元素之间的联系文档这些元素包括其它需求、体系结构、设计部件、源代码模块、测试、帮助文件和文档。(A) 需求描述(B) 需求分析(C) 需求获取(D) 需求跟踪【正确答案】D【要点解析】题眼题干中的“编制每个需求与系统元素之间的联系文档”是《需求跟踪》的官方标准定义。建立这种联系的主要载体就是需求跟踪矩阵。干扰项排除选项 A需求描述侧重于用文本表达需求本身的语义选项 B需求分析侧重于挖掘逻辑冲突与可行性选项 C需求获取侧重于从用户那里收集原始信息。只有 D 强调需求与外部设计、代码、测试之间的映射关联。结构化与面向对象需求建模结构化分析模型数据流图DFD与数据字典DD结构化分析的核心思想是自顶向下、逐层分解关注系统内部“数据的流转与加工”。DFD 的 4 大基本元素外部实体实体系统边界之外的人、部门或外部系统数据的源头或归宿。加工处理对数据进行的变换或计算逻辑必须有输入也必须有输出。数据存储保存数据的文件或数据库表。数据流处于动态流动中的数据。DFD 常见错误黑洞一个加工只有输入流没有输出流。奇迹灰洞一个加工只有输出流没有输入流。直连错误外部实体之间直接连线、外部实体与数据存储直接连线、数据存储之间直接连线必须经过“加工”中转。父子平衡子图与父图的输入/输出数据流必须保持一致。数据字典DD如果说 DFD 是“骨架”那么数据字典就是对骨架中每个元素做出的详尽定义。定义内容数据项、数据结构、数据流、数据存储、处理过程。常见定义符号定义为 / 等价于连接 / 与如学号 姓名[ | ]或 / 选取其一如[ 男 | 女 ]{ }重复如{ 订单项 }( )可选可有可无面向对象分析模型用例建模Use Case用例模型是从外部用户的视角来描述系统功能与交互边界。参与者Actor位于系统外部与系统发生交互的实体用户、外部设备、定时器系统、外部接口系统。关系限制参与者与参与者之间只有泛化继承关系绝没有包含或扩展。3 大核心用例关系关系类型符号与指向核心含义与触发条件典型场景包含关系(Include)带箭头的虚线include指向被包含者基础用例在执行时必定会触发公共用例提取公共步骤。多个用例提取出的公共功能如“查询余额”和“转账”都包含“用户登录”。扩展关系(Extend)带箭头的虚线extend指向基础用例基础用例在特定条件扩展点下可选执行扩展用例。异常处理或增值服务如“借书”在逾期时触发“缴纳罚金”。泛化关系(Generalization)带空心三角箭头的实线指向父用例特殊用例继承一般用例的所有特性并加以特殊化。同一功能的不同实现方式如“在线支付”泛化为“微信支付”与“支付宝支付”。场景学习在高校图书管理系统中无论是“借书”还是“还书”都必须先执行“身份验证”。当借书时若发现“借阅超期”系统会额外触发“缴纳滞纳金”。还款时支持“校园卡刷卡”或“扫码支付”。借书 和 身份验证包含关系include题眼“必须先执行”、“提取公共步骤”。画法带箭头的虚线由“借书”指向被包含的“身份验证”。借书 和 缴纳滞纳金扩展关系extend题眼“超期等特定条件触发”、“可选执行”。画法带箭头的虚线由“缴纳滞纳金”指向基础用例“借书”。在线支付 和 微信支付 / 支付宝支付泛化关系Generalization题眼“同一抽象概念的具体实现方式”。画法带空心三角箭头的实线由子用例指向父用例。