持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第30天

需求工程活动

需求获取

需求获取是从人、文档或者环境当中获取需求的过程。

需求工程师需要利用各种方法和技术，在学习—认知的递进过程中来“发现”需求，分析需求。

需求获取和需求分析是交织在一起的

需求工程师在需求获取中要执行的任务：

收集背景资料： 收集系统背景资料，形成领域知识基础框架，以便与用户进行有效沟通，获取需求。

获取问题与目标，定义项目前景和范围发现用户在业务中遇到的高层次问题，用户解决高层次问题的期望既是系统的业务需求，也是系统要达到的目标。

明确高层次解决方案：定义项目的前景与范围 需求分析 指导需求冲突协商 形成项目的前景与范围文档

识别涉众，选择信息的来源：

• 涉众分析：用户、投资方等，选取涉众代表获取需求。

• 硬数据采样：表单、报表、备忘录的硬数据采样，了解业务流程。

选择获取方法，执行获取 ，获取功能与非功能需求：

• 获取问题域特性。

• 面谈、调查表、原型、观察法等。

记录获取结果：

• 业务需求、项目前景与范围（项目前景与范围文档）

• 用户需求与问题域特性

例如修建一条公路，它预期的使用者是广大的司机；监管方是交通管理局；出资方是国家财政；发展商是某某公司；建筑商是某某工程公司等。显然他们都与此项目有利益关系，都是涉众。这些都好理解。但是在某些情况下，看似与公路完全无关的一些人和事却会成为重要涉众。例如当公路修建需要搬迁居民时，被搬迁的居民就成为重要的涉众；当公路规划遇到历史建筑时，文物管理局就成为重要的涉众。虽然软件项目开发与修建公路相比涉及的人和事要少得多，但是也不能忽略系统使用者之外的其他涉众。另外，当面对一个陌生的问题领域时，往往在项目初期还不能够清楚的获悉究竟谁是系统的使用者，通常得随着需求的深入逐步明确。但是最终的系统使用者将从涉众当中产生，因此涉众分析显得尤为重要

需求分析

需求工程师执行的需求分析活动：

背景分析:研究系统部署环境，形成关于用户业务的知识框架，与用户进行有效沟通。

方法：领域分析、企业建模

问题分析、目标分析、业务分析，确定系统边界。

方法：系统用例图、上下文图

面向对象边界描述：用例图--外部角色在与解决方案的交互中完成的任务与目标

结构化方法的边界描述：上下文图

关注解决方案与环境之间的信息流输入/输出

软件需求建模

建模是需求工程中最重要的任务，是为展现和解释信息而进行的抽象描述活动。

模型由一些基本元素 和元素之间的关系组成，具有与丰富的语义。

技术方法：数据流图、实体关系图、状态转换图、类图、Z模型

需求细化

• 特征：用户需求具有模糊、歧义性。

• 目的：在模型的帮助下，将用户需求细化为具有良好粒度和特性的系统级需求。

确定优先级

• 定期评估、调整优先级，适应业务目标变化，最大限度利用资源。

需求协商

• 发现冲突、技术说明、指导冲突协商

获取的需求需要被编写成文档，主要目的是为了在系统涉众、开发者之间交流需求信息。

• 业务需求被写入项目前景和范围文档

• 用户需求被写入用户需求文档（或者用例文档）

• 系统需求被写入需求规格说明

质量要求：简洁、精确、一致和易于理解。

需求规格说明 子活动

定制文档模版 【IEEE1998】

• 编写文档：

  • 模型语言：准确性
  • 自然语言：可读性

需求验证

确保需求规格说明文档能正确、准确的反映用户的意图，指导设计、实现、测试，需求规格需要满足几个标准：

• 文档内每条需求都正确、准确的反映了用户的意图；

• 文档记录的需求集在整体上具有完整性和一致性；

• 文档的组织方式和需求的书写方式具有可读性和可修改性

为满足以上标准，要进行需求验证

• 执行验证 ：同级评审、原型、模拟。

• 问题修正 ：发现问题、修正问题、跟踪问题、落实问题。

通过需求验证的需求规格说明传递给后续系统设计、实现、测试开发人员。

需求管理

需求的影响力贯穿软件的产品生命周期，为保证需求持续、稳定和有效发挥，要进行需求管理。

• 建立和维护需求基线集

  • 前提与基础：建立良好的配置管理，对需求基线进行版本控制。

• 建立需求跟踪信息：对系统级需求进行后向跟踪、前向跟踪。

• 处理变更请求、进行变更控制

  • 需求变更是导致项目失败的主要原因之一，需要建立控制变更的过程及策略，确定应对变化的基本方法，组织变更控制团队。

  • CMMI软件能力成熟度模型集成将需求管理作为二级成熟度企业都应具备的关键过程域