从系统分析到需求工程

  • 系统分析

    • 系统分析主要是对现有业务系统进行研究，确定新系统中软件的边界*（对边界进行划分）*和功能。
    • 系统分析的结果一般是软件的需求，故也常被称为需求分析；
    • 系统设计是决定如何实现软件功能的活动。
    • 传统上认为，系统分析决定“做什么”，系统设计决定“怎么做”。“谁来做”

  • 需求工程

    • 需求工程是用科学的方法，发现、记录和确认需求的学科。

  • 需求工程认为软件需求是一个持续的过程，以迭代方式贯穿于软件开发的全周期。

需求工程框架概览

​ 需求工程框架

  • 系统上下文： 系统所处*环境中与定义、理解和解释系统需求相关*的部分。上下文是需求的主要来源。
  • 核心活动： 需求过程的本质活动。包括需求获取、需求文档化、需求协商。体现了需求工程的内容维度、共识维度和文档化维度。
  • 横切活动： 对需求过程有重大影响，贯穿始终。包括需求确认，需求管理。为核心活动提供支持，并保证需求结果的正确性。
  • 需求活动： 核心活动+横切活动
  • 需求制品： 从不同层次描述需求，分三类 ：高层次目标、需求场景、面向方案的需求。

系统上下文

  • 系统的上下文 （Context）指的是目标系统、与之交互的用户和外部系统.
  • 系统上下文亦即需求概念中的问题领域。
  • 结构化 的系统上下文分析，将它分为4刻面：
    • 主体刻面： 上下文的主要方面。含有软件系统必须处理或包含的实体和事件；
    • 使用刻面： 上下文系统被使用的有关情况；
    • IT系统刻面： 运行或技术环境相关的所有方面；
    • 开发刻面： 影响系统开发的所有方面。

需求活动

  • 需求活动是需求工程的中心。 通过活动达到目的，产生结果。

    以下5个需求活动之间，存在交互关系。

  • 需求获取： 从涉众、现有文档或已有软件系统（称为遗留系统）中得到和改进对需求的理解，在需求的内容维度取得进展。

  • 需求文档化： 已知的需求只有文档化，才能进行商讨和确认，指导软件开发工作。需求文档化主要关注各种文档的规范、格式、写法。

  • 需求协商： 不同涉众的要求和期望不同，会导致需求冲突。需求协商就是要识别需求冲突，并对冲突加以解决。需求协商也是核心活动。

  • 需求确认： 确认活动是为了保证需求的正确性。包括——

    • 需求制品的确认： 按照内容、文档化和共识三个维度确认制品没有缺陷，才可用于开发过程，或纳入合同文本。
    • 核心活动的确认： 确认核心活动是否符合规定的流程（过程规约，活动规则）。为过程保障活动。过程正确，才能得到可信的结果。
    • 系统上下文考虑因素的确认： 确认是否对上下文因素进行了充分的、合规的考虑。过程保障活动。

  • 需求管理： 维持需求过程有序进行。包括——

    • 需求制品管理： 确定需求的优先级，需求的持久化保存，需求的配置及变更管理，需求跟踪关系维护
    • 需求活动管理： 对需求活动进行规划和控制，确保需求过程有效和高效。
    • 系统上下文观察： 识别系统上下文的变更。一个相关上下文的变更，会要求一个或多个需求活动的执行，或者活动的重新规划。

需求制品

  • 需求制品即需求活动产生的成果文档。

  • 由于需求的层次性，需求文档也分成——

    • 目标(文档)： 在系统上下文中建立的愿景。典型目标文档即“愿景”。描述对软件的高层需要(Needs)，以及从使用者角度提出的特性（Features）

      • 愿景是对期望简要、精确的描述。期望是对当前不满意作改善的构想。
      • 愿景仅定义目标，不说明如何实现。但愿景是**可验证（可实现）**的。
      • 在整个开发周期，愿景是涉众的指导思想。

    • 场景： 对软件需求的形象化描述。

      • 场景是需求的主要载体。
      • 用例创建从识别系统参与者（对涉众的进一步细化）开始， 然后根据参与者目标，识别和确定参与者与系统交互的情景。

    • 面向方案的需求： 与所用软件工程方法接轨的需求文档。促进（加速）下一步的软件开发

      • 传统方法中，由场景进一步定义系统的数据视图、功能视图和行为视图；
      • 面向对象的方法中，基于用例，得出领域类图（E-R图前身）、系统顺序图（人机交互）、操作契约等。

  • 需求制品是可选的