概述

介绍如下内容:

  • 需求分析的基本任务
  • 需求分析的参与人员
  • 需求分析的结构化分析方法的四条准则
  • 需求分析的具体任务
  • 需求的获得方法

基本任务:

系统必须做什么?即对目标系统提出完整、准确、清晰、具体的要求。并在需求分析结束之前给出软件需求规格说明书

参与人员

  • 用户:尽量准确具体地把对软件的求描述出来。
  • 分析员:通过与用户沟通获取用户对软件的需求。在软件需求规格说明书严格审查和验证需求分析的结果

结构化分析方法的准则

  • 理解并描述问题的信息域,并建立数据模型。信息域为软件产品需要用到的所有数据。
  • 定义软件应完成的功能,并建立功能模型。
  • 描述作为外部事件结果的软件行为,并建立行为模型。
  • 将上述模型进行分解,用层次的方式展示细节。

需求分析的具体任务

确定系统的综合要求

  • 功能需求:系统必须提供的服务。
  • 性能需求:系统必须满足的定时约束或容量约束,通常包括如下几种
    • 响应时间
    • 信息量速率
    • 主存容量
    • 磁盘容量
    • 安全性等方面的需求
  • 可靠性和可用性需求:可靠性需求定量地指定系统的可靠性。
  • 出错处理需求:说明系统对环境错误应该怎样响应。例如接收到了非法数据应该如何做。
  • 接口需求:描述应用系统与它的环境通信的格式,通常包括
    • 用户接口需求
    • 硬件接口需求
    • 软件接口需求
    • 通信接口需求
  • 约束:设计或实现应用系统时应遵守的限制条件。如精度,工具和语言的约束,应当遵循的标准和应当使用的硬件平台等。
  • 逆向需求:说明软件系统不应该做什么。逆向需求有无限个,一般仅选取能澄清真实需求且可消除可能发生误解的逆向需求。
  • 将来可能提出的要求:应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。

分析系统的数据要求

  • 任何一个软件系统本质上都是信息处理系统。
  • 必须分析系统的数据要求,这是软件需求分析的一个重要任务。
  • 分析系统的数据要求通常采用建立数据模型的方法。
  • 利用数据字典可以全面准确地定义数据,但是不够直观,常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。

导出系统逻辑模型

综合之前综合要求和数据要求的分析结果,可以导出系统的详细的

  • 逻辑模型
  • 数据流图(DFD)
  • 实体-联系图(ER图)
  • 状态转换图
  • 数据字典
  • 主要的处理算法

图片加载失败建立逻辑模型的大致流程

修正开发计划

被修正的开发计划是在可行性研究阶段分析出来的,但并不详细具体。而经过了需求的详细了解之后,就可以修改成具体的开发计划了。

获取用户需求的方法

访谈

访谈时最早开始使用也是目前为止最广泛使用的方法。

正式访谈

系统分析员会提出事先准备好的具体问题,通常采用调查表的形式,分析员通过仔细阅读调查表也可以有针对性地访问一些用户询问一些新问题。

非正式访谈

系统分析员多使用情景分析技术,提出可自由回答的开放性问题鼓励受访者说出自己的想法。

情景分析可以对用户将来使用某个系统解决问题的方法和结果进行分析,可以在一定程序上演示目的系统的行为,便于用户理解,发现一些未知需求,保证用户在过程中处于积极主动的状态。

图片加载失败情景分析举例

面向数据流自顶向下求精

任何一个信息处理系统都是讲数据加工处理成输出信息,数据决定需求的处理和算法,所以数据是需求分析的出发点

  • 一可行性分析阶段做出的顶层数据流图为基础,建立详细的数据流图:描述数据在软件内从输入移动到输出的过程中所进行的变换
  • 使用数据字典:定义数据流图中的元素
  • 使用E-R图:从用户角度描述数据
  • 使用IPO图:描述数据流图处理框中的功能和算法
  • 使用层次方块图:层次方框图的从上到下,逐层细化的效果对功能的逐步分解也同样适用,所以更多的是用来描述软件产品的功能结构。
  • 使用Warnier图:它比层次方框图要更具体,描绘手段更丰富一些。

上述的图也是描述需求的常用图形。

图片加载失败大致流程

简易的应用规格说明技术

一种面向团队的需求收集方法,提倡用户与开发者合作,共同标记问题,提出解决方案要素,商讨不同方案并指定基本需求。

大致过程

  1. 初步访谈
  2. 写出产品需求
  3. 开讨论会
  4. 制定规格说明
  5. 开发者和用户反复修订,最终提出完整的软件需求规格说明书

快速建立系统原型

快速建立旨在演示目标系统主要功能的可运行程序,实现用户看得见的功能,省略隐含功能。是最有效、最准确和最强大的技术

特点

  • 快速:尽快提供一个原型,使用户和开发者在目标系统上尽可能快速达成共识。
  • 原型应容易修改。

所用技术

为了快速实现和修改原型,通常会使用如下技术

  • 第四代技术:众多数据库查询和报表语言、程序应用系统生成器以及其它高级的给过程语言。
  • 可重用的软件构件。
  • 形式化规格说明和原型环境:在交互式环境下用自动工具把基于形式语言的规格说明翻译成可以执行程序代码。

描述需求的方法

  • 一可行性分析阶段做出的顶层数据流图为基础,建立详细的数据流图:描述数据在软件内从输入移动到输出的过程中所进行的变换
  • 使用数据字典:定义数据流图中的元素
  • 使用E-R图:从用户角度描述数据
  • 使用IPO图:描述数据流图处理框中的功能和算法
  • 使用状态转换图(STD):描述系统在各个状态下转移的条件和行为。
  • 使用层次方块图:层次方框图的从上到下,逐层细化的效果对功能的逐步分解也同样适用,所以更多的是用来描述软件产品的功能结构。
  • 使用Warnier图:它比层次方框图要更具体,描绘手段更丰富一些。

对需求进行验证

  • 一致性:所有需求必须是一致的,不能和其他需求有矛盾
  • 完整性:需求必须是完整的,规格说明书应该包含用户需要的每一个功能或性能
  • 现实性:必须是可实现的
  • 有效性:需求正确有效,可以切实解决用户的问题

快速建立系统原型

该方法不仅可以获取用户需求,也可以验证需求