ch2 需求分析

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

3
需求分析概述 什么是用户需求
待开发软件系统的功能、性能、设计约束和其它 要求
开发软件系统前,须了解用户的期望和要求
软件需求 需求分析过程
需求分析的重要性
软件开发的基础和前提 最终目标软件系统验收的标准 避免或者尽早剔除早期的错误
4
需求分析概述
需求分析的复杂性和面临的困难
“容易修改”。如果原型的第一版不是用户所需 要的,就必须根据用户的意见迅速地修改它,构 建出原型的第二版,以更好地满足用户需求。如 果修改耗时过多,势必延误软件开发时间。
31
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
美国海军研究实验室从20世纪70年代起就对 软件开发技术不断地进行研究。他们对海军A -7E飞机上的并行操作程序进行实地测试, 以验证许多新设想的可行性。得出的研究数 据表明:A—7E项目中77%的需求错误特点是 不明确、疏忽、不一致和二义性。按错误类 型对这些错误分布进行分析的结果是: 49%不正确的事实,31%疏忽,l3%不一致 ,5%二义性。
18
需求分析的过程
获取和理解用户需求 描述和分析用户需求 对用户需求进行评审
19
需求分析过程示意图
获取和理解需求
需求获取 技术
描述和分析需求 评审用户需求
需求评 审原则
20
建模、抽象、 多视点、问题 分解、原型
步骤1:获取和理解用户需求阶段
任务
获取并理解用户需求, 清除用户需求的不一致 性, 模糊性和歧义性,帮助用户发现潜在的需 求
8
需求分析的重要性
The reason: There was no discussion in the requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4. Statistical material: In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. 31% of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).

原则
确保SRS的完整性、一致性和准确性 鼓励用户参与SRS以及用户手册的制定 尽可能做到SRS结构清晰,措辞准确和简洁
22
步骤3:对用户需求进行评审
任务
多方人员一起对SRS进行复核和评审,以确保 用户手册和SRS全面、准确、一致地反映用户 需求
原则
支持各方(用户,需求分析人员、设计人员) 共同参与评审工作
片面, 不完全 模糊, 不准确 不一致, 歧义 需求复杂和庞大
因此必须使用系统的方法、借助于一系列 行之有效的技术和工具进行软件需求分析
5
需求分析概述
需求分析是软件生存期的一个重要阶段,是软 件开发项目得以成功的基础。 其最根本的任务是确定为了满足用户的需要, “系统必须做什么?”的问题。 需求分析是一个不断发现和决定的过程,在此 过程中,软件开发者和用户起着同样重要的作 用。 系统分析员应该写出软件需求规格说明书,以 书面形式准确地描述软件需求。
25
需求获取技术
问题域
交流 用户 需求分析员
26
需求获取 访谈 快速建立软件原型
27
访谈
1. 正式访谈
系统分析员将提出一些事先准备好的具体问题。 2. 非正式访谈
分析员将提出一些用户可以自由回答的开放性问 题,以鼓励被访问人员说出自己的想法。
3. 调查表 经过仔细考虑写出的书面回答可能比被访者对问 题的口头回答更准确。
结构化分析过程:实质上是一种创建模型的活动。 系统分析员从不同角度抽象出目标系统的特性,使 用精确的表示方法构造系统的模型,验证模型是否 满足用户对目标系统的需求,并在设计过程中逐渐 把和实现有关的细节加进模型中,直至最终用程序 实现模型。
15
16
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
17
需求分析的过程
用户需求例子-图书馆管理系统
功能需求:办理读者借书证, … 性能需求:查询操作延迟时间不超过1秒钟, … 设计约束:前台运行在windows OS下,… 其它要求:开发时间6个月, …
23
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
24
需求获取
获取技术
软件需求分析总是从两方或多方之间的通信 开始。用户面临的问题需要用基于计算机的 方案来解决;开发者应该对用户的需求作出 反应,给用户提供帮助。这样就产生了相互 通信的需求。 但是,正如前面已经讲过的,从开始通信到 真正相互理解的道路通常是充满坎坷的。良
6
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
7
需求分析的重要性
真的很重要吗?
Case: Our real-time example is based on the embedded
software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane-5 ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).
9
需求分析的重要性
To understand why, Standish (1995) asked the survey respondents to explain the causes of the failed projects. The top factors were reported to be 1. incomplete requirements (13.1%) 2. lack of user involvement (12.4%) 3. lack of resources (10.6%) 4. unrealistic expectations (9.9%) 5. lack of executive support (9.3%) 6. changing requirements and specifications (8.7%) 7. lack of planning (8.1%) 8. system no longer needed (7.5%)
32
分析建模
结构化分析(Structured Analysis, SA)是一种确 定模型的活动。 模型:就是为了理解事物而对事物做出的一种抽象, 是对事物的一种无歧义的书面描述。通常,模型由 一组图形符号和组织这些符号的规则组成。 SA用抽象模型的概念,按照软件内部数据传递、变 换的关系,自顶向下逐层功能分解的系统分析方法 来定义系统的需求。
DeMarco在一份研究报告中指出,被检查出来的 错误的56%产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现,在一份美国 军方大型管理信息系统的需求现格说明书(SRS) 中存在着500多个错误,当然这仅仅是一个软件 项目中的一次调查。
12
需求分析的重要性
4.在需求阶段,代表性的错误为疏忽、不 一致和二义性。
需求分析
(Requirements Analysis)
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
2
outline
需求分析概述 需求分析的重要性 需求分析的过程 需求获取 分析建模 需求规格说明书
10
需求分析的重要性
Five Facts
1. 软件生命周期中,一个错误发现得越晚, 修复错误的费用越高。
生命周期中修复软件的相对费用 阶段 需求阶段 设计阶段 相对修复费用 0.1 ~ 0.2 0.5
编码阶段
单元测试阶段 验收测试阶段 维护阶段
1
2 5 20
11
需求分析的重要性
2.许多错误是潜伏的,并且在错误产生后很长 一段时间才被检查出来。 3.在需求过程中会产生很多错误。
原则
和用户进行交流和合作 将对原始问题理解与软件开发经验结合, 发现 ….
21
步骤2:描述和分析用户需求阶段
任务
对用户需源自文库进行建模,生成SRS和初步用户手册 SRS : 用户需求(功能, 行为, 性能等) 用户手册:如何操作和使用目标软件,界面描述 和使用初步构想,目的…
33
分析建模
适用于分析大型的数据处理系统。 方法的特点:利用数据流图(Data Flow Diagram, DFD)来帮助理解问题,对问题进行分析。
功能分析工具:DFD、DD。 数据分析工具:ER图或者EER(扩展ER)图。 行为分析工具:状态迁移图、Petri网等。
34
分析建模
29
快速建立软件原型
快速建立软件原型是最准确、最有效、最
强大的需求分析技术。
快速原型就是快速建立起来的旨在演示目
标系统主要功能的可运行的程序。
构建原型的要点是,它应该实现用户看得
见的功能,省略目标系统的“隐含”功能。
30
快速原型的特性:
“快速”。快速原型的目的是尽快向用户提供一 个可在计算机上运行的目标系统的模型。因此, 原型的某些缺陷是可以忽略的。
28
4. 情景分析技术 对用户将来使用目标系统解决某个具体问题的方 法和结果进行分析。 情景分析技术的用处: 能在某种程度上演示目标系统的行为,从而便于 用户理解,而且还可能进一步揭示出一些分析员 目前还不知道的需求。 能保证用户在需求分析过程中始终扮演一个积极 主动的角色。让用户起积极主动的作用对需求分 析工作获得成功是至关重要的。
13
需求分析的重要性
5.需求错误是可以被检查出来的。
发现错误的比例 发现错误的方法 检查 单元测试 集成测试 发现错误的比例(%) 65 10 5
维护
其它
6
14
14
需求分析的重要性
在需求过程中会产生很多错误(fact3,4)。 许多错误并没有在早期被发现(fact2)。 这样的错误是能够在产生的初期被检查出 来的(fact5)。 如果没有及时检查出来这些错误,软件费 用会直线上升(fact1)。
相关文档
最新文档