软件工程-需求获取简介

软件开发活动的最终目的是解决用户的实际问题，因此需求获取就成为了一个最为重要的组成部分，本文从问题的获取和需求分析入手，介绍问题向需求转换的流程和规范做法。

概述

现今开发的任何一个软件系统，都是从用户要解决的问题开始启动的。因此，首先要做的就是明确要做什么，解决什么问题，也即明确用户的需求。并且不论使用的是哪种软件开发方法学，需求的获取和分析手段都是类似的。

软件工程活动包括如下内容：

1. 需求获取
2. 需求分析
3. 系统设计
4. 对象设计
5. 实现
6. 测试

这些活动在总体顺序上随着使用的方法学的不同有不同，但在软件开发的整个过程中，总是伴随着这些活动进行的。并且需求获取是一切活动的源头，没有明确的需求，后续的开发活动都是空谈。

获取的需求总是会包含如下两方面的内容：

1. 功能性需求： 描述了系统和环境之间的交互。这里的环境指用户或者是任何可能与这个系统交互的外部实体。
2. 非功能性需求：描述了不直接关联到系统功能行为的其他方面内容。包括可用性，可靠性，性能，可适配性，可维护性，可移植性等。

上述两个方面的内容在描述时必须满足如下原则：

1. 完整
2. 一致
3. 无二义
4. 正确
5. 可确认
6. 可行
7. 可追踪

需求分析的结果是通过参与者和用例来描述的模型，这个模型表示了系统的目标。

下面介绍需求获取时候用到的一些工具和方法。

需求获取（Requirements Elicitation）

需求获取是将注意力完全放在系统目标的描述上，通过从用户获取到的问题域，定义了解决这一问题的系统。而这一定义是通过需求规格说明表示。并且在需求获取后的需求分析阶段，需求规格说明会被结构化和形式化，从而产生分析模型（主要用于系统分析人员和开发者之间进行沟通）。

而需求获取实际又包含如下活动：

1. 标识参与者：参与者可以是人，也可以是外部系统，它是一种抽象的角色。
2. 标识场景：场景指的是特化的使用场景，带有具体的细节。通过标识场景，可以和用户一起沟通并加深对问题的理解。
3. 标识用例：用户和开发者确认场景后，就可以从场景导出一组对应的抽象用例了。
4. 求精用例：细化每一组用例，增加错误条件或异常条件。
5. 标识用例之间或参与者同用例之间的关系：识别出用例之间的依赖关系，或者参与者与用例的关系，分解共同的功能，同时加强用例模型。
6. 标识非功能性需求：系统性能约束，文档，消耗的系统资源，安全性和质量。

需求获取的结果可以通过 RAD（需求分析文档）进行编写。

问题获取

需求也是从用户要解决的问题而来的，因此需要明确如何获取和描述问题。

问题描述时，也可以通过下面几个方面进行：

1. 问题的上下文及整体描述
2. 系统目标
3. 高抽象层级的功能性需求
4. 高抽象层级的非功能性需求
5. 解决方案所运行的目标环境

参考

1. 面向对象软件工程：使用 UML、模式与 Java（第三版）