【软考之系统架构师】软件需求管理知识点整理

一、软件需求工程

1、软件需求

• 层次关系：业务需求→用户需求→系统需求，抽象层次依次降低
• 判断技巧：性能需求通常带数字指标；设计约束是外部强制规定
• 业务需求
  • 提出者：项目投资人、市场营销部门等非技术人员
  • 特点：高层次目标要求，如"需要在线教育平台"
  • 案例："用户能有效纠正文档拼写错误"（不涉及具体实现）
• 用户需求
  • 描述形式：用户使用场景和具体任务
  • 获取方式：用户访谈、问卷调查
  • 案例："找出拼写错误并提供替换项列表"
• 系统需求
  • 功能需求
    • 特征：明确的功能描述语句
    • 案例："显示替换词对话框并实现全文替换"
  • 非功能需求
    • 包含范围：性能需求（响应时间≤1秒）、质量属性（可靠性、可维护性）
    • 记忆点：非功能=非直接功能相关+质量属性
  • 设计约束
    • 识别特征：外部强制规定（如"必须采用国产数据库"）
    • 典型示例：金钱精度保留小数点后两位

考试真题：

答案：A B C A

二、需求开发

1、需求获取

1) 需求获取定义

• 定义:需求获取是确定和理解不同项目干系人需求和约束的过程
• 范围:涉及不同用户和干系人的需求收集
• 定位:属于需求开发过程的初始阶段
• 重点:以了解基本定义为主，非深入细节

2) 需求获取法🌟🌟

• 用户访谈:一对一或一对三的深度交流，适用于代表性用户，需求精准但覆盖面有限，分结构化和非结构化两种形式。
• 问卷调查:适用于大规模用户群体，需求收集量大但杂乱，问卷设计难度较高。
• 采样:从大群体中选取代表性样本的过程，核心在于样本选择和数量确定
• 
• 情节串联版:通过系列图片讲故事展示需求，形象生动但耗时较长。
• 联合需求计划(JRP):关键用户、分析师和开发团队共同参与的会议，能统一解决多方矛盾。
• 需求记录技术:包括任务卡片等方法，用于记录调研结果。

真题练习：

答案：A D C 

2、需求分析

1.需求分析定义

• 需求分析定义：将杂乱无章的用户要求和期望转化为明确用户需求的过程
• 需求获取方法：可采用多种方法混合使用，非单一性
• 需求筛选标准：需区分必要需求（合同规定）与非必要需求
• 优质需求特征：具备无二义性和完整性
• 需求冲突处理：分析不同干系人对同一需求的不同理解
• 需求分析作用：判断需求的有用性和正确性

2.需求分析任务

• 系统上下文范围关系图:数据流图的一种，反映系统间数据流走向和功能关系
• 用户界面原型:需求分析阶段先设计出用户界面
• 需求可行性分析:评估需求是否可实现
• 需求优先级确定:为需求建立逻辑模型并排序
• 数据字典创建:定义系统中使用的数据元素
• 质量功能部署:将需求与质量特性(如可靠性)关联
• 容错措施设计:针对关键质量要求(如24×7运行)设计相应解决方案

3.结构化的需求分析

1) 结构化的需求分析三大模型

• 需求分析分类:结构化和面向对象
• 结构化特点:自顶向下、逐步分解、面向数据流
• 功能模型:对应数据流图(DFD)
• 行为模型:对应状态转换图
• 数据模型:对应ER图
• 数据流图组成:数据流、加工、数据存储、外部实体
• 状态转换图特点:与UML状态图类似
• ER图应用:在数据库设计中讲解

2) 数据流图

• 基本图形元素🌟🌟🌟
  • 数据流图基本元素：外部实体（长方形）、加工（四边带弯）、数据存储（两种形式）、数据流（箭头）
  • 数据流规则：流向必须经过加工，不能直接在外部实体/数据存储间流动
  • 加工定义：输入数据流到输出数据流的转换功能
  • 加工错误类型：黑洞（只有输入）、奇迹（只有输出）、灰洞（输入输出不匹配）
  • 数据存储功能：用于存储数据的容器
  • 外部实体特征：存在于软件系统外部并与系统交互的对象

3) 分层数据流图

• 分层数据流图定义:自顶向下逐层分解的系统功能描述工具
• 顶层数据流图:反映系统与外部实体交互的上下文图
• 零层数据流图:对顶层系统进行功能扩展的内部加工图
• 数据流平衡原则:子图与父图的输入输出必须严格对应
• 加工分解方法:每个加工可继续细化为更详细的一层图
• 考试重点范围:通常只考察顶层和零层两级分解

4) 数据字典

• 数据字典定义：对数据流图中各成分进行详细说明的字典，用于解释数据流图中的概念。
• 数据字典作用：提供数据流图中数据流、数据存储、加工等成分的详细描述，便于理解和使用。
• 数据字典条目：包括数据流、数据项、数据存储和基本加工四类，不包含外部实体。
• 外部实体排除原因：外部实体不属于系统内部，因此不在数据字典中描述。
• 数据项概念：数据的最小单位，用于描述数据的类型和结构。
• 加工逻辑描述方法：结构化语言、判定表、判定树三种方法。
• 数据字典结构：包含符号、含义、示例等，类似于字典的条目格式。

3、需求定义

• 需求定义阶段目标：将需求分析阶段建立的逻辑模型规范化，形成软件需求规格说明书(SRS)。
• 结构化定义方法：又称严格定义/预先定义，适用于需求明确场景，基于所有需求可预先定义的假设。
• 原型方法：适用于需求不明确场景，通过迭代原型逐步确定需求。
• 结构化建模成果：建立数据流图(DFD)、实体关系图(ERD)、状态转换图(STD)三大模型。
• 面向对象建模特点：通过UML系列图形进行建模（后续讲解）。
• 严格定义前提条件：开发人员与用户能清晰准确交流，需求可完整预先定义。
• 需求分析输出：建立系统逻辑模型，为需求定义提供基础。

4、需求验证

• 需求验证定义:又称需求确认，是与用户共同确认需求的过程。
• 验证核心活动:对需求规格说明书进行评审和测试。
• 评审类型:包括正式评审和非正式评审，需多方参与（需求/开发/测试人员）。
• 需求测试特点:无代码阶段，通过设计概念测试用例或场景验证需求。
• 签字确认意义:用户签字作为验收标准，防止后期抵赖。
• 需求基线形成:通过验证的需求规格说明书成为基线，禁止随意修改。
• 变更管理:基线化后需走正式变更流程才能更新需求。
• 最终交付物:需求规格说明书和需求基线（已确认的说明书版本）。

三、需求管理

1、定义需求基线

• 需求基线定义：通过评审的需求说明书即为需求基线
• 基线特性：基线确定后不可随意修改
• 变更要求：后续修改需遵循正式变更流程
• 基线作用：作为需求管理的基准参照点

• 需求初始状态:被建议状态
• 需求评审结果:通过则批准，不通过则拒绝结束
• 需求实现流程:设计阶段→编码→单元测试→集成测试→验收交付
• 需求变更环节:在实现流程后单独说明

2、需求变更

• 需求变更流程：提出变更→分析影响→提交CCB审批→执行变更→验证变更
• CCB组成：由对需求有决定权的领导组成（如项目经理、客户方经理、技术经理）
• 流程简化原则：可减少步骤但不可颠倒顺序（如1-3-5可接受，3-1-5不可接受）
• 变更风险：用户参与不足/需求分类遗漏/需求无限增加/需求表述模糊
• 变更原因：外部环境变化/前期工作缺陷/新技术出现
• CCB双重含义：变更控制委员会（需求）与配置控制委员会（配置）共用简称
• 考试答题技巧：流程题需保持步骤逻辑顺序，允许中间步骤缺失

3、需求跟踪

• 需求跟踪定义:分为双向跟踪，包括正向跟踪和反向跟踪。
• 正向跟踪:从用户原始需求到需求文档再到产品实现，判断需求是否少实现。
• 反向跟踪:从产品功能回溯到需求文档和原始需求，判断需求是否多实现。
• 追溯与回溯:正向跟踪又称追溯，反向跟踪又称回溯。
• 需求跟踪矩阵:用于记录需求与用例关系的工具，通过打勾确认对应关系。
• 矩阵解读:某行无对勾表示需求未实现，某列无对勾表示用例多余。
• 跟踪目标:确保需求实现既不多也不少，达到精确匹配。

真题练习：

答案：D B B

解析1：

• CMMI二级关键过程域数量:第二级包含六个关键过程域，而非三个
• 需求属性包含内容:需求稳定性属于重要需求属性
• 需求变更管理正确流程:变更描述→变更分析→变更实现（CCB审批步骤可省略但顺序不可逆）
• CCB职能范围:变更控制委员会有权对任何基线工作产品的变更做出决定
• 选项排除技巧:通过明确错误选项（如B、C）可锁定正确答案（D）

解析2：

• 数据流图作用：描述功能模型而非数据模型
• 数据模型工具：ER图用于数据建模（数据库领域）
• 外部实体特征：与系统交互的外部名词（如读者）
• 加工识别：动词类操作（如借阅）属于功能而非实体
• 系统内部实体：图书管理系统中的图书、书柜等
• 概念区分：行为模型对应状态转换图