第3章需求分析详解

合集下载

需求分析PPT课件

需求分析PPT课件
19
3.2.2 面向数据流的自顶向下求精
❖ 回溯过程中需要回答两个问题深入调查
输出数据的组成?
输出数据的来源?
外部输入或 系统生成
20
3.2.2 面向数据流的自顶向下求精
❖ 回溯时常遇到的问题:为了得到某个数据元素需要 用到数据流图中还没有的数据元素,或者得出这个 数据元素要用的算法尚不完全清楚。
求要不断迭代) ❖ 注意区别”可行性分析”和”需求分析”的
异同; ❖ 设计出系统的”数据模型”、细化的“逻辑
模型”和“行为模型”;(关键所在) 3
需求分析做什么?
所有的结构化分析方法都遵守下述准则:
(1) 必须理解并描述问题的信息域,根据这条 准则应该建立数据模型。
(2) 必须定义软件应完成的功能,这条准则要 求建立功能模型。
❖ 确定系统综合要求和分析系统数据要求顺利 完成之后即可导出详细的系统功能模型。
❖ 阶段性成果:
细化后并经过多次校验的数据流图(DFD) 与数据流图相辅相存的数据字典(DD) 概要性的描述主要加工的处理算法(IPO)
10
3.1.4 分析和设计系统的行为模型
❖ 确定系统的动态变化的方式,采用状态转换 图来描述。
❖ 系统分析员应该从不同角度抽象出目标 系统的特性,使用精确的表示方法构造
系统的模型。
数据角度、功能角 度、行为角度
DFD、DD、STD、 E-R
35
模型的作用
现实世界
影射
计算机世界
36
模型的作用
现实世界

OOA
向 对

开 OOD 发

OOP 法
结构化
结 分析

化 结构化 开 设计

第3章-需求分析课件

第3章-需求分析课件

❖ 2。需求分析
❖ 这个阶段对已收集的需求进行提炼、分析和审查,即对问 题的分析和方案的综合,确保所有的需求含义都被理解, 并找出可能错误,遗漏或不足的地方。
❖ 分析人员在这一步骤中的任务是根据对问题及其环境的理 解与软件开发经验,改正用户需求的模糊性、歧义性和不 一致性,排除由于用户的片面性和短期行为所导致的不合 理要求、挖掘用户尚未提出但具有价值的潜在需求,并在 用户的帮助下对相互冲突的要求进行折衷,使用户需求逐 步精确化、一致化和完全化。
经过评审确认的需求规格说明将成为客户方与开发方的 合同。如果评审未通过,比如发现了遗漏或错误,则必 须进行迭代,直至通过评审为止。
需求分析的任务
与软件实际运行相关的需求分析任务
1、确定对系统的综合要求 2、分析系统的数据要求 3、异出系统的逻辑模型 4、修正项目开发划 5、开发原型系统
3.3.2 需求分析的一般性技术
在分析阶段构筑的模型不应涉及软件实现的细节,以免分散分 析人员的注意力、限制软件设计人员为提高软件质量和效率而 选择实现方法的自由度。
需求分析结束时确立的软件模型是生成需求规格说明的依据, 也是软件设计和实现的基础。
3.3.2.3 快速原型技术
如果按照传统的软件开发方法,需要经过漫长的开 发时间之后用户才能看到目标软件的最初版本。此 时用户常常会提出许多修改意见,有时甚至全盘否 定,导致开发失败。为了降低开发风险,在需求分 析阶段常常采用快速原型技术。
发挥。 ③所提问题汇总后应能反映应用问题及其子问题的全貌、并且
不要过分详细。
2.观察用户工作流程
如果可能,可通过实际观察用户的手工操作过 程来提取新系统的初步用户需求。
观察手工操作过程不是为了模拟手工操作过程, 而是为了获取第一手资料,并从中提取出有价 值的需求。分析人员有了第一手资料,再结合 自己的软件开发和应用的经验,就能够发现不 合理的用户需求、提出用户还没有意识到的潜 在的但却很有价值的用户需求,并能够从软件 的角度改进操作流程和操作规范,从而可获得 用户满意的分析结果。

第3章_需求分析

第3章_需求分析
• 输入输出数据的格式 • 数据的取值范围 • 接收或发送数据的频率 • 数据的精确性如何? • 数据必须保存多久时间?
需求内容——接口
• 有来自其它系统的输入吗 • 有到其它系统的输出吗 • 对数据格式有规定吗 • 对数据存储介质有特殊要求
需求内容——性能
• 对执行速度有无限制? • 对响应时间有无限制? • 对吞吐率有无限制? • 对存储容量有无限制?
• 系统的可靠性如何? • 系统必须监测和隔离错误吗? • 平均出错时间为多少? • 系统可移植性如何?
需求内容——安全性
• 必须对访问系统或系统信息加以控制吗? • 一个用户的数据与其他用户的数据关系
如何? • 用户程序与其它程序或操作系统要隔离
开来吗? • 多长时间需要备份? • 备份数据存放位置 • 需要防火或防盗吗?
2.在对数据流图分层细化时,必须保持信息的连续 性。即:分解前、后的输入/输出数据流必须相同。
3.在功能级数据流图中,可根据需要给处理和数据 存储增加编号,便于引用和追踪。同时编号应反 映处理的分解层次;
4.一张数据流图中的包含的处理控制在5~9个,因此 数据流图应该使用分层和画分图的方法。
需求获取的内容
• 功能性需求和非功能性需求. • 功能性需求:定义系统做什么,包括系统的
所有输入,输出,以及如何从输入到输出. • 非功能性需求(性能):系统对效率,可靠性,
安全性,可维护性,可移植性,吞吐量及符合 某种标准等要求.
需求内容——功能
• 系统将做什么? • 系统何时及如何修改?
需求内容——数据
• 二个阶段:需求获取和需求规约. • 系统分析员 • 对象:用户 • 目标:对要达到的目标或所解决的问题有
一个清楚而明确的认识. • 成果:需求规格说明书

第3章 需求分析

第3章 需求分析

网上查某 本书<3秒
图书名称 /作者姓 名
按照输入的组 合条件,进行 模糊查询
显示“图书名称、作 者姓名、是否借出、 内容简介”
2
后台查询读 者信息响应 时间 后台查询图 书信息响应 时间
图书 馆借 阅部 图书 馆借 阅部
借阅 操作 员 借阅 操作 员
后台查某 读者信息 <2秒 后台查某 部书<2秒
案例3-3 【案例3-3】网上图书馆信息系统的部分接口列表,如 表3-3所示。 表3-3 目标系统的接口列表(接口模型)
3.2 需求分析的任务及过程
表3-3 目标系统的接口列表(接口模型)
编 号 接口 名称 接口 规范 接口 标准 入口参数 出口参数 传输 速率
1
与财 务系 统接 口
财务 系统 规定 的接 口规 范
3.2 需求分析的任务及过程
图3-2需求分析过程
3.2 需求分析的任务及过程
根据实际项目的规模和特点确定合适的需求分析常规过 程如下。 1.需求获取 2.综合需求与描述 3. 需求验证 4.需求文档
课堂讨论:
(1)需求分析具体任务有哪些? (2)需求分析常规步骤是什么?
3.2 需求分析的任务及过程书信息系统的 部分性能点列表(性能模型),如表 3-2所示。
3.2 需求分析的任务及过程
表3-2 图书馆系统的性能点列表
编号 性能名称 使用 部门 网上 读者 使用 岗位 网上 读者 性能描述 输入 系统响应 输出
1
读者网上查 询图书信息 响应时间
一张 凭证 一次 处理 传送
3.2 需求分析的任务及过程
7.确定系统运行环境及界面 8.修正开发计划和新系统方案 9. 编写需求文档,验证确认需求 【注意】上述任务要具体分析,灵活运用。如果需求 分析之后,对将要实现的新系统,仍然感到不够明确时, 不应签字确认,还需进行进一步深入分析。

03需求分析PPT课件

03需求分析PPT课件
用户类型? 各种用户熟练程度? 需受何种训练? 用户理解、使用系统的难度? 用户错误操作系统的可能性?
2020年9月28日
15
(6) 文档需求
需哪些文档? 文档针对哪些读者?
2020年9月28日
16
(7) 数据需求
输入、输出数据的格式? 接收、发送数据的频率? 数据的准确性和精度? 数据流量? 数据需保持的时间?
2020年9月28日
19
(10) 软件成本消耗与开发进度需求
开发有规定的时间表吗? 软硬件投资有无限制?
2020年9月28日
20
(11) 质量保证
系统的可靠性要求?
系统必须监测和隔离错误吗? 规定系统平均出错时间? 出错后,重启系统允许的时间? 系统变化如何反映到设计中? 维护是否包括对系统的改进? 系统的可移植性?

描述现实系统是 如何在物理上实 现的。
目 描述新系统的主要 标 业务功能和用户新 系 的需求,无论系统 统 应如何实施。
2020年9月28日
描述新系统是如 何实施的(包括 技术)。
23
需求分析过程示意
(1) 通过对现实环境的调查,获取请
教务科
购 书 单
12
(3) 环境需求
硬件设备:机型、外设、接口、 地点、分布、温度、 湿度、磁场干扰等
软件: 操作系统 网络 数据库
2020年9月28日
13
(4) 界面需求
有来自其它系统的输入吗? 到自其它系统的输出吗? 对数据格式有规定吗? 对数据存储介质有规定吗?
2020年9月28日
14
(5) 用户或人的因素
准确地定义未来系统的目标,确定为了 满足用户的需求“系统必须做什么”。用 《需求规格说明书》规范的形式准确地表 达用户的需求。

第3章 需求分析

第3章 需求分析
6
软 件 工 程
4. 出错处理需求
这类需求说明系统对环境错误应该怎样响应。例如,如果它接收到 从另一个系统发来的违反协议格式的消息,应该做什么?注意,上述这 类错误并不是由该应用系统本身造成的。 在某些情况下,“出错处理”指的是当应用系统发现它自己犯下一 个错误时所采取的行动。但是,应该有选择地提出这类出错处理需求。 我们的目的是开发出正确的系统,而不是用无休止的出错处理代码掩盖 自己的错误。总之,对应用系统本身错误的检测应该仅限于系统的关键 部分,而且应该尽可能少。 3.7.6 故障处理 a. 内部故障处理 在开发阶段可以随即修改数据库里的相应内容。 b. 外部故障处理 对编辑的程序进行重装载时,第一次装载认为错,修改。第二次运 行,在需求调用时出错,有错误提示,重试。
(1)必须理解并描述问题的信息域,根据这条准则应该建 立数据模型。 (2)必须定义软件应完成的功能,这条准则要求建立功能 模型。 (3)必须描述作为外部事件结果的软件行为,这条准则要 求建立行为模型。 (4)必须对描述信息、功能和行为的模型进行分解,用层 次的方式展示细节。
12
第 3 章 需 求 分 析
据存储(可行性研究得到的高层数据流图)定义到元素级。
沿数据流图从输出端往输入端回溯着手分析。
第 3 章 需 求 分 析
图3.1 面向数据流自顶向下求精过程
15
3.2.3 简易的应用规格说明技术 软 件 工 简易的应用规格说明技术(面向团队的而求收集法)提倡用户 程 与开发者密切合作,共同标识问题,提出解决方案要素,商讨不同
18
软 件 工 程
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外,还应该写出软件 需求规格说明书,它是需求分析阶段得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统的数据要 求、功能需求、性能需求、可靠性和可用性要求、出错处理 需求、接口需求、约束、逆向需求以及将来可能提出的要求。 自然语言的规格说明具有容易书写、容易理解的优点,为大 多数人所欢迎和采用。 为了消除用自然语言书写的软件需求规格说明书中可能 存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题, 有些人主张用形式化方法描述用户对软件系统的需求,第4章 将简要地介绍形式化说明技术。

第3章需求分析

第3章需求分析
状态转换图(STD)
需求分析的任务
5、编写需求规格说明书和开发计划 根据上述的阶段性成果,汇总为“软件
需求规格说明书”,以提交评审 在可行性分析的基础上,较准确地估计
系统的开发成本和进度 修正开发计划
需求分析的任务--举例
馆长和馆员
配合 走 访 客 户 , 调 研 业务流程
调研 分析师
记录调研过程资料
与用户沟通获取需求的方法
需求获取是否彻底与成功,直接关系到软 件开发的成败。
需求获取为什么难?
(1)用户需求具有动态性,即需求的不稳定性:在整个软 件生命周期内,需求会随着时间的进展而有所变化。
(2)用户需求具有模糊性:由于用户的需求表达不很清楚 也不够明确。
与用户沟通获取需求的方法
1、需求获取技术
回溯时常遇到的问题:为了得到某个数据元素需要 用到数据流图中还没有的数据元素,或者得出这个 数据元素要用的算法尚不完全清楚。
因此,需要向用户等有关人员请教,使分析员对目 标系统的认识更深入具体,更多的数据元素被划分 出来,更多的算法搞清楚了。
把分析过程中得到的数据元素记录在数据字典中, 把对算法的简明描述记录在IPO图中,并添加到数据 流图的适当位置上。
与用户沟通获取需求的方法
数据流图是帮助用户复查需求的极好工具; 分析员向用户解释数据的来源(组成和处理,反映
了分析员对系统已有的认识。) 用户要及时纠正和补充分析员的认识
它验证了已知的元素,补充了未知的元素,填补了 文档中的空白;
分析员对系统的认识是一个螺旋式上升的过程。
与用户沟通获取需求的方法
外部输 入或系 统生成
与用户沟通获取需求的方法
输入数据
加工: f g k
输出数据

第3章 需求分析及功能建模方法

第3章 需求分析及功能建模方法

第3章需求分析及功能建模方法3.1 需求分析概述3.1.1 需求分析概念1、所谓需求分折:就是对待开发的系统要做什么,完成什么功能的全面描述。

2、需求分析的工作:通过对需求的调查、了解、观察和分析,通过对原始数据的收集、分类和抽象,并采用有效的技术、工具,对原始资料进行加工整理,描述开发目标、实现的功能及其相互关系等活动的集合;3、需求的定义:客户对一个待开发的系统在实现目标、完成功能、应达到的性能、安全性、可靠性等方面的期望和要求的集合;4、需求获取的困难:(1) 软件功能复杂;(2) 需求的可变性;5、需求分析阶段的主要任务:分析当前的业务流程,包括体系结构,各职能部门完成的主要任务、关系及其交流的信息。

6、需求分析的结果通常以模型等建模工具和方法描述系统的信息流、功能结构及完成各功能需要的数据。

7、功能模型和软件需求规格说明书是软件开发的依据,将指导后续的开发工作。

8、需求分析工作是系统分析员与用户不断交互的过程中完成的。

3.1.2 系统分析员的职能1、系统分析员的主要要任务:是确定应用信息系统及软件产品应该达到的各项功能性要求和非功能性要求,即用户要做什么。

2、系统分析员应该具备的素质:(1) 获取需求的能力;(2) 管理及沟通能力;(3) 技术素养;3.1.3 需求获取的方法常用的几种获取需求的方法:(1)面谈;(2)实地观察;(3)问卷调查;(4)查阅资源;3.1.4 需求分析过程1、标识问题:(1) 需求分析的第一步,通过对问题的识别和标识获得所求解问题及其运行环境的理解;(2) 标识问题从现行系统的业务流程做起,理解现行系统的业务流程;(3) 在标识理解需求的同时,还要注意确定系统的人机界面;2、建立需求模型:(1) 模型是对现实原形所作的一种抽象,其本质是只关心与研究内容有关的因素,而忽略无关的因素,其目的是把复杂的事物变得简单,便于认识和分析;(2) 目前常用的模型方法主要有DFD数据流图和IDEFO,都属于结构化分析方法,其特征是抽象和分解;(3) 首先对应用领域进行全面的分析,发现并找出同类事物的本质,用抽象方法把这类事物的非主要方面剔除,把握住事物的内部规律或本质,就可以找到解决办法;然后采用自上而下逐步求精的方法对复杂的问题进行分解;(4) 结构化分析及建模方法的主要优点:(A) 不过早陷入具体的细节;(B) 从整体或宏观入手分析问题;(C) 通过图形化的模型对象直观地表示系统要做什么,完成什么功能;(D) 图形化建模方法方便系统分析员理解和描述系统;(E) 模型对象不涉及太多的技术术语,便于用户理解;3、描述需求:(1) 需求描述的目标:对软件项目功能性和非功能性的需求全面描述;(2) 功能性需求:指需要计算机实际解决的问题或实现的具体功能,明确描述系统必须做什么,实现什么功能以及输入输出等;(3) 非功能性需求:软件项目对实际运行环境的要求;(4) 需求描述主要由需求模型和需求说明书组成,说明书侧重文字说明,内容如下:需求概述;功能需求;信息需求;性能需求;环境需求;其他需求;(5) 在对需求进行分析过程中,系统分析员要经常考虑的问题:(A) 描述的需求是完全的吗?(B) 需求描述是正确的和一致的吗?(C) 描述的这些需求是可行的、实际可操作的吗?(D) 描述中的每一条需求都是客户需要的吗?4、确认需求:1、评审委员会审核下列内容:功能需求;数据需求;性能;数据管理;其他需求。

第3章 需求分析-大纲

第3章 需求分析-大纲

第三章需求分析
3.1 需求分析的任务和步骤
——需求分析的任务
……确定对系统的综合要求
……分析系统的数据要求
……建立软件的逻辑模型
——确定对系统的综合要求
……功能性需求
……非功能性需求:可用性,可靠性……
——分析系统的数据要求
……数据字典——定义数据
……层次方框图——定义数据结构
——建立软件的逻辑模型:数据流图、数据字典、实体-联系图、主要算法
——编写软件需求规格说明书
——需求分析评审
3.2 需求获取的常用方法(5个)
——访谈
——问卷调查
——观察用户工作流程
——建立联合分析小组
——快速原型法
3.3 需求分析的方法(4个)
——功能分解法:软件需求当做一棵倒置的功能树
——结构化开发方法:结构化分析、结构化设计和结构化程序设计
——信息建模方法:实体-联系图
——面向对象的分析
3.4 结构化分析技术
——思路:基于数据流图自顶向下逐层分解
3.5 需求分析图形工具
——实体-联系图(Entity-Relationship Diagram)
……实体定义:对软件必须理解的复合信息的抽象
……属性定义:数据对象的性质
……联系定义:数据对象彼此之间相互连接的方式
——数据字典
……定义:数据字典是关于数据的信息的集合,也就是对数据流图中包含的
所有元素的定义的集合。

……四类元素:数据流,数据流分量(即数据元素),数据存储,处理——层次方框图
……定义:用树型结构的一系列多层次的矩形框描绘数据的层次结构。

——IPO图(Input Process Output)。

需求分析详解PPT课件

需求分析详解PPT课件
6. 由一名或多名与会者根据会议成果起草完整的软件需求规 格说明书。
第19页/共61页
3.2.4 快速建立软件原型
• 快速建立软件原型是最准确、最有效、最强大的需求分析技术。所谓软件原型,就是快速建立起来的旨在 演示目标系统主要功能的可运行的程序。
• 构建软件原型的要点是,它应该实现用户看得见的功能,省略目标系统的“隐含”功能。 • 软件原型的应该具备的第一个特性是“快速”,第二个特性是“容易修改”。
第5页/共61页
• 在分析软件需求和书写软件需求规格说明书的过程 中,分析员和用户都起着关键的、必不可少的作用。
第6页/共61页
第3章 需求分析
• 所有的需求分析方法都遵守下述准则: • (1) 必须理解并描述问题的信息域,根据这条准则应该建立数据模型。 • (2) 必须定义软件应完成的功能,这条准则要求建立功能模型。 • (3) 必须描述作为外部事件结果的软件行为,这条准则要求建立行为模型。 • (4) 必须对描述信息、功能和行为的模型进行分解,用层次的方式展示细节。
• 当需要调查大量人员的意见时,请被调查人填写调查表是十分有效的做法。
第13页/共61页
3.2.1 访谈
• 在访问用户的过程中使用情景分析技术往往十分有效。所谓情景分析,就是对用 户将来使用目标系统解决某个具体问题的方法和结果进行分析。系统分析员利用 情景分析技术往往能够获知用户的具体需求。
• 情景分析技术的用处主要体现在下述两个方面: (1) 它能在某种程度上演示目标系统的行为,从而便于用
第10页/共61页
3.1 需求分析的任务
任务3:导出系统的逻辑模型 综合上述两项分析的结果可以导出系统的详细的逻辑模型,通常用数据流图、实体-联系图、状态转换图、

软件工程 03_需求分析

软件工程 03_需求分析

X.第3章需求分析•需求分析的目标就是搞清楚用户真正想要的系统是什么以及存在哪些约束条件。

•需求分析是软件开发的输入,“垃圾入,垃圾出”,所谓“失之毫厘,谬以千里”。

•需求分析的捕获和描述、需求分析的细化、功能性需求和非功能性需求等。

需求分析的挑战•无章法的软件开发,尤其是在开发过程上游中的需求分析,很容易导致整个项目的失败。

•分析阶段开发人员需要与未来系统相关的领域专家们在一起工作。

对于软件开发者来说,这是一个学习未知领域的过程,是建造一个新的世界的开始。

需求跟踪•给出针对每个源需求及对应目标实现,将它们通过某种方式联系起来。

-从用例图到活动图的转换-从活动图或者动作(action)到文本需求的转换-从文本需求到类或者实例变量、方法和方法参数的转换•文档记录的方法,大规模系统难以满足要求。

•CASE工具。

业务\|需求\|类模型、跟踪的作用•需求变更影响范围如何•从类逆向追溯需求,可以获知实现的改动会影响到哪些原始需求•除此之外,跟踪信息还可以附加对应连接创建的时间、属于增量开发的哪个周期等•测试用例和需求之间的跟踪连接,可以方便的确定出哪些需求已经进行了测试,哪些还存在遗漏,对于掌握和提高测试的完备性具有重要的指导意义•在CMM三级中要求软件组织必须具备需求跟踪的能力需求跟踪矩阵•实践中常使用需求跟踪矩阵(RTM)对变更进行管理,包括需求变更、设计变更、代码变更、测试用例变更等•需求跟踪矩阵是变更波及范围影响分析的有效工具•可将RTM划分为两类:纵向跟踪矩阵和横向跟踪矩阵。

•纵向跟踪矩阵,包括如下的3种跟踪内容:-需求之间的派生关系,如客户需求到系统需求;-实现与验证的关系,如需求到设计、需求到测试用例等;-需求的责任分配关系,需求由谁负责。

•横向跟踪矩阵包括需求之间的接口关系等。

•需求跟踪矩阵只要能够保证需求链的一致性和状态的跟踪就可以,有不同的实现方法。

第3章 需求分析.ppt

第3章 需求分析.ppt

分析




调查表法

观察法
业务需求



可行性报告 概要 用户
与 方 法
系统定义报告 信息
功能需求 用户需求
非功能性需求
银行ATM系统(1)
银行ATM系统(2)
31




概系
述统
--
需 求 分
分 析 员







需求分析
需求获取
分析、处理
获取数据
目标逻辑模型
从数据流和数据结构出 发,找出系统各元素之 间的联系、接口特征及 设计限制、能否满足功
31 需
需求评审 与确认





--

评审、验证
求 分
的四个方面







一致性 完整性 现实性 有效性
所有需求必须一致, 不能前、后和相互
矛盾
说明书应包括用户需 求的每一方面
在现有基础上可 实现
必须证明需求有效, 能解决用户提出的
问题
二、需求分析的方法
31





--
述 分析
需 求
方法
软件需求的问题(1)
软件需求的问题(2)
需求错误的代价(1)
需求错误的代价(2)
31
需 重要性 求 分 析 概 述
--


分 需求获取

困难
的 重
,原因有三

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
分析小组成员主要包括领域专家、系统分析员;
客户访谈 问题分析与确认
20
与用户沟通的方法
1、访谈
2、面向数据流自顶向下求精
3、简易的应用规格说明技术 4、快速建立软件原型
21
3.2.1.访谈
正式的访谈:具体问题的问答形式; 非正式的访谈:开放式、交互性的问答。 书面调查:调查大量人员意见; 情景分析技术:对用户将来使用目标系统解决某个具 体问题的方法和结果进行分析。 1)能在某种程度上演示目标系统的行为,便于理解; 2)用户在需求分析过程中始终扮演积极主动的角色。
某出版社系统调查表
编号 提出问题
1
2 3 4 5 6 7 8 9
您在哪个部门工作?
出版业务流程是什么? 您每日都处理那些文件、数据、报表? 工作中手工处理特别麻烦的事情是什么? 工作中手工处理什么问题解决不了?影响效率的问题有哪些? 您认为提高工作效率,节省工作时间,减轻工作强度可采取哪些 办法? 您的部门需要成本核算和统计的内容有哪些? 您的部门采用计算机管理工作情况如何? 如何改进业务流程使之更合理?
消除数据冗余的程度。
3.1.3.导出系统的逻辑模型
导出详细的系统逻辑模型。
数据流图 数据字典 实体-联系图
姓名
性别
编号
教 师
1 教 N
状态转换图
主要的处理算法
课程名
课 程
学时
学分
3.1.4.修正系统的开发计划
修正在可行性分析阶段制定的初步的开发计划。
3.2 与用户沟通获取需求的方法
图:软件需求分析的通信途径
3.2.3.简易的应用规格说明技术
前两种方法中,用户比较被动。ቤተ መጻሕፍቲ ባይዱ
是一种面向团队的需求收集方法,是一种主流技术。 它提倡用户与开发者密切合作、共同标识问题、提出 解决方案,确定基本需求。
初步访谈
召开会议 小组讨论
汇总需求
简易的应用规格说明技术
进行初步的访谈,初步确定待解决的问题的范围和解
决方案。 开发者和用户分别写出“产品需求” 会议前准备 开会讨论 起草完整的软件需求规格说明书
1、功能需求 系统必须完成的所有功能 ( 输入、输出、加工 ); 1)强制的需求; 2)希望的需求; 3)可选的需求。
2、性能需求 系统必须满足的时间、空间约束,通常包括响应时 间、信息量速率、容量、安全性等;
3、可靠性需求 定量指出系统的故障率和使用程度,一个衡量可靠性 的参数是平均失效前时间 (MTTF, Mean Time To Failure),定义为随机变量、出错时间等的"期望值"。 4、出错处理需求 系统对环境错误如何处理,这类错误并不是由系统本 身造成的。仅限于关键部分,尽可能少;
5. 可理解性:需求描述不应该使用太多专业化词汇; 6. 可修改性:应该保证能够比较容易接纳修改; 7. 可追踪性:将分析后的需求与原始需求联系起来。
3.1 需求分析的任务
1. 通过对目标问题、用户要求和目标环境的研究、 分析和综合,建立抽象级的分析模型 (Analysis
Model);
2. 准确地、完整地体现用户需要的功能、性能及其 他要求,规范地通过“软件需求规格说明书” (SRS, Software Requirement Specification) 表达出来。
例1:有一个大学图书管理系统,该系统除了一般的 图书管理功能外,还能够为学生和教工从其他图书馆 借阅图书和文献资料提供服务。 因此系统应该具备以下功能: ⑴ 基本数据维护功能 ⑵ 基本业务功能 ⑶ 数据库管理功能 ⑷ 信息查询功能
1. 功能需求 ⑴基本数据维护功能: 提供使用者录入,修改并进行维护基本数据的 途径。基本数据包括读者的信息、图书资料的相关 信息,可以对这些信息进行修改,更新。 ⑵基本业务功能: 读者借、还书籍的登记管理功能,随时根据读 者借、还书籍的情况更新数据库系统,如果书籍已 经借出,可以进行预留操作,书籍的编目、入库、 更新等操作。
② 通过追踪这些细化的数据流图产生了新的问题,新的问题 的答案可能在数据字典中增加新的条目,并且将产生新的 算法; ③ 细化过程中注意及时的更新数据字典; 4、书写文档 ① 系统规格说明
② 数据要求
③ 用户系统描述 ④ 修正的开发计划
沿数据流图回朔 书写文档 用户复查 修正开发计划 细化数据流图
审 查 和复审
5、接口需求
系统与环境通信的格式:用户接口、硬件接口、软件 接口、通信接口等;
6、约束 在设计或实现系统时应遵守的条件:精度、工具和语 言约束、设计约束、标准、硬件平台; 7、逆向需求 系统不应该做什么,选取澄清真实需求且可消除误 解的逆向需求,且不需定量分析; 8、将来可能出现的要求 明确列出当前不属于系统开发范畴,将来很可能会提 出的要求。
3.2.4 快速原型法
快速原型:快速建立起来的旨在演示目标系统主要功 能的可运行的程序。 是最准确、有效和强大的需求分析技术。 快速:快速的提供给用户一个可运行的软件; 容易修改:根据用户的要求可迅速构建新的原型;
问 题:
成本问题; 方法和工具问题。
快速建立软件原型
为了快速地构建和修改原型,通常使用下述3种方法
④ 对系统可靠性的需求:要求系统失败发生率小 于1%。
3. 领域需求 例如:对“大学图书管理系统”,提出一些与 图书管理的业务相关的需求: ⑴ 图书编目要求按照《中国图书馆分类法》进行; ⑵ 由于版权限制,某些文献资料只能在图书馆规定 的阅览室阅读,并限制复制和打印。 第一条需求是对遵循我国图书管理的规定,执 行对图书的分类管理的标准。而第二条需求则是版权 法对图书馆文献资料的保护的需要,描述了对一类文 献资料有限制的使用和服务。
⑶数据库管理功能: 对所有图书信息及读者信息进行统一管理维护 的功能,对书籍的借还也要进行详细的登记,以便 协调整个图书馆的运作。 ⑷信息查询功能: 提供对各类信息的查询功能,如对本图书馆的 用户借书信息,还书的信息,书籍源信息,预留信 息等进行查询,对其他图书馆的书籍、资料源信息 的查询功能。
2.非功能需求
3.3.1 分析建模

结构化分析实质上是一种创建模型的活动。 需求分析过程应该建立3种模型,它们分别 是数据模型、功能模型和行为模型。
结构化分析方法( Structured Analysis ,SA )
面向数据流进行需求分析的方法 适合于数据处理类型软件的需求分析
36
结构化分析模型的组成结构
主要的文档。
软件需求说明书的编写提示 (GB856T—88)
软件需求说明书的编写提示
1 引言
1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述
2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示
3 需求规定
3.1 对功能的规定 3.2 对性能的规定
第三章
需求分析
3.1、需求分析的任务
3.2、与用户沟通获取需求的方法 3.3、分析建模与规格说明 3.4、实体-联系图 3.5、层次图和IPO图 3.6、验证软件需求
知识点
需求分析概述
需求分析的步骤
获取需求的方法
分析建模与工具
验证软件需求
需求分析概述
可行性研究从概念上定义软件的总体目标,粗略地 了解了用户的需求。需求分析进一步精化软件的作 用范围,明确系统必须完成的功能,对目标系统提 出完整、准确、清晰、具体的要求。 需求分析由软件分析人员与用户共同完成。 需求获取面临的挑战
① 系统安全性需求:为保证系统安全性,对本图 书馆的各项功能进行分级、分权限操作,对各类用户 进行确认。对其它图书馆借阅图书和文献资料服务控 制访问范围:如限IP、限用户等。
② 对系统可用性的需求:为了方便使用者,要求 对所有交互操作提供在线帮助功能。
③ 对系统查询速度的需求:要求系统在20S之内 响应查询服务请求。
和工具:
(1) 第四代技术
(2) 可重用的软件构件
(3) 形式化规格说明
3.3 分析建模与规格说明
什么是模型?
模型,就是为了理解事物而对事物做出的一种
抽象,是对事物的一种无歧义的书面描述。
模型通常由一组图形符号和组织这些符号的规
则组成。
模型的作用
在建模过程中了解系统; 通过抽象降低复杂性; 有助于回忆所有的细节; 有助于开发小组间的交流; 有助于与用户的交流; 为系统的维护提供文档 。
分析建模与规格说明
3.3.2. 软件需求规格说明(SRS)
Software Requirement Specification
通常用自然语言+模型,完整、准确、具体地描述 系统的数据要求、功能需求、性能需求、可靠性和 可用性要求、出错处理需求、接口需求、约束、逆 向需求以及将来可能提出的要求。
软件需求规格说明书,是需求分析阶段得出的最
10
11
哪些问题是目前传统手工方法根本无法解决的?
出版社计算机管理信息系统需要解决什么问题?
3.2.2.面向数据流自顶向下求精
结构化分析方法:面向数据流自顶向下逐步求精进行 需求分析的方法。
分析的对象:可行性分析中得到的数据流图。 主要目标:把数据流和数据存储定义到元素级别。
从数据流图的输出端数据流开始分析: 确定数据元素的来源,初步定义有关的算法; 确定数据元素的新的信息。 在复查的过程中进行数据流图的细化。
3.1 需求分析的任务
1. 确定系统的综合要求
2. 分析系统的数据要求
3. 建立系统的逻辑模型
4. 修正系统开发计划
5. 复审、验证需求分析
6. 编写软件需求规格说明书
3.1.1确定系统的综合要求
提问并思考:
相关文档
最新文档