软件工程期末复习（6）需求分析的任务

需求分析

需求分析的任务

“建造一个软件系统的最困难的部分是决定要建造什么……没有别的工作在做错时会如此影响最终系统，没有别的工作比以后矫正更困难。”                                                      

                                                                                                                     —— Fred Brooks

 

需求难以建立的原因：

• 误解
• 交流障碍
• “完整性”问题
• 需求永远不会稳定
• 用户意见不统一
• 错误的要求
• 认识混淆

 

需求为何重要？------软件项目失败的原因：

•  不完整的需求（13.1%）
• 缺少用户的参与（12.4%）
• 缺乏资源（10.6%）
• 不切实际的期望（9.9%）
• 缺乏行政支持（9.3%）
• 改动需求和说明（8.7%）
• 缺少计划（8.1%）
• 不再需要该系统（7.5%）

需求为何重要？------有关软件错误的一些认识：

事实1： 在软件生命周期中，一个错误发现得越晚，修复错误的费用越高

事实2：   许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 

Boehm从TRW公司所做的软件项目中得出结论：所有被检测出来的错误中的54％实际上是在编码和单元测试阶段以后才被发现的；更糟糕的是，此类错误中的绝大部分（占45％）是属于需求和设计阶段的，而编码阶段的错误只占9％。 

事实3:     在需求过程中会产生很多错误

DeMarco在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求规格说明书中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。

事实4：   在需求阶段，代表性的错误为疏忽、不一致和二义性 

美国海军研究实验室对海军A-7E飞机上的飞行操作程序进行实地测试，得出的研究数据表明： A-7E项目中77％的需求错误特点是不明确－疏忽、不一致和二义性。

• 49％ 不正确的事实
• 31％ 疏忽
• 13％ 不一致
• 5％  二义性
• 2％  放错位置

 事实5 ：  需求错误是可以被检查出来的

Basili和Weiss的数据表明：在A-7E的软件定义文档中，33％的需求错误是通过人工检查出来的。 Celko觉得利用自动分析工具能够从SRS中检查出来相当数量的错误。

由上面这些事实，能得出如下四点结论：

• 在需求过程中会产生很多错误（事实3和4）
• 许多错误并没有在早期被发现（事实2）
• 这样的错误是能够在产生的初期被检查出来的（事实5）
• 如果没有及时检查出来这些错误，软件费用会直线上升（事实1）

需求过程不仅是可能的而且也是值得的

什么是需求？

• 需求：就是系统的特征，或对系统为达到某个目标所能做的事情的一个描述。
• 需求：是对问题信息和系统行为、特性、设计及制造约束的描述的集合。
• 需求过程本质：在问题空间与求解空间中间架设桥梁。

项目干系人（Stakeholder）

• 直接或间接从正在开发的系统中获益的人
  • 业务运行管理人员
  • 产品管理人员
  • 市场销售人员
  • 内部和外部客户
  • 最终用户
  • 顾问
  • 产品工程师、软件工程师、支持和维护工程师以及其他人员

 项目干系人需求、系统需求：

• 需求可能首先从项目干系人角度表达为一个非形式化的、不详细的、高层的描述，称为项目干系人需求（客户需求）；
• 然后从开发者角度出发，发展成更详细的形式，即系统需求。

功能需求、非功能需求

功能需求：系统与环境间的交互——描述系统必须支持的功能和过程的系统需求。

非功能需求：客户给出的具体约束、指标——描述操作环境和性能目标的系统需求。

二者的区别：功能需求描述系统应该做什么，非功能需求则为如何实现这些需求设定约束。

例如：

功能需求可能声明：系统必须提供一些验证系统用户身份的工具。

非功能需求可能声明：验证过程必须在4秒内完成。

应该考虑到的非功能需求 

• 性能：实时性、资源利用、硬件配置限制、精确度
• 可靠性：有效性、完整性
• 安全/保密性
• 运行限制：使用频度、运行期限、控制方式（如本地或远程）、对操作员的要求
• 物理限制：系统的规模等限制
• 用户界面友好性：易用性

需求的特征

• 正确性：要确保需求的表达中没有引入错误（faults）。
• 一致性：确保没有互相冲突、矛盾的需求；确保没有不确定的需求。
• 完整性：如果需求描述了所有可能的状态，以及状态的变化、输入、过程和约束，那么这组需求就是完整的。
• 现实性：确保客户要求系统做的事真的能做到。
• 实用性：确保需求和要解决的问题有直接关系。
• 可检验性：必须能写出测试来说明需求已被满足。
• 可回溯性：保证每个系统功能都能追溯到一组要求它的需求；确保很容易找到处理系统特定方面的某一组需求。 

需求文档

需求文档的可能使用者：

• 系统客户：需要阅读需求文档来检验是否表达了他们的需要；
• 软件项目管理者：需求文档是制定项目计划的基础之一；
• 系统工程师：需要理解待开发系统；
• 系统测试工程师：要依据需求文档制作测试用例，验证开发出的系统是否满足要求；
• 系统维护人员：使用需求文档理解初始系统的特性和系统不同部分之间的关系。

两种需求文档：

• 需求定义（需求描述）
  • 用应用域术语编写
  • 彻底列举客户/用户想要系统做些什么
  • 由客户/用户和开发人员共同编写
• 需求规约（软件需求规格说明，Software Requirements Specification）
  • 用开发人员擅长的技术术语编写
  • 需求定义的技术性版本，方便设计人员理解
  • 由分析人员编写

需求分析的任务

• 必须理解并描述问题的信息域，根据这条准则应该建立数据模型；
• 必须定义软件应完成的功能，这条准则要求建立功能模型；
• 必须描述作为外部事件结果的软件行为，这条准则要求建立行为模型；
• 必须对描述信息、功能和行为的模型进行分解，用层次的方式展示细节

• 确定对系统的综合要求

  • 功能需求
  • 性能需求
  • 可靠性和可用性需求
  • 出错处理需求
  • 接口需求：用户接口需求；硬件接口需求；软件接口需求；通信接口需求
  • 约束：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台 逆向需求
  • 将来可能提出的要求

• 分析系统的数据要求

  • 建立数据模型
    • E-R图
  • 复杂数据结构的描述
    • 数据字典
    • 层次方框图
    • Warnier图
  • 数据库
    • 数据规范化

• 导出系统的逻辑模型

  • 软件系统详细的逻辑模型通常用数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述

• 修正系统的开发计划

  • 可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。