需求分析概述及任务

需求分析

    为了开发出真正满足用户需求的软件产品,首先必须知道用户的需求,对软件需求的深入理解是软件开
发工作获得成功的前提条件,不论人们把设计和编码工作做得如何出色,不能真正满足用户需求的程序只会
令用户失望,给开发者带来烦恼。
    需求分析是软件定义时期的最后一个阶段,它的基本任务是准确地回答“系统必须做什么?”这个问题
。
    虽然在可行性研究阶段已经粗略地了解了用户的需求,甚至还提出了一些可行的方案,但是,可行性研
究的基本目的是用较小的成本在较短的时间内确定是否存在可行的解法,因此许多细节被忽略了。然而在
最终的系统中却不能遗漏任何一个微小的细节,所以可行性研究并不能代替需求分析,它实际上并没有准确
地回答“系统必须做什么?”这个问题。
    需求分析的任务还不是确定系统怎样完成它的工作,而仅仅是确定系统必须完成哪些工作,也就是对目
标系统提出完整、准确、清断、具体的要求。
    在需求分析阶段结東之前,系统分析员应该写出软件需求规格说明书,以书面形式准确地描述软件需求
。
    在分析软件需求和书写软件需求规格说明书的过程中,分析员和用户都起着关键的、必不可少的作用,
只有用户才真正知道自己需要什么,但是他们并不知道怎样用软件实现自己的需求,用户必须把他们对软件
的需求尽量准确、具体地描述出来;分析员知道怎样用软件实现人们的需求,但是在需求分析开始时他们对
用户的需求并不十分清楚,必须通过与用户沟通获取用户对软件的需求。
    需求分析和规格说明是一项十分艰巨复杂的工作。用户与分析员之间需要沟通的内容非常多,在双方
交流信息的过程中很容易出现误解或遗漏,也可能存在二义性。因此,不仅在整个需求分析过程中应该采用
行之有效的通信技术,集中精力细致工作,而且必须严格审查验证需求分析的结果。
    尽管目前有许多不同的用于需求分析的结构化分析方法,但是,所有这些分析方法都理守下述准则
(1)必须理解并描述间题的信息域,根据这条准则应该建立数据模型
(2)必须定义软件应完成的功能,这条准则要求建立功能模型
(3)必须描述作为外部事件结果的软件行为,这条准则要求建立行为模型
(4)必对连信息,功能和行为的模型进行分解,用层次的方式展示细节

3.1需求分析的任务
3.1.1 确定对系统的综合要求

    虽然功能需求是对软件系能的一项基本需求,但却并不是唯一的需求,通常对软件系统有下述几方面的
综合要求。
    1.功能需求
    这方面的需求指定系统必须提供的服务,通过需求分析应该划分出系统必须完成的所有功能。
    2.性能需求
    性能需求指定系统必须满足的定时约束或容量的束,通常包括速度(响应时间)、信息量速率,主存容量
,磁盘容量,安全性等方面的需求,例如,“应力分析程序必须在一分钟之内生成任何一个梁的应力报告。”
就是一项性能需求。
    3.可靠性和可用性需求
    可靠性需求定量地指定系统的可靠性,例如,“机场雷达系统在一个月内不能出现2次以上故障。”
    可用性与可靠性密切相关,它量化了用户可以使用系统的程度。例如,“在任何时候主机或备份机上的
机场雷达系统应该至少有一个是可用的,面且在一个月内在任何一台计算机上该系统不可用的时间不能超
过总时间的2%。”
    4.出错处理需求
    这类需求说明系统对环境错误应该怎样响应。例如,如果它接收到从另一个系统发来的违反协议格式
的消息,应该做什么?注意,上述这类错误并不是由该应用系统本身造成的。
    在某些情况下,“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是,应该
有选择地提出这类出错处理需求。人们的目的是开发出正确的系统,而不是用无休止的出错处理代码掩盖
自己的错误。总之,对应用系统本身错误的检测应该仅限于系统的关键部分,而且应该尽可能少。
    5.接口需求
    接口需求描述应用系统与它的环境通信的格式。常见的接口需求有,用户接口需求；硬件接口需求;软
件接口需求；通信接口需求,例如：
    把商品从货源地运送到目的地所需要的成本,应该一直显示在“成本”正文框中。
    “向运输公司传送“需运送的商品”信息的格式是exp<string>,其中<string>是从商品目录中选取的
字符串”
    上述第一个例子是应用系统与用户接口的一个需求,第二个例子指定了与其他应用系统通信的信息格
式,两者都是接口需求
    6.约束
    设计约束或实现的约束描述在设计或实现应用系统时应遵守的限制条件，在需求分析阶段提出这类需
求,并不是要取代设计(或实现)过程,只是说明用户或环境强加给项目的限制条件,常见的约束有:精度；工
具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台
    7.逆向需求
    逆向需求说明软件系统不应该做什么,理论上有无限多个逆向需求,人们应该仅选取能澄请真实需求且
可消除可能发生的误解的那些逆向需求,例如,“应力分析程序无须分析桥梁倒塌数据”
    8,将来可能提出的要求
    应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求,这样做的
目的是,在设计过程中对系统将来可能的扩充和修改预做准备,以便一且确实需要时能比较容易地进行这种
扩充和修改。

3.1.2 分析系统的数据要求
    任何一个软件系统本质上都是信息处理系统,系统必须处理的信息和系统应该产生的信息在很大程度
上决定了系统的面貌,对软件设计有深远影响,因此,必须分析系统的数据要求,这是软件需求分析的一个重
要任务。分析系统的数据要求通常采用建立数据型的方法。
    复杂的数据由许多基本的数据元素组成。数据结构表示数据元素之间的逻辑关系。利用数据字典可以
全面准确地定义数据,但是数据字典的缺点是不够形象直观。为了提高可理解性,常常利用图形工具助描绘
数据结构。常用的图形工具有层次方框图和Warier图。
    软件系统经常使用各种长期保存的信息,这些信息通常以一定方式组织并存储在数据库或文件中,为减
少数据冗余,避免出现插入异常或删除异常,简化修改数据的过程,通常需要把数据结构规范化(范式)

 3.1.3 导出系统的逻辑模型

    综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图，实体联系图，状态转换图，数据字典和主要的处理算法描述这个逻辑模型。

3.1.4 修正系统开发计划

    根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。