软件测试--需求分析

软件需求分析

1.系统分析

是一组成为计算机系统工程的活动，着眼于所有的系统元素，而不仅仅是软件

主要探索软件项目：目标、市场预期、主要技术指标

2.可行性分析

此问题是否值得去解决

针对问题的目标和范围进行概要的分析和研究，探索问题的核心问题以及相应的解决方案

3.需求定义

用户续期——分析需求——形成文档（文档说明产品必须或应当作甚）

4.目标及任务

任务：定义新系统的目标，回答系统“做什么”的问题，并编制需求规格说明书

目标：解决系统“做什么“的问题

5.原则和方法

操作性原则：

• 问题的信息域必须被表示和理解（数据模型）
• 软件将完成的功能必须被定义（功能莫i选哪个）
• 软件的行为必须被表示（行为模型）

数据模型

信息内容和关系：内容表示个体数据和控制对象，它们可以和其他数据和控制对象相关联

信息流：表述数据和控制在系统中流动时变化的方式

信息结构：表示各种数据和控制项的内部组织

功能模型

对进入软件的信息和数据进行变化和处理的模块：输入，处理和输出

行为模型

软件对来自外界的时间做出的反应，这些反应形成了行为模型的基础

工程化原则：

• 正确的理解问题，建立分析模型
• 记录每个需求的起源及原因，保证需求的可回溯性
• 开发一个人机交互过程的原型
• 给需求赋予优先级
• 尽量删除歧义性

6.软件需求工程

需求开发——《用户需求说明书》：需求沟通，需求获取

需求定义——《软件需求规格说明书》：需求分析与综合；需求建模；制定需求分析规格说明

需求确认——《需求评审报告》《书面承若》：需求评审；需求承诺

1.需求获取

（1）需求获取的对象：用户和客户

用户：使用软件的人

客户：购买软件的人

用户和客户最终可能是同一个人

需求获取的难点：

• 用户无法清楚地表达需求
• 需求分析员必须设法搞清楚用户真正的需求

需求的理解问题：

• 需求分析员和用户可能有误解问题，需求确认工作必不可少（属于需求管理）
• 用户经常变更需求
• 需求变更不可怕，可怕的是需求变更失去控制

（2）需求获取的流程

目的	获取用户（客户与最终用户）的需求信息，经过分析后产生《用户需求说明书》
角色与职责	需求分析员调查、分析用户的需求，客户与最供用户提供必要的需求信息
启动准则	需求分析员已经确定需求
输入	任何与用户需求相关的材料
主要步骤	第一步：准备调查 第二步：调查与记录 第三步：分析需求信息 第四步：撰写《用户需求说明书》 第五步：需求确认
输出	《用户需求说明书》
结束准则	需求分析员已经撰写完成《用户需求说明书》（确保无误），《需求说明书》内容无二义性，且涵盖了所有的用户需求
度量	需求分析员统计工作量与上述文档的规模，汇报给项目经理

（3）需求获取的准备工作

调查什么？如何调查？“什么人”在“什么时候”调查？（调查表，调查的方式，调查的时间、地点、人员）

方式

• 与用户交谈，向用户提问题
• 参观用户的工作流程，观察用户的操作
• 向用户群体发调查问卷
• 与同行、专家交谈，听取意见
• 分析已经存在的同类软件产品，提取需求
• 从行业标准、规则中提取需求
• 从网上搜查相关资料

（4）需求获取与记录

表格形式

（5）撰写用户需求说明书

《用户需求说明》使用自然语言描述用户的需求

《软件需求规格说明书》计算机语言和图形符号

（6）软件需求类型

功能需求 性能需求 环境需求 可靠性需求
安全保密要求 用户界面需求 资源使用需求
软件成本消耗与开发进度需求
预先估计以后系统可能达到的目标

2.需求定义

目的	定义准确无误的软件产品需求，产生《软件需求规格说明书》
角色和职责	需求分析员定义软件需求，客户与最用户确认软件需求
启动准则	《用户需求说明书》撰写完成
输入	《用户需求说明书》
主要步骤	第一步：细化分析用户需求 第二步：撰写软件需求规格说明书 第三步：软件需求确认
输出	《软件需求规格说明书》
结束准则	《软件需求规格说明书》撰写完成，开发方和客户方对产品需求进行确认
度量	需求分析员统计工作量和文档的规模，汇报给项目经理

需求获取之后，对比较复杂的用户需求进行建模分析，帮助开发人员更好地理解需求。
在模型基础上，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满足功能要求，是否合理。
依据功能需求，性能需求，运行环境需求等，剔除其不合理的部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。

（1）需求建模

着重描述系统必须做什么

给出逻辑视图（逻辑模型）和物理视图（物理模型）

逻辑视图：软件要达到功能和处理数据之间的关系（不是实现细节）

物理模型：处理功能和数据结构的实际表达形式（取决于设备）

方法：

• 面向对象的分析方法（OOA）
• 面向数据流的结构化分析方法（SA）
• 面向数据结构的Jackson方法
• 建立动态模型的状态转换图登

（2）编制需求分析文档

• 软件需求规格说明书
• 数据要求说明书
• 初步的用户手册
• 修改、完善和确定软件开发实施计划

3.需求确认

目的	开发方和客户对需求文档进行评审，并作书面承诺
角色和职责	开发方和客户共同组织人员对需求文档进行评审。双方负责人对需求文档作书面承诺，使之有商业合同效果
启动准则	《用户需求说明书》和《软件需求规格说明书》已完成
输入	《用户需求说明书》和《软件需求规格说明书》
主要步骤	第一步：非正式需求评审 第二步：正式需求评审 第三步：获取需求承诺
输出	《需求评审报告》和书面的需求承诺
结束准则	需求文档通过正式评审，并获得开发方和客户的书面承诺
度量	项目经理统计工作量和上述文档的规模

评审的主要内容

• 系统定义的目标是否与用户的要求一致
• 系统需求分析阶段提供的文档资料是否齐全
• 文档中的所有描述是否完整、清晰、准确反映用户要求，有没有遗漏、重复或不一致的地方
• 与所有其他系统成分的重要接口是否都已经描述
• 所开发项目的数据流与数据结构是否足够，确定
• 所有图表是否清楚，在不补充说明时能否理解
• 主要功能是否已包括在规定的软件范围之内，是否都已充分说明
• 系统的约束条件或限制条件是否符合实际
• 开发的技术风险是什么
• 是否考虑过软件需求的其他方案
• 是否考虑过将来可能会提出的软件需求
• 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认
• 软件开发计划中的估算是否受到了影响