当前位置：文档之家 › 第三章-需求分析

第三章-需求分析

  • 格式：ppt
  • 大小：3.38 MB
  • 文档页数：58

下载文档原格式

  / 58

合集下载

第3章-需求分析课件

第3章-需求分析课件

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

需求分析 PPT课件

需求分析 PPT课件
9
3.3 分析建模与规格说明 3.3.1 分析建模
模型：就是为了理解事物而对事物做出的一 种抽象，是对事物的一种无歧义的书面描述。 通常，模型由一组图形符号和组织这些符号 的规则组成。
结构化分析过程：实质上是一种创建模型的 活动。系统分析员从不同角度抽象出目标系 统的特性，使用精确的表示方法构造系统的 模型，验证模型是否满足用户对目标系统的 需求，并在设计过程中逐渐把和实现有关的 细节加进模型中，直至最终用程序实现模型。
带箭头的连线：称为状态转换，箭头指明了转 换方向。
19
状态图中使用的主要符号
20
活动表的语法格式： 事件名(参数表)/动作表达式
“事件名”可以是任何事件的名称。 常用的3种标准事件：
entry事件指定进入该状态的动作； exit事件指定退出该状态的动作； do事件则指定在该状态下的动作。
数据对象 数据对象的属性 数据对象彼此间相互连接的关系
14
实体-联系图的符号
ER图中包含： 实体(即数据对象)，用矩形框表示； 关系，用连接相关实体的菱形框表示； 属性，用椭圆形或圆角矩形表示，并用直线
把实体(或关系)与其属性连接起来。
15
例1：某校教学管理系统的ER图
16
状态转换图
需要时可以为事件指定参数表。活动表中的 动作表达式描述应做的具体动作。
21
事件表达式的语法： 事件说明［守卫条件］／动作表达式
事件说明的语法为：事件名(参数表)。 守卫条件是一个布尔表达式。如果同时使用
事件说明和守卫条件，则当且仅当事件发生 且布尔表达式为真时，状态转换才发生。如 果只有守卫条件没有事件说明，则只要守卫 条件为真状态转换就发生。 动作表达式是一个过程表达式，当状态转换 开始时执行该表达式。

需求分析的概念和任务

需求分析的概念和任务

h
6
需求分析的重点
通过对业务流程和数据流程的分析，在以下四 个方面与客户要达成完全一致目标。
① 业务模型、 ② 功能模型、 ③ 性能模型、 ④ 接口模型。
需求分析要明确：万一需求有点变化，双方必须 履行合同规定的“需求变更管理程序”。
h
7
需求的层次
需求可分解为4个层次：
①业务需求：反映组织机构或客户对软件高层次 的目标要求。这项需求是用户高层领导机构决 定的，它确定了系统的目标、规模和范围。
② 用户手册包括用户界面描述以及有关目标系统使用方 法的初步构想。
③ 在需求分析中确立测试标准，作为系统开发目标是否 完成的验收依据。
④ 修改的项目开发计划是根据新的分析结果，对可行性 分析和软件计划阶段中制订的初步的项目开发计划作 必要的修改、补充和完善。
h
19
软件需求规格说明的规则
➢ 描述要“做什么”而不是“怎样实现” ➢ 要求使用面向处理语言说明（或称系统定义语言） ➢ 如果被开发软件只是一个大系统中的一个元素，那么整
个大系统也包括在规格说明的描述之中 ➢ 规格说明必须包括系统运行环境 ➢ 规格说明必须是一个认识模型 ➢ 规格说明必须是可操作的 ➢ 规格说明必须容许不完备性并允许扩充 ➢ 规格说明必须局部化和松散耦合
h
20
《用户需求报告》要点指南
➢ 以业务流程为主线， ➢ 以需求分析的九大任务为中心， ➢ 以功能、性能、接口三个列表为基本点。
②用户需求：用户使用该软件要完成的任务。
③功能需求：定义了软件必须实现的功能。
④非功能需求：对功能需求的补充。
h
8
需求分析的目标
➢构造一个完整的、精致 的目标系统逻辑模型；

第3章需求分析详解

第3章需求分析详解
分析小组成员主要包括领域专家、系统分析员；
客户访谈 问题分析与确认
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.简易的应用规格说明技术
前两种方法中，用户比较被动。ቤተ መጻሕፍቲ ባይዱ

第3章 需求分析-软件工程案例教程(第2版)-李军国-清华大学出版社

第3章 需求分析-软件工程案例教程(第2版)-李军国-清华大学出版社
6
可行性研究的任务和目的
➢ 用最小的代价在尽可能短的时间内确 定问题是否能够解决。
➢ 确定问题是否能够解决和值得解决。 ➢ 分析可能的利弊关系。
➢ 对行动方针提出建议（是否可行）。
7
可行性研究的时间与成本
➢ 可行性研究实质上是在较高层次上以抽 象方式进行系统分析和设计的过程。
➢ 可行性研究需要的时间长短取决于工程 的规模。
仔细阅读和分析有关的材料，改正含糊或不正确的叙述， 清晰的描述目标系统。
➢ 识别用户的真正要求?（访问关键人员） ➢技术现状如何？ （系统调研） ➢系统配置如何？ （分析有关的材料） ➢系统维护能力如何？ （系统调研） ➢ 系统配置与外部环境的接口什么样？（限制和约束） ➢ 技术上的风险有哪些？ ➢ 是否具备技术资源？ ➢ 开发人员是否得到培训？ ➢ 是否存在法律责任和政治风险？
21
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解业务活动状况，特别是活动要点的分析。 ➢ 明确这些要点间什么在流动，如何流动。 ➢ 对物理流量进行分析。 ➢ 模型化，得到实际业务系统的物理模型。
22
系统分析的内容
1. 环境分析 2. 物理分析 3. 功能分析 4. 信息分析 5. 动态分析
➢ 了解系统应解决的问题是什么？ ➢ 这些问题是如何提出的？ ➢ 了解问题的结构。 ➢ 这些问题如何解决才能满足用户的要求？
17
案例： （库存管理）
找出问题
➢不能及时获得库存信息 ➢库存信息不够准确 ➢无法及时了解车间对库存商品的需求情况
18
系统分析过程
① 分析现实世界，充分理解当前系统，并用一个具体模 型描述，获得当前系统的物理模型。

第三章：需求分析PPT课件

第三章：需求分析PPT课件

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

第3章需求分析

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

第3章_需求分析

第3章_需求分析
结构化分析方法(SA)，是面向数据流进行需求 分析的方法。
结构化分析
• 结构化分析方法是抽象模型的概念，按照软件 内部数据传递、变换的关系，自顶向下逐层分 解，直到找到满足功能要求的所有可实现的软 件为止。
• 抽象和分解是这个方法的主要手段，由于数据 传递与变换而形成的数据流，是这个方法的主 要依据。
2.在对数据流图分层细化时，必须保持信息的连续 性。即：分解前、后的输入/输出数据流必须相同。
3.在功能级数据流图中，可根据需要给处理和数据 存储增加编号，便于引用和追踪。同时编号应反 映处理的分解层次；
4.一张数据流图中的包含的处理控制在5~9个，因此 数据流图应该使用分层和画分图的方法。
分层的数据流图
第三章 需求分析
• 需求分析的任务 • 需求分析的过程 • 需求分析的文档
需求分析
• 任务:确定待开发软件的功能，性能，数 据，接口等要求,从而确定系统的逻辑模 型.
• 参与人员 • 两个阶段:需求获取阶段和需求规约阶段 • 成果:软件需求说明书 • 方法:结构化分析(SA)
需求分析的任务
• 确定对系统的综合要求 • 分析系统的数据要求 • 导出系统的逻辑模型 • 修正系统开发计划
软件需求规格说明书
• A01 系统需求简要说明表 • A02 数据流图 • A03 数据流/存贮/组合元素描述表 • A04 数据元素描述表 • A05 数据概念结构图 • A06 基本处理说明 • A07 系统I/O描述表 • A08 数据元素代码表 • A09 系统流程图
软件需求分析方法
软件系统本质上是信息处理系统 任何信息处理系统的基本功能都是把输入数据 转变成需要的输出信息。 数据是需求分析的出发点。数据决定了需要的 处理和算法。 典型的面向过程的软件需求分析方法就是：

管理经济学-第三章需求分析

管理经济学-第三章需求分析

06
需求的收入弹性
定义
需求的收入弹性是指当消费者的收入发生变化时，需 求量变动的程度。具体来说，它衡量了需求量对收入 变动的敏感程度。
需求的收入弹性通常用需求量变动的百分比与收入变 动的百分比的比值来表示。
分类
01
正常品
需求的收入弹性大于零的商品， 即随着收入的增加，需求量也相 应增加。
劣等品
非线性需求函数
非线性需求函数是指需求量与价格之间呈非线性关系，通常表示为：Qd = f(P) 其中，f(P)是一个关于P的函数，可以 是二次函数、三次函数或其他形式的函数。
指数需求函数
指数需求函数是指需求量与价格之间呈指数关系，通常表示为：Qd = e^(-aP) 其中，a是常数，Qd和P 分别代表需求量和价格。
具体计算时，需要先确定商品B需求变化量 以及商品A价格变化量，然后带入公式进行
计算。
应用场景
交叉弹性在市场营销中具有重要应用价值。例如，当企业分析其产品与竞争对手产品之间的关系时，可以利用交叉弹性来评 估产品之间的替代或互补程度，从而制定有效的营销策略。
另外，交叉弹性也可以用于分析不同产品之间的关联程度，帮助企业了解市场需求和消费者行为，从而更好地制定产品定价 、促销和分销策略。
05
需求的交叉弹性
定义
交叉弹性是指一种商品的需求量对另一种商品价格变动的反 应程度。具体来说，它衡量了一种商品价格变化百分之一时 ，另一种商品需求量变化的百分比。
交叉弹性可以分为正交叉弹性和负交叉弹性，正交叉弹性表 示两种商品为替代品，负交叉弹性表示两种商品为互补品。
计算方法
交叉弹性 = (商品B需求变化量 / 商品B原始 需求量) / (商品A价格变化量 / 商品A原始价 格)

第3章-需求分析

第3章-需求分析
求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为，
这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行
分解，用层次的方式展示细节。
需求获取面临的挑战
客户说不清楚需求 需求易变性 问题的复杂性和对问题空间 理解的不完备性与不一致性
优秀需求具有的特性
❖ 1. 完整性 ❖ 2. 正确性 ❖ 3. 可行性 ❖ 4. 必要性 ❖ 5. 划分优先级 ❖ 6. 无二义性 ❖ 7. 可验证性
6 D1 库存清单
包含零件编号、 名称、目前价格 1
事务
1
5
2 定货报表
仓库管理员
处理
产生
采购员
事务
Байду номын сангаас
报表
形成定货数量 2
4
D2 定货信息
3
面向数据流方法的分析的应用
6
D1 库存清单
7
仓库
事务 1.1 接收
管理员
事务
事务 1.2 更新 库存
5
库存信息 1.3 处理 定货
D3 供应商信息 1
2 定货报表 产生 报表
现实世界
面
OOA
向 对
象
开 OOD 发
方
OOP 法
结构化
结 分析
构
化 结构化 开 设计
发
方 法
结构化 编程
计算机世界
结构化分析模型的组成结构
数
加
据 E-R图
数据流图 工
对 象
(DFD) 说
数据字典
明
（DD）
说
明
状态转换图
(STD图)
控制说明
面向对象分析模型的组成结构

《软件工程学》第3章 需求分析-答案

《软件工程学》第3章 需求分析-答案

3.1 需求分析的任务和步骤1．需求分析阶段产生的文档是软件需求规格说明书。

2．需求分析的任务是要建立软件的逻辑模型。

3．分析系统的数据要求是软件需求分析阶段的一个重要的任务。

4．需求分析的任务不包括（B）。

A．问题分析B．系统设计C．需求描述D．需求评审5．需求规格说明书是在计划时期可行性研究阶段产生的文档。

（×）6．需求分析阶段的成果主要是需求规格说明，但该成果与软件设计、编码、测试直至维护关系不大。

（×）7．软件需求是指用户对目标软件系统在功能、性能、行为、设计约束等方面的期望。

（√ ）8．需求分析中的性能要求是指系统的技术性能指标，包括：存储量、响应时间、精确度和安全保密等方面。

（√ ）3.2 需求分析获取的常用方法3.3 需求分析的方法3.4 结构化分析技术1．要将一个复杂的系统分析清楚，常用方法的结构化分析方法就是（ A ）A．面向数据流自顶向下逐步求精的方法B．由内向外进行分析的方法C．先局部后整体的分析方法D．使用IPO图形工具分析的方法2．结构化程序设计的一种基本方法是（ D ）。

A．筛选法B．递归法C．归纳法D．逐步求精法3．结构化程序设计主要强调的是（ A ）。

A．程序易读性B．程序的效率C．程序的规模D．程序设计语言的先进性4．下列各种叙述中，哪一个不是结构化方法的特征?（ C ）A．严格定义需求B．划分开发阶段C．提供运行模型D．制定规范文档5．通常所说的结构化设计（SD）是属于基于（ B ）的设计方法。

A．数据结构B．数据流C．对象D．以上均可6．通常所说的结构化设计方法就是基于数据流的设计方法。

7．结构化程序设计强调模块采用自上而下逐步求精设计方法，单入口、单出口。

（√ ）3.5 需求分析图形工具。

  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

缺乏合格的项目经理
6
Shortage of software engineers
缺乏软件工程师
7
Fixed - price contract 固定价合同
Inadequate communications for system integration 8
系统集成阶段 , 交流与沟通不充分
9
Insufficient experience as team 团队缺乏经验
.
12
需求分析定义
需求分析是为最终用户所看到的系统 建立一个概念模型，是对需求的抽象 描述。
.
13
需求分析模型
.
14
需求规格
需求分析工作完成的一个基本标志是形成 了一份完整的、规范的需求规格说明书
需求规格说明书的编制是为了使用户和软 件开发者双方对该软件的初始规定有一个 共同的理解，使之成为整个开发工作的基 础。
需求验证
需求是正确的吗？ 需求是一致的吗？ 需求是完全的吗？ 需求是实际可行的吗？ 需求是必要的吗？ 需求是可检验的吗？ 需求是可跟踪的吗？ 最后的签字
.
18
需求总在变化
.
19
.
20
需求变更管理
1. 确定需求变更控制过程 2. 建立变更控制委员会(SCCB) 3. 进行需求变更影响分析 4. 跟踪所有受需求变更影响的工作产品 5. 建立需求基准版本和需求控制版本文档 6. 维护需求变更的历史记录 7. 跟踪每项需求的状态 8. 衡量需求稳定性
同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施
验证人
杨炎泰
韩万江，姜岳尊，孙泉
验证日期
2002．10．11
填表人
XXXX
.
24
本章要点
一、需求概述 二、需求工程 三、需求分析模型 四、需求建模方法 五、案例分析
.
25
分析模型在系统描述和设计模型之间建 立桥梁
申请日期
2012。10．11
项目管理系统
系统设计
RCR-PM-01.doc, RCR-PM-02.doc, 变更简述如下
1）修改测试流程控制：将2个角色，3个渠道流，改为3个角色，4个渠道流，详见RCR-PM-01.doc 2）增加开发人员技能信息库管理，详见RCR-PM-02.doc
验证意见 SCCB
不充分的需求规范
2
Changes in requirements 需求的改变
3
Shortage of systems engineers 缺乏系统工程师
4
Shortage of software managers
缺乏了解软件特性的经理人
5
Shortage of qualified project managers
软件工程
第三章 需求分析
.
0
本章要点
一、需求概述 二、需求工程 三、需求分析模型 四、需求建模方法 五、案例分析
.
1
软件需求
需求是指用户对软件的功能和性能的 要求，就是用户希望软件能做什么事 情，完成什么样的功能，达到什么性 能。
.
2
软件需求的层次
业务需 求
用户需 求
非功能性需 求
系统需 求
.
21需求变更控制系统Fra bibliotek一个正式的文档，说明如何控制需求变更 建立变更审批系统
.
22
变更申请 选择变更方式
忽略
SCCB评估 根据评估结果
项目经理自行决定
拒绝
接受本次修改
下个版本再修改
修改合同相关信息
修改相关需求
修改相应的. 项目计划
23
申请人
项目名称
阶段名称 文件名称
修改内容
XXXX
软件基表线4-3产需求品变更修提改交单提交单
数据模型
10 Shortage of application domain experts
缺乏应用领域专家
Scale: 5 = Very Serious 3 = Serious 1 = No Serious
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8
3.8
3.6 3.6
Source: Carnegie-Mellon University, Software Engineering Institute
.
6
本章要点
一、需求概述 二、需求工程 三、需求分析模型 四、需求建模方法 五、案例分析
.
7
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
需求变更
需求变更
.
8
需求工程基本任务
需求工程
需求开发
需求管理
需求获取
需求分析
变更管理
需求验证
需求规格说明
.
9
需求获取图示
系统描述 分析模型 设计模型
.
26
需求分析模型
关联模型 行为模型 数据模型 原型模型 其他
.
27
关联模型
定义系统与环境的关联关系
.
28
关联模型
Branch Accounting system
Security system
Auto-teller system
Branch counter system
功能需 求
质量特 性
约束和假 设
软件需求规格
.
3
需求问题举例
需求的隐含错误 需求不明确、含糊 用户不断增加需求、变更需求 用户刁难 开发人员的镀金
.
4
需求管理的重要性
.
5
项目失败的原因分析
No.
Top 10 Factors
1
Inadequate requirements specification
Account database
Usage database
Maintenance system
图２－6：ＡＴＭ系统的关联模型
.
29
行为模型
行为模型是描述系统的总体行为
数据流模型 状态机模型
.
30
数据流模型
旅行社
单订
航
票
班
预定机票
航班目录
费用 记账
准备机 票
机票
旅客
记账文件
.
31
状态机模型
.
32
.
15
软件需求规格说明的原则
从现实中分离功能，即描述要“做什 么”而不是“怎样实现”
采用一定的规格说明语言 如果被开发软件只是一个大系统中的
一个元素，那么整个大系统也包括在 规格说明的描述之中
.
16
规格说明应该包括系统运行环境 规格说明应该是一个认识模型 规格说明应该容许不完备性并允许扩
充
.
17
.
10
需求获取
用户要求
软件需 求
基线需求 扩展需求
.
11
需求获取注意事项
缺乏用户参与，开发人员技术驱动 沟通失真 识别真正的用户 正确理解客户需求，了解行业背景 变更频繁 具备较强忍耐力和清晰的思维 使用符合客户语言习惯的表达 提供需求开发评估报告 尊重开发人员和客户的意见，妥善缓解矛盾 划分需求的优先级