4 需求工程

kiki
Jan 1, 0001 blog

4.1 功能需求和非功能需求

  • 功能需求：包括对系统应该提供的服务、如何对特殊输入做出反应，以及系统在特定条件下的行为的描述
    • 某些情况下，可能需明确声明系统不应该做什么
    • 系统的功能需求描述应该完备且一致
    • 完备性：用户所需的所有服务都应该给出描述
    • 一致性：需求描述不能前后矛盾
  • 非功能需求：对系统提供的服务或功能给出的约束
    • 包括时间约束、开发过程的约束和所受到的标准的约束
    • 经常适用于整个系统而不是个别的系统或功能
    • 如果有可能，使非功能需求得以量化，从而可测试

4.2 软件需求文档

  • 软件需求文档是对系统开发者需要实现什么的正式陈述
    • 应该包括系统的用户需求和一个详细的系统需求描述
  • 敏捷：增量式收集用户需求，并把它们作为用户故事情节卸载卡片上；然后对需求给出优先级排序，优先考虑紧急的需求

4.3 需求描述

  • 需求描述就是在需求文档写下用户需求和系统需求
    • 用户需求：从用户角度描述，使用自然语言、图形描述
    • 系统需求：是软件工程师系统设计的起点，仅仅描述系统的外部行为和对它的操作上的限制

4.4 需求工程过程

  • 需求工程包括
    • 1 业务需求描述
    • 2 可行性研究：在需求工程早起进行。考虑三个相关问题
    • 系统是否对机构的总体目标有贡献
    • 采用当前技术，系统是否能在时间要求和预算范围内实现
    • 系统是否能和正在使用中的其他系统集成
    • 3 用户需求导出
    • 4 用户需求描述
    • 5 原型构造
    • 6 系统需求导出
    • 7 系统需求描述和建模
    • 8 复查(需求有效性验证)
    • 重复上述步骤

4.5 需求导出和分析

  • 1 需求发现：也称为需求导出，是一个对准备建立的系统和正在使用的系统进行信息收集，并从这些信息中提取用户需求和系统需求的过程
  • 2 需求分类和组织
  • 3 需求优先级排序和协商
  • 4 需求描述
  • 重复上述步骤

4.6 需求有效性验证

  • 需求有效性验证是检验需求是否真正按客户的意愿来定义系统的过程
  • 对需求文档定义的需求执行多种类型的检查
    • 有效性检查：某个用户可能认为系统应该执行某项功能
    • 一致性检查：在文档中，需求不应该彼此冲突
    • 完备性检查：需求文档应该包括所有系统用户想要的功能和约束
    • 真实性检查：基于对已有技术的了解，检查需求以保证需求能真正实现。这些检查考虑到系统开发的预算和进度安排
    • 可检验性检查：系统书写的需求应该是可以检验的，即能设计出一组检查方法来验证交付的系统是否满足每一个定义的需求
  • 需求有效性验证技术包括
    • 需求评审：由一组评审人员对需求进行系统性分析，主要是错误检查和不一致性检查
    • 原型建立：为客户和最终用户生成一个可执行的系统模型，他们能在这个模型上体验从而检查系统是否符合他们的真正需要
    • 测试用例生成：需求应该是可测试的。把对需求的测试作为有效性验证过程的一部分，从而发现问题。如果很难或者不可能设计测试，那以为着需求的实现很困难，应重新考虑

4.7 需求管理

  • 需求管理是一个对系统需求变更了解和控制的过程
  • 需求变更管理过程有 3 个阶段
    • 问题分析和变更描述：对问题或变更提议进行分析检查有效性。将分析结果反馈给变更请求者，请求者产生一个更详尽的需求变更提议或取消变更请求
    • 变更分析和成本计算
    • 变更实现：必要的话，修改需求文档以及系统设计和实现。尽量避免先修改系统再修改需求文档
sa engineer

相关