Ray 的记录站

日常开发实践记录

0%

软件工程-需求获取简介

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

概述

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

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

  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(第三版)