需求分析
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
行分解，用层次的方式展示细节。
3.1 需求分析的任务
需求内容 逻辑模型 修正系统开发计划
需求内容(I)
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求
资源使用需求
成本消耗需求
开发进度需求
预先估计以后 系统可能达到 的目标
需求内容(II)
需求分析的基本任务是准确地回答“系统 必须做什么?”这个问题。
确定系统必须完成哪些工作，对目标系统 提出完整、准确、清晰、具体的要求。
在需求分析阶段结束之前，系统分析员应 该写出软件需求规格说明书（Software Requirement Specification ），以书面形 式准确地描述软件需求。
修正系统开发计划
根据在分析过程中获得的对系统的更深入更 具体的了解，可以比较准确地估计系统的成本 和进度，修正以前制定的开发计划。
3.2 信息收集技术
主要问题 复查现有报表、表格和过程描述 访谈 观察并记录商业过程 建立原型 分发收集调查表 主持联合应用程序设计会议 面向数据流分析 简易规格说明书
1 主要问题
主题
对用户来说的问题
商业过程和操作是什么 你要干什么
商业过程应该怎样完成 如何完成它？需要哪些步骤？
需求什么样的信息
你要使用哪些信息？你要使用什 么样的表单或报告？
表 信息收集中的主要问题
2 复查报表、表格和过程描述
商业文档和过程描述是了解过程的一个好方 法。 表格和报表可以为面谈提供可视化的帮助、 也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不会 提及的商业规则。 有助于发现商业过程中的不一致和冗余。
接口需求描述应用系统与它的环境通信 的格式。常见的接口需求有：用户接口需 求；硬件接口需求；软件接口需求；通信 接口需求。
需求内容(IV)
5. 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？
需求内容(V)
6. 数据需求 输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？
面谈之前
确立面谈目的 确定要包括的相关用 户
确定参加会议的项目 小组成员
建立要讨论的问题和 要点列表
复查有关文档和资料 确立时间和地点 通知所有参加者有关 会议的目的、时间和地 点
3 面谈
进行面谈
衣着得体 准时到达 寻找异常和错
误情况
深入调查细节 详细记录
1. 功能需求 这方面的需求指定系统必须提供的服务。 通过需求分析应该划分出系统必须完成的 所有功能。 2. 性能需求 软件开发的技术性指标。 例如： 存储容量限制 执行速度、响应时间 吞吐量
需求内容(III)
3. 环境需求 硬件设备：机型、外设、接口、地点、 分布、温度、 湿度、磁场干扰等
软件：操作系统、网络、数据库 4. 接口需求
第3章 需求分析
3.1 需求分析的任务 3.2 信息收集技术 3.3 数据模型 3.4 功能模型 3.5 行为模型 3.6 其他图形工具 3.7 验证软件需求
目标
列举信息收集技术技巧 设计项目的E-R图 设计项目的数据流图 设计项目的状态转换图 了解其他图形工具
第三章 需求分析(I)
需求内容(VI)
7. 安全保密需求 需对访问系统或系统信息加以控制吗？ 用户程序如何与其它程序和数据库系统隔离？ 系统备份要求？ 8. 质量保证 系统的可靠性要求？
规定系统平均出错时间？
出错后，重启系统允许的时间？
维护是否包括对系统的改进？
系统的可移植性？
逻辑模型
数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图）
学生购买教材的实际处理流程—当前系统物理模型 购
书
购
申
书
发
学 请 教务科 单 会计室 票 出纳员
生
107
购张
206
206
王
李
书
购
申
书
发
学 请 审查 生 有效性
单
票
开发票
开领 书单
领
书
单
书 教材科
学
108
生
赵
领
书
单
书学
发书 生
去掉模型中非本质因素，抽象出当前系统的逻辑模型。
5 建立原型 6 分发和收集调查表
第三章 需求分析(II)
所有这些分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这
条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则
要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，
这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进
找出和记录未 回答的条目和未
解决的问题
面谈之后
复查笔记的准确性、 完整性和可理解性
把所收集的信息转 化为适当的模型和
文档
确定需要进一步澄 清的问题域
适当的时间向参加 会议的每一个人发
一封感谢信
4 观察并记录商业过程(I)
观察 使用活动图来进行记录
4 观察并记录商业过程(II)
审查产品需求，列出系统环境组成部分的对象、 系统将产生的对象以及系统为了完成自己的功能 将使用的对象。
列出操作这些对象或与这些对象交互的服务 最后还应该列出约束条件和性能标准。
9 简易的应用规格说明技术(II)
在展示了每个人针对某个议题的列表之后， 大家共同创建一张组合列表。
这些认识正确吗?有没有遗漏?用户应该注意 倾听分析员的报告，并及时纠正和补充分析员 的认识。复查过程验证了已知的元素，补充了 未知的元素，填补了文档中的空白。
9 简易的应用规格说明技术(I)
典型过程如下：
通过初步访谈确定待解决的问题的范围和解决 方案。
然后开发者和用户分别写出“产品需求”。选 定会议的时间和地点，并选举一个负责主持会议 的协调人。
7 主持联合应用程序设计会议
JAD的目的是把所有这些活动压缩为用 户和项目小组成员一起参加得更短的JAD 会议。 参加人员：
JAD会议领导者 用户 技术人员 来自百度文库项目组成员
8 面向数据流自顶向下求精
数据流图是帮助复查的极好工具。
从输入端开始，分析员借助数据流图、数据 字典和IPO图向用户解释输入数据是怎样一步 一步地转变成输出数据的。
3.1 需求分析的任务
需求内容 逻辑模型 修正系统开发计划
需求内容(I)
功能需求 性能需求 环境需求 可靠性需求 安全保密要求 用户界面需求
资源使用需求
成本消耗需求
开发进度需求
预先估计以后 系统可能达到 的目标
需求内容(II)
需求分析的基本任务是准确地回答“系统 必须做什么?”这个问题。
确定系统必须完成哪些工作，对目标系统 提出完整、准确、清晰、具体的要求。
在需求分析阶段结束之前，系统分析员应 该写出软件需求规格说明书（Software Requirement Specification ），以书面形 式准确地描述软件需求。
修正系统开发计划
根据在分析过程中获得的对系统的更深入更 具体的了解，可以比较准确地估计系统的成本 和进度，修正以前制定的开发计划。
3.2 信息收集技术
主要问题 复查现有报表、表格和过程描述 访谈 观察并记录商业过程 建立原型 分发收集调查表 主持联合应用程序设计会议 面向数据流分析 简易规格说明书
1 主要问题
主题
对用户来说的问题
商业过程和操作是什么 你要干什么
商业过程应该怎样完成 如何完成它？需要哪些步骤？
需求什么样的信息
你要使用哪些信息？你要使用什 么样的表单或报告？
表 信息收集中的主要问题
2 复查报表、表格和过程描述
商业文档和过程描述是了解过程的一个好方 法。 表格和报表可以为面谈提供可视化的帮助、 也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不会 提及的商业规则。 有助于发现商业过程中的不一致和冗余。
接口需求描述应用系统与它的环境通信 的格式。常见的接口需求有：用户接口需 求；硬件接口需求；软件接口需求；通信 接口需求。
需求内容(IV)
5. 用户或人的因素 用户类型？ 各种用户熟练程度？ 需受何种训练？ 用户理解、使用系统的难度？ 用户错误操作系统的可能性？
需求内容(V)
6. 数据需求 输入、输出数据的格式？ 接收、发送数据的频率？ 数据的准确性和精度？ 数据流量？ 数据需保持的时间？
面谈之前
确立面谈目的 确定要包括的相关用 户
确定参加会议的项目 小组成员
建立要讨论的问题和 要点列表
复查有关文档和资料 确立时间和地点 通知所有参加者有关 会议的目的、时间和地 点
3 面谈
进行面谈
衣着得体 准时到达 寻找异常和错
误情况
深入调查细节 详细记录
1. 功能需求 这方面的需求指定系统必须提供的服务。 通过需求分析应该划分出系统必须完成的 所有功能。 2. 性能需求 软件开发的技术性指标。 例如： 存储容量限制 执行速度、响应时间 吞吐量
需求内容(III)
3. 环境需求 硬件设备：机型、外设、接口、地点、 分布、温度、 湿度、磁场干扰等
软件：操作系统、网络、数据库 4. 接口需求
第3章 需求分析
3.1 需求分析的任务 3.2 信息收集技术 3.3 数据模型 3.4 功能模型 3.5 行为模型 3.6 其他图形工具 3.7 验证软件需求
目标
列举信息收集技术技巧 设计项目的E-R图 设计项目的数据流图 设计项目的状态转换图 了解其他图形工具
第三章 需求分析(I)
需求内容(VI)
7. 安全保密需求 需对访问系统或系统信息加以控制吗？ 用户程序如何与其它程序和数据库系统隔离？ 系统备份要求？ 8. 质量保证 系统的可靠性要求？
规定系统平均出错时间？
出错后，重启系统允许的时间？
维护是否包括对系统的改进？
系统的可移植性？
逻辑模型
数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图）
学生购买教材的实际处理流程—当前系统物理模型 购
书
购
申
书
发
学 请 教务科 单 会计室 票 出纳员
生
107
购张
206
206
王
李
书
购
申
书
发
学 请 审查 生 有效性
单
票
开发票
开领 书单
领
书
单
书 教材科
学
108
生
赵
领
书
单
书学
发书 生
去掉模型中非本质因素，抽象出当前系统的逻辑模型。
5 建立原型 6 分发和收集调查表
第三章 需求分析(II)
所有这些分析方法都遵守下述准则： (1) 必须理解并描述问题的信息域，根据这
条准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则
要求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，
这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进
找出和记录未 回答的条目和未
解决的问题
面谈之后
复查笔记的准确性、 完整性和可理解性
把所收集的信息转 化为适当的模型和
文档
确定需要进一步澄 清的问题域
适当的时间向参加 会议的每一个人发
一封感谢信
4 观察并记录商业过程(I)
观察 使用活动图来进行记录
4 观察并记录商业过程(II)
审查产品需求，列出系统环境组成部分的对象、 系统将产生的对象以及系统为了完成自己的功能 将使用的对象。
列出操作这些对象或与这些对象交互的服务 最后还应该列出约束条件和性能标准。
9 简易的应用规格说明技术(II)
在展示了每个人针对某个议题的列表之后， 大家共同创建一张组合列表。
这些认识正确吗?有没有遗漏?用户应该注意 倾听分析员的报告，并及时纠正和补充分析员 的认识。复查过程验证了已知的元素，补充了 未知的元素，填补了文档中的空白。
9 简易的应用规格说明技术(I)
典型过程如下：
通过初步访谈确定待解决的问题的范围和解决 方案。
然后开发者和用户分别写出“产品需求”。选 定会议的时间和地点，并选举一个负责主持会议 的协调人。
7 主持联合应用程序设计会议
JAD的目的是把所有这些活动压缩为用 户和项目小组成员一起参加得更短的JAD 会议。 参加人员：
JAD会议领导者 用户 技术人员 来自百度文库项目组成员
8 面向数据流自顶向下求精
数据流图是帮助复查的极好工具。
从输入端开始，分析员借助数据流图、数据 字典和IPO图向用户解释输入数据是怎样一步 一步地转变成输出数据的。