《实战需求分析》教学课件(第3章)

合集下载

第三章需求分析1PPT课件

第三章需求分析1PPT课件
第 44页页
注意 ① 需求分析阶段,系统分析员的主要关注点是“做什
么( what ) ” ,不是“怎样做( how)”; ② 需求分析阶段,系统分析员应该给出软件需求规格
书。
第 55页页
§3.1需求分析的任务
▪ 四项主要任务: 1 、确定对系统的综合要求 2 、分析系统的数据要求 3 、导出系统的逻辑模型 4 、修正系统开发计划
▪ 数据流图(Data Flow Diagram,DFD) :用来创建功能模 型,描述了信息流和数据转换。
▪ 教学目的:了解需求分析的任务和步骤、评审标准 和过程;掌握基本技术,理解需求规格说明书的作 用与组成。
▪ 教学重点:基本技术、需求规格说明书的作用与组 成。
▪ 教学难点:基本技术。
第 33页页
需求分折简介
▪ 软件需求指用户对所开发的软件在功能、性能、 环境、可靠性等各方面的要求。
▪ 需求分析主要回答待开发的系统必须“做什么” ,并用 《 需求规格说明书 》 的形式准确、详细、 规范地表达出来。
第 2222页页
例:结构化分析方法建立的需求模型
▪ 结构化分析( Structured Analysis , SA )是面向数据流 进行分析的方法,主要建立以下几种模型:
▪ 实体关系图(Entity-Relationship Diagram,E-R图)来创建数 据模型,描述系统中所有重要的数据对象;
密切合作,共同标识问题,提出解决方案要素,商 讨不同方案并指定基本需求。 ▪ 具体过程见教材 P60 面 ▪ 提问:此方法将产生什么样的产品?
第 1188页页
§3.2.4快速建立软件原型
▪ 快速原形就是快速建立起来的旨在演示目标系统主要 功能的可运行的程序。

第3章-需求分析课件

第3章-需求分析课件

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

CH3 需求分析 经典软件工程PPT 教学课件

CH3 需求分析 经典软件工程PPT 教学课件
42
工 资 清 单 F3
人事部门 出勤表
业绩表
1
计算工资
2 打印工资工资条
清单
后勤部门 水电扣款表 实发工资表 3
工资存 款清单
工资转存
银行
职工
图4.6 工资计算系统第一层数据流图
43
人事部门出勤表 业绩表
奖金发放表
1 .1
1 .2
计算奖金和
计算应
缺勤扣款
发工资
应发工资表
1 .3 计算 所得税
缺勤扣款表
一个DFD主要由以下四个部分组成:
数据流
数据流名称
加工(转换)
转换 名称
外部实体 外部实体名称
数据存储 数据存储名称 25
§3 数据流图
§3.2 画数据流图的原则
先找系统数据的输入输出点,画出外部实体 确定外部实体的输入输出数据流
由源点外部实体的数据流出发,逐渐进行加 工,完成整个数据流图
……
记帐数据
库 31
§4 数据字典
数据字典例子: (处理逻辑)
数订据票员加工订名票称单:定票预
航班

- 别名: 无


- 输入: 订票单 机 - 输出航: 班航号班、费票用 费用


机票
- 激发条件:接受到订票单
-处理航逻班辑目:录
记帐
帐单
if 单据=订帐票目单 then if 单据是否过期
订票员
……
then 是否有该航班,是否有机票
记帐数据 库
32
§5 基于数据流的分析方法
§3.4 基于数据流的分析方法
DFD是系统中各处理子功能以及它们之间 数据流动的图形表示 -- 刻划系统功能和行为

《需求分析》PPT课件 (2)

《需求分析》PPT课件 (2)

2021/4/26
14
3.1.4 修正系统开发计划
根据在分析过程中获得的对系统的更深入更具体的 了解,可以比较准确地估计系统的成本和进度,修 正以前制定的开发计划。
2021/4/26
15
3.2 与用户沟通获取需求的方法
• 访谈 • 面向数据流自顶向下求精 • 简易的应用规格说明技术 • 快速建立软件原型
2021/4/26
33
2021/4/26
34
为了消除用自然语言书写的软件需求规格说明书中
可能存在的不一致、歧义、含糊、不完整及抽象层
为了解决上述问题,人们研究出一种面向团队的需
求收集法,称为简易的应用规格说明技术。这种方
法提倡用户与开发者密切合作,共同标识问题,提 出解决方案要素,商讨不同方案并指定基本需求。 今天,简易的应用规格说明技术已经成为信息系统 领域使用的主流技术。
2021/4/26
22
典型过程如下:
1. 进行初步的访谈,开发者和用户分别写出“产 品需求”。
2021/4/26
19
3.2.2 面向数据流自顶向下求精
软件系统本质上是信息处理系统,而任何信息处理 系统的基本功能都是把输入数据转变成需要的输出 信息。数据决定了需要的处理和算法,看来数据显 然是需求分析的出发点。在可行性研究阶段许多实 际的数据元素被忽略了,当时分析员还不需要考虑 这些细节,现在是定义这些数据元素的时候了。
2021/4/26
28
(3) 形式化规格说明和原型环境
在过去的20多年中,人们已经研究出许多形式化规 格说明语言和工具(参见第4章),用于替代自然语言 规格说明技术。今天,形式化语言的倡导者正在开 发交互式环境,以便可以调用自动工具把基于形式 语言的规格说明翻译成可执行的程序代码,用户能 够使用可执行的原型代码去进一步精化形式化的规 格说明。

《需求分析》幻灯片PPT

《需求分析》幻灯片PPT
❖ 从数据流图的输出端着手分析,这是因为系 统的根本功能是产生这些输出的关键原因。
❖ 输出数据决定了系统必须具有的最根本的组 成元素〔包括功能和数据构造组成〕。
3.2.2 面向数据流的自顶向下求精
❖ 注意1:第2章给出了1种数据流图的分析方法 〔教材〕,其目的主要是导出较高层次较粗 糙的数据流图,而需要准确地收集需求,采 用本章的从数据流图的输出向输入的回溯方 法。
面向数据流方法的分析过程
❖ 沿数据流图回溯 ❖ 用户复查 ❖ 细化数据流图 ❖ 修正开发方案 ❖ 书写文档 ❖ 审查和复审
沿数据流图回溯
❖ 从数据流图的输出向输入回溯,依次确定每 个数据元素的来源〔组成和实现算法〕;
❖ 把数据元素的信息记录到数据字典中; ❖ 把对算法的简明描述记录到IPO图中; ❖ 补充的数据流、数据存储和处理应该添加到
❖ 简易的应用规格说明技术 ❖ 快2.1 访谈
❖ 最早并且仍然广泛使用 ❖ 正式的访谈:具体问题的问答形式 ❖ 非正式的访谈:开放式、交互性的问答 ❖ 需要调查大量人员时采用“调查表〞技术 ❖ 还使用“情景分析技术〞〔用户角度〕,就是
对用户将来使用目标系统解决某个具体问题 的方法和结果进展分析。

(DD)


状态转换图
(STD图)
控制说明
面向对象分析模型的组成构造
操作、
类/对象
对象-关
模型
使用实例
(Use Case)
系模型
对象-行为模型
3.3 分析建模与规格说明
❖ 构造化分析方法的创立的几个主要模型及关 键元素如下:
❖ 数据模型:E-R图〔E-RD〕〔本章介绍〕 ❖ 功能模型:数据流图〔DFD〕 ❖ 行为模型:状态转换图〔STD〕〔本章介绍〕 ❖ 数据字典:模型中心〔DD〕 ❖ 根据上述模型整理出软件需求规格说明书

第3章_需求分析

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

软件工程课件之第3章 需求分析(第五版)(张海潘编著)PPT文档74页

软件工程课件之第3章 需求分析(第五版)(张海潘编著)PPT文档74页
55、 为 中 华 之 崛起而 读书。 ——周 恩来
谢谢!
51、 天 下 之 事 常成 于困约 于是呼 吸,生 命是活 动。——卢 梭
53、 伟 大 的 事 业,需 要决心 ,能力 ,组织 和责任 感。 ——易 卜 生 54、 唯 书 籍 不 朽。——乔 特
软件工程课件之第3章 需求分析(第五 版)(张海潘编著)
11、获得的成功越大,就越令人高兴 。野心 是使人 勤奋的 原因, 节制使 人枯萎 。 12、不问收获,只问耕耘。如同种树 ,先有 根茎, 再有枝 叶,尔 后花实 ,好好 劳动, 不要想 太多, 那样只 会使人 胆孝懒 惰,因 为不实 践,甚 至不接 触社会 ,难道 你是野 人。(名 言网) 13、不怕,不悔(虽然只有四个字,但 常看常 新。 14、我在心里默默地为每一个人祝福 。我爱 自己, 我用清 洁与节 制来珍 惜我的 身体, 我用智 慧和知 识充实 我的头 脑。 15、这世上的一切都借希望而完成。 农夫不 会播下 一粒玉 米,如 果他不 曾希望 它长成 种籽; 单身汉 不会娶 妻,如 果他不 曾希望 有小孩 ;商人 或手艺 人不会 工作, 如果他 不曾希 望因此 而有收 益。-- 马钉路 德。

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) 用户或人的因素
准确地定义未来系统的目标,确定为了 满足用户的需求“系统必须做什么”。用 《需求规格说明书》规范的形式准确地表 达用户的需求。

第三章:需求分析PPT课件

第三章:需求分析PPT课件

-
3.2 获取需求的方法
1、访谈
访谈有两种基本形式,分别是正式的和非正式的访谈。
当需要调查大量人员的意见时,向被调查人分发调查表 是一个十分有效的做法。
在访问用户的过程中使用情景分析技术往往非常有效。
情景分析技术的用处主要体现在下述两个方面:
(1) 它能在某种程度上演示目标系统的行为,从而便于用户 理解,而且还可能进一步揭示出一些分析员目前还不知道 的需求。
一般使用第三范式。
17
-
3.6 状态转换图
在需求分析过程中应该建立起软件系统的行为模型。状态转换图(简 称为状态图)通过描绘系统的状态及引起系统状态转换的事件,来表示系统 的行为。此外,状态图还指明了作为特定事件的结果系统将做哪些动作(例 如,处理数据)。
1、状态
状态是任何可以被观察到的系统行为模式,一个状态代表系统的一种 行为模式。状态规定了系统对事件的响应方式。系统对事件的响应,既可 以是做一个(或一系列)动作,也可以是仅仅改变系统本身的状态,还可以是 既改变状态又做动作。
7.其它需求
-
3.4概念模型
最常用的表示概念性数据模型的方法:实体—联 系方法(Entity-Relationship Approach),简称ER模型。
E-R模型包含三个基本成分:“实体”、“联 系”、“属性”
(1)实体:是客观世界中存在的且可相互区分的事物。 它可以是人或物,也可以是具体事物或抽象事物。 – 例如:教师、学生、课程是实体。 实体用矩形框表示,如: 教师
在状态图中定义的状态主要有:初态(即初始状态)、终态(即最终状态) 和中间状态。在一张状态图中只能有一个初态,而终态则可以有0至多个。
状态图既可以表示系统循环运行过程,也可以表示系统单程生命期。

软件工程之第3章-需求分析(第五版)(张海潘编著)精品PPT课件

软件工程之第3章-需求分析(第五版)(张海潘编著)精品PPT课件
根据在分析过程中获得的对系统的更深入更具 体的了解,可以比较准确地估计系统的成本和 进度,修正以前制定的开发计划。
3.2 与用户沟通获取需求的方法
访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型
需求的获取
需求获取是开发人员与客户或用户一起对应用领 域进行调查研究,收集系统需求的过程
层次的方法展示细节。
3.1 需求分析的任务
确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性需求、出错处理需求、 接口需求、约束、 逆向需求、将来可能提出的要求。
分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划
3.1.1 确定对系统的综合要求
1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求
确定系统必须完成哪些工作,也就是对目标系 统提出完整、准确、清晰、具体的要求。
系统分析员应该写出软件需求规格说明书,以 书面形式准确地描述软件需求。
需求:正在构建的系统必须符合的事务。
需求管理:是一种获取、组织并记录系统需求 的系统化方案以及一个使客户与项目团队不断 变更的系统需求达成并保持一致的过程。
第四代技术特点:
简单易学,用户界面良好,面向问题、非过程化程度 高,用户只需告知系统做什么,而无需说明怎么做。 用4GL编程使用的代码量较少,并可成数量级地提高 软件生产率。
程序设计语言划代:
1GL是汇编语言;
2GL是高级程序设计语言,如FORTRAN,ALGOL, BASIC,LISP等;
术性的转换
功能范围更广,
现代
全过程的,注 重整个产品过 程的全部

《实战需求分析》教学课件

《实战需求分析》教学课件
准确性和完整性。
与用户对需求进行确认, 确保需求符合用户的期
望和要求。
02
需求收集的方法与技巧
访谈与问卷调查
访谈
通过面对面的交流,深入了解用户的 需求和期望。可以设计开放式和封闭 式问题,引导用户表达自己的需求。
问卷调查
设计结构化的问卷,广泛收集用户的 需求信息。要注意问题的明确性、中 立性和可量化性。
制定变更计划
制定变更计划,包括变更实施 时间、责任人、风险应对措施 等。
跟踪与反馈
对变更实施过程进行跟踪,及 时反馈变更结果,以便进行调 整。
需求变更的控制与跟踪
控制
建立需求变更控制流程,确保变更在 可控范围内进行。
跟踪对需求变更Βιβλιοθήκη 行全程跟踪,确保变更 得到有效执行。
版本控制
对需求文档进行版本控制,记录每次 变更的内容和时间。
需求分析的重要性
01
确保软件开发的正确性和有效性
通过需求分析,可以明确用户的需求和期望,从而确保软件开发的正确
性和有效性,避免开发过程中的偏差和浪费。
02
提高软件产品的质量和用户体验
通过需求分析,可以深入了解用户的需求和行为习惯,从而设计出更符
合用户需求的软件产品,提高软件产品的质量和用户体验。
03
识别利益相关者
识别与产品相关的所有利益相关者,包括直接用户、间接用 户、企业领导等。
分析利益相关者的需求
分析不同利益相关者的需求和期望,综合考虑各方需求,确 保产品的平衡和满足度。
03
需求规格说明书的编写
需求规格说明书的内容
01
02
03
04
功能需求
详细描述系统需要实现的功能 ,包括主要功能和次要功能。

《实战需求分析》教学课件(第3章)

《实战需求分析》教学课件(第3章)
【案例:使用软件系统的触发事件】
规划工作方式
规划使用软件系统的时间
✓不同功能有不同的时间要求 ✓规划使用时间主要用于对软件的 运算压力提前做好预案
规划使用软件系统工作的场景
原来是怎么处理的,现在该怎么处 理,经历哪些步骤,在处理过程中, 人需要做什么,系统需要做什么, 人跟系统怎么进行信息交互等
【案例:使用软件系统工作的场景】
思考题
思考
请思考: 1. 学校需要开发一款管理学生档案信息的软件。对于学生基本信息的编辑权限,客户提
出了这个需求:学生的基本信息由班主任录入,如果班主任请假,领导又催得急的话, 学工处王老师处理。 ——用正确的方式重新描述本需求。 2. 假设需要开发一款软件用于学校宿舍的床位分配,根据你的想法提出关于床位分配的 需求。注意需求描述要尽量明确、精准、没有二义性,且一般非IT人员能够看得懂。 3. 根据学校图书馆借书、还书的管理要求,画出业务流程图。 4. 假设你到学校图书馆借书,图书管理员通过软件处理借书事宜。描述一下处理借书的 工作场景。 5. 观察在学习、生活中使用到的一些软件,请举一个信息孤岛的例子,并说明(或猜想) 其形成的原因,有什么解决方法。
案例:需求调研中的理解偏差
将自然语言描述的需 求结构化
将用户用自然语言描述的 不严谨的需求转换成明确、 精准、没有二义性的需求
案例:将自然语言描 述的需求结构化
3.1 需求确定
认清需求 控制需求 挖掘需求
控制 需求
识别超出项目范围的需求
需求是有边界的,应该在项目范围之内。为了让用户理 解需求边界,首先要确定项目目标。用户的需求如果偏 离了这个目标,要指出来,越早指出越好。
统一编码
✓在不同的系统中将相同的业 务信息统一编码 ✓因为关键数据编码一致,可 以采用简单的方法整合
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

B
逻辑信息孤岛
从物理层面来看,连接没有任何障碍,孤岛的 形成纯粹是由数据的产生过程、加工过程、存 储格式、数据结构引起的。 ——这种情况占了绝大部分
3.4.4 避免信息孤岛
什么是信息孤岛
形成原因
处理方式
业务上相同或相似的数据, 在不同的软件系统中采用了 完全不同的数据结构
完全相同的数据,在这个软件系统 中采用这种编码方式,在另外一个 软件系统中又采用另外一种编码方 式
3.1 需求确定
认清需求
控制需求
挖掘需求
满足用户正确的需求
需要满足用户的需求 但只包括正确的需求
需要挖掘的需求
用户需求并不是建立信 息化管理体系的目标
需求 组成
让用户提出需求是建立 这个体系的一种手段, 不是目标 必要的需求是要挖掘的, 无论用户是否提出,都 需要实现
用户提出的需求
厘清用户需求 对用户的需求进行系统分析 规划未来如何通过信息系统进行企业管理 确定需要哪些软件功能 需要处理哪些数据
பைடு நூலகம்
以下这些工作是在系统规划阶段决定的——
以后用户如何通过这个软件工作 对现在的业务流程需要做什么变更重组 这个项目的范围 哪些需求可以实现哪些需求不可以实现 整个系统需要处理的信息 整个系统需要提供的功能
规划软 件边界
【案例:规划软件边界】 【案例:存在多系统的软件边界】
规划工作方式
规划各岗位人员使用软件后的具体工作过程,需要规划相关岗位的 职员在使用你的软件之后应该如何工作,围绕软件系统的具体工作 步骤是什么。
3.3.2 系统蓝图设计-规划工作方式
规划使用软件的地点
规划工作人员在什么地方使 用软件 不同岗位有不同使用的方式
系统规划
系统规划的工作内容
需求确定
整理需求 系统蓝图设计
几个注意事项
3.1 需求确定
认清需求
控制需求
挖掘需求
将抽象的需求具体化
思考通过什么方法能够实 现用户抽象的需求目标
具体化
结构化
案例:抽象的需求
将自然语言描述的需 求结构化
注意避免理解偏差
如何避免理解偏差—— 提高沟通能力、沟通频次, 学习对方工作领域的知识
避免 误差
将用户用自然语言描述的 不严谨的需求转换成明确、 精准、没有二义性的需求
案例:将自然语言描 述的需求结构化
案例:需求调研中的理解偏差
3.1 需求确定
认清需求
控制需求
挖掘需求
识别超出项目范围的需求
需求是有边界的,应该在项目范围之内。为了让用户理
解需求边界,首先要确定项目目标。用户的需求如果偏 离了这个目标,要指出来,越早指出越好。
4. 假设你到学校图书馆借书,图书管理员通过软件处理借书事宜。描述一下处理借书的
工作场景。 5. 观察在学习、生活中使用到的一些软件,请举一个信息孤岛的例子,并说明(或猜想) 其形成的原因,有什么解决方法。
谢 谢!
授课老师:xxxxxxxxx
编码差异
人为因素 缺少关联字段
数据结构差异
供应商不愿意别人访问自己系 统的数据 数据有特殊性,别人无法解读
业务上有关联的数据,在 两个软件系统中就是找不 到关联方式
3.4.4 避免信息孤岛
什么是信息孤岛
形成原因
处理方式
数据接口
系统之间通过接口进行数据沟通 麻烦之处:范围小、实时困难、 同步困难 【案例:通过数据接口保持数据同步】
案例:挖掘需求
系统规划
系统规划的工作内容
需求确定
整理需求 系统蓝图设计
几个注意事项
3.2 整理需求
引言 编写目的 调研背景 专业术语
需求调研报告
业务流程图
1 1.1 1.2 1.3 …… 2 2.1 2.2 2.3 2.4 …… 3 3.1 3.2 3.3 ……
//为什么要编写本文档 //简述调研过程,参与人等 //解释本文档中用到的专业术语
其它 注意事项 待定问题
//整理本系统需要处理的所有数据
【案例:某采购管理系统的数据】
//可能跟本项目有关系的其它软件系统
//注意点 //没有定论,还需要继续讨论的问题
【案例:某考勤分析系统的“待定问题”】
整理需求
需求调研报告
业务流程图
︻ 案 例 ︓ 业 务 流 程 图 ︼
3.3 整理需求
需求调研报告
3.2 整理需求 4 需求 4.1 财务部 4.2 …… 5 5.1 5.2 …… 6 6.1 6.2 …… 7 7.1 7.2 计划部
需求调研报告
业务流程图
【案例:某车间调度的需求】
//整理所有需求,这是本文档的核心内容 //可以以业务领域为维度,也可以以软件 功能为维度
数据 销售合同 采购单 相关系统 系统A 系统B
如何规划工作方式( ★ ★ ★ ★ ★ )
让用户重复劳动产生的原因( ★ ) 信息孤岛形成的原因,常用处理方式( ★ ★ ★ ★ )
思考题
思考
请思考: 1. 学校需要开发一款管理学生档案信息的软件。对于学生基本信息的编辑权限,客户提 出了这个需求:学生的基本信息由班主任录入,如果班主任请假,领导又催得急的话, 学工处王老师处理。 ——用正确的方式重新描述本需求。 2. 假设需要开发一款软件用于学校宿舍的床位分配,根据你的想法提出关于床位分配的 需求。注意需求描述要尽量明确、精准、没有二义性,且一般非IT人员能够看得懂。 3. 根据学校图书馆借书、还书的管理要求,画出业务流程图。
■避免重复劳动
重复劳动会严重影响工作士气 要避免给用户带来重复劳动
【案例:直接重复录入数据】 重复劳动最大的可能性来自数据的重复录入 【案例:间接重复录入数据】
■处理好软件关系
一个信息化管理体系可能会包括很多软件 要警惕业务范围有交叉的软件 如果处理不好会:带来重复劳动;形成信息孤岛 【案例:在多个系统中重复录入数据】
概述 项目目标 //希望对企业管理改善达成的目标 期待解决的问题 //希望通过本项目解决的管理问题 项目范围 //本项目的工作边界 双方约定 //澄清双方理解上可能产生冲突的地方 相关资料 组织结构 用户名单 重要业务规则 //经过整理的对以后阶段有用的资料
【案例:某销售管理系统的项目目标】 【案例:某库存管理系统“待解决的问题”】 【案例:某销售管理系统的项目范围】 【案例:某销售管理系统的双方约定】
案例:限制超出项 目范围的需求
控制 需求
识别错误的需求
用户的需求并不总是正确的,有些需求得不偿失或根本 无法实现。满足用户的需求是义不容辞的责任,但不包 括错误的需求。
案例:识别错误的 需求
识别技术上不能实现的需求
要对自己的团队的技术能力有非常清楚的了解。对于技
术上不能实现的需求要尽早跟跟用户说清楚。
■避免信息孤岛
信息割据:每一款软件都有自己的规则,犹如“信息诸侯”
3.4.4 避免信息孤岛
什么是信息孤岛
形成原因
处理方式
A
信息 孤岛
物理信息孤岛
数据被存放在不同的物理地点,相互之间被完
全隔开,很难找到直接的通信方式。
——由于现在网络发达,这种情况比较少见
信息被分割成许多独立 块,块与块之间缺少有 效的联系手段,犹如海 洋中孤零零的岛屿。
的什么功能
人跟系统怎么进行信息交互等
【案例:使用软件系统的触发事件】
规划工作方式
【案例:使用软件系统工作的场景】
系统规划
系统规划的工作内容
需求确定
整理需求 系统蓝图设计
几个注意事项
3.4 几个注意事项
■警惕利益受损者
01 注意 事项 04 02 03
推行信息化管理需要进行流程重组 流程重组会遭到大部分人的反对 对来自利益受损者的阻力要有心理准备
本章重点
本章重点
本章重点: 如何将用户的需求具体化、结构化( ★ ★ ★ ★ ★ ) 如何识别超出项目范围的需求( ★ ★ ★ ) 如何识别错误的需求 ( ★ ★ ) 需求调研报告的编写方式( ★ ★ ★ ★ ) 如何绘制业务流程图( ★ ★ ) 如何规划软件边界( ★ ★ ★ )
杨长春编著 清华大学出版社出版
课时:xx
授课老师:xxxxxxx
实战需求分析
第3章:系统规划
本书主页
系统规划
目录
CONTENTS
本章重点 思考题
系统规划
系统规划的工作内容
需求确定
整理需求 系统蓝图设计
几个注意事项
系统规划的工作内容
系统规划是根据用户需求规划企业信息化管理体系的过程,主要工作包括:
规划使用软件系统的时间
不同功能有不同的时间要求 规划使用时间主要用于对软件的 运算压力提前做好预案
规划软件系统的触发事件
规划什么事情发生时需要软 件来处理
规划使用软件系统工作的场景
原来是怎么处理的,现在该怎么处 理,经历哪些步骤,在处理过程中, 人需要做什么,系统需要做什么,
处理不同的事情,需要软件
统一编码
在不同的系统中将相同的业 务信息统一编码 因为关键数据编码一致,可 以采用简单的方法整合
整合平台
建立一种用于信息整合的平台, 这其实也是一种软件 麻烦之处:从其他软件系统中获 取数据是一件困难的事
综合解决方案
综合解决方案从根本上解决 信息孤岛问题 实现综合解决方案是一个相 当艰巨的任务
业务流程图
系统规划
系统规划的工作内容
需求确定
整理需求 系统蓝图设计
几个注意事项
3.3 系统蓝图设计
进行价值分析
分析这个系统将来会给客户、用户带来什么;分析会对以后的管理 带来什么,会对管理工作有什么影响,管理方式会因之而做出什么 变更。
相关文档
最新文档