第2章-需求分析(1)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2013-8-5
27
结构化语言
• • • • 结构化语言描述 判定表 判定树 窗体式规格
2013-8-5
28
(1) 结构化语言描述
• 结构化语言使用的词汇进行了限制,并且可以 使用固定的模板来定义系统的需求。 • 例如:结构化英语
结构化英语的词汇表由 英语命令动词 数据词典中定义的名字 有限的自定义词 逻辑关系词 IF_THEN_ELSE、 CASE_OF 、 WHILE_DO、 REPEAT_UNTIL等组成。
领域需求描述的一个例子
功能需求
例如一个图书馆系统的需求:
1。需要一个基于Z39.50标准的、面向所有数 据库的标准用户界面。 2。因为版权限制,一些文档只能根据用户需 要输出到本地打印机或网络打印机上。
关于版权法对图书资料保护 的需求,描述了一类文档打 印完立即删除的功能
2013-8-5 21
2 用户需求
25
Dogs must be carried.
2013-8-5
NL的表现
• • • • • 到1999年底,它还欠款1000元。 自行车还没有修好,修车的急坏了。 北京图书馆收藏着章太炎的书。 这辆车没有锁。 巴勒斯坦游击队对以色列的进攻是早有 准备的。 • ………………
2013-8-5 26
NL 規格的替代表示法
软件工程教研室
课程名称:软件工程
第9-18讲 第2章 软件项目的需求分析
任课教师: 教师E-mail:
2013-8-5
熊伟 x_w_ei@163.com
0
需求问题举例
需求的隐含错误 需求不明确、含糊 用户不断增加需求、变更需求 用户刁难 开发人员的镀金
2013-8-5
1
本章要点
一、需求概述 二、需求工程 三、需求建模方法 四、需求分析过程 五、案例分析
Shortage of software engineers Fixed - price contract
缺乏软件工程师
Biblioteka Baidu
固定价合同
Inadequate communications for system integration 系统集成阶段 , 交流与沟通不充分
团队缺乏经验
缺乏应用领域专家
Shortage of application domain experts
2013-8-5 4
需求分析的任务是什么?
需求分析的任务 准确地定义未来系统的目标,确定为了满 足用户的需求系统必须做什么。并用 <需求 规格说明书> 规范的形式准确地表达用户的 需求。
需求的层次和分类是什么?
分三个层次: 用户需求 系统需求 软件设计描述
2013-8-5
分三类: 功能需求 非功能需求 领域需求
平均值
4.5 4.3 4.2 4.1 4.1 3.9 3.8 3.8 3.6 3.6
Shortage of systems engineers
缺乏系统工程师
缺乏了解软件特性的经理人 缺乏合格的项目经理
Shortage of software managers
Shortage of qualified project managers
2013-8-5
项目失败的原因分析
No.
1 2 3 4 5 6 7 8 9 10 Insufficient experience as team
Top 10 Factors
Inadequate requirements specification Changes in requirements 需求的改变 不充分的需求规范
24
2013-8-5
自然语言的问题(NL)
• 不够清楚 使用语言时有时候很难精确、清楚的描述 • 需求混淆 – 功能与非功能需求可能会产生混淆 • 需求混合 – 将好几种不同需求一同表示
Shoes must be worn. (〔乘车时〕鞋子必须穿上) (〔乘车时〕必须穿着鞋子) (〔乘车时〕必须把鞋子穿在脚上) (〔乘车时〕狗必须抱着) (〔乘车时〕必须抱着狗) (〔乘车时〕必须把狗抱在身上)
对文本加亮(使用黑体或斜体)来突出显示关键性的需求。
尽量避免用计算机专业术语。但不可避免地会用到应用 领域的专业术语。
2013-8-5 23
3 系统需求
系统需求是比用户需求更详细的需求描述,是 系统实现的基本依据。因此,是一个完全的和 一致的系统描述,是软件工程人员系统设计的 起点。
系统需求描述可能包括许多不同模型,如对象 模型和数据流模型。 原则上讲,系统需求应该陈述系统应该做什么 而不包括系统应该如何实现。然而,在细节层 次上会提到设计信息.
2013-8-5 15
非功能需求的分类
2013-8-5
16
非功能需求的检验举例
系统目标
系统应该很好用,即使对一个没有经验的用户, 而且应该使得用户错误降到最少 可检验的非功能需求 对一个没有经验的用户来说,经过两个小时的 培训就应该能使用系统的所有功能。在这样的 培训之后,一个有经验的用户每天的出错平均 数不应超过两次
2013-8-5
2
一、需求概述
• 1. 2. 3. 4. 5. 本节将要学习的内容如下: 软件需求的基本概念 功能需求和非功能需求 用户需求 系统需求 软件需求文档
2013-8-5
3
基本概念
什么是软件需求? 开发软件所需要的各种条件。需求是指用 户对软件的功能和性能的要求,就是用户 希望软件能做什么事情,完成什么样的功 能,达到什么性能。 什么是需求工程? 对服务和约束的发现、分析、建立文档、检 验的过程叫做需求工程。
用户需求是从用户角度来描述系统功能 和非功能需求。让不具备专业知识的人 看懂。
这样的需求描述只描述系统的外部行为, 因而,用户需求就不可能使用任何实现 模型来描述,而是用自然语言、图表和 直观的图形来叙述。
2013-8-5 22
书写用户需求应该遵守的原则
设计一个标准的格式,保证所有的需求定义都按照该 格式书写。这种格式包括对初始需求描述的扩展、用 户需求的基本原理以及详细的系统需求描述的索引。 使用一致的语言。尤其要区别强制性和希望性的需求。 定义强制性需求时要使用“必须”,定义希望性需求时 使用“应该”。
2013-8-5
非功能需求 的检验非常 困难,用定 量化的描述 来衡量非功 能需求是否 达到目标是 一种不错的 办法。
17
指定非功能需求的度量
性质 Speed Size Ease of use Reliability 度量方法
Processed transactions/second User/Event response time Screen refresh time Mbytes ,Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems
2013-8-5 29
结构化英语的特点
• 是一种介于自然语言和形式化语言之间的语言 • 语言的正文用基本控制结构进行分割,加工中的操作 用自然语言短语来表示 • 其基本控制结构有三种: – 简单陈述句结构:避免复合语句; – 重复结构:while_do 或 • repeat_until 结构。 – 判定结构:if_then_else 或 • case_of 结构;
2013-8-5
31
(2) 判定表
• 如果数据流图的加工需要依赖 于多个逻辑条件的取值,使用 判定表来描述比较合适
2013-8-5
32
以“检查发货单”为 例
2013-8-5
33
2013-8-5
34
(3) 判定树
• 判定树也是用来表达加工逻辑的一种工 具。有时侯它比判定表更直观。 欠款>60天 不发出批准书 检 金额>$500 欠款60天 发出批准书、 查 发货单 发 欠款>60天 发出批准书、 货 发货单及赊欠报告 金额$500 单 欠款60天 发出批准书、 发货单 2013-8-5 35
2013-8-5 13
功能性用户需求举例
一个大学图书馆系统的功能需求描述:这个系统为 学生和教工从其他图书馆借阅图书和文献提供服务。 1。用户能从总的数据库中查询或者是选择其中的一个 子集。 2。系统能提供适当的浏览器供用户阅读馆藏文献。 3。每次借阅能对应一个独特的识别符(0RDER_ID), 可拷贝到用户账户的常备储存区内。
18
Robustness Portability
2013-8-5
非功能需求和功能需求之间的关系
非功能需求和功能需求之间会产生冲突, 比如性能的要求和目标之间。3D画面, 容量与功能等等。 尽量对非功能需求和功能需求在文档中 分开叙述,易于采用不同的指标分析功 能是否达到要求。不能分开的视具体系 统情况而定,可以采用折中办法
2013-8-5 19
领域需求
领域需求起源于系统的应用领域而不是系统 的用户需要。 它们可能是一个新的特有的功能需求、对已 存在的功能需求的约束或者是需要实现的一 个特别计算。 因为它们时常反映应用领域的基本问题,所 以领域需求很重要。如果这些需求不被满足, 系统的正常运转就不可能。
2013-8-5 20
2013-8-5
14
非功能需求
非功能需求是对系统提供的服务或功能给出的约 束。包括时间约束、开发过程的约束、标准等。
它们与系统的总体特性相关,如可靠性、反应时 间和储存空间等。 一个功能需求没有满足会可能降低系统的能力, 而一个非功能系统需求没有满足是则可能使整个 系统无法使用。 非功能需求源于用户对系统的限制。如预算,政 策,安全规章,隐私保护等等。
2013-8-5
9
不同类型需求的读者对象
2013-8-5
10
软件需求的层次
业务需求 用户需求 非功能性需求
质量特性
功能需求 系统需求
约束和假设
软件需求规格
2013-8-5 11
1 功能需求和非功能需求
• 软件系统需求的分类:
功能需求 非功能需求 领域需求
2013-8-5
12
功能需求
功能需求描述系统所预期提供的功能或服务。 功能需求说明: 1. 如果是用户需求,就用较一般的描述给出,若是 功能性的系统需求,则需要详细地描述系统功能、 输人和输出、异常等。 2. 用户常希望得到清晰的功能需求描述,而开发者 则希望模糊。然而,不严密的描述常常成为软件 问题的根源。 3. 理论上,系统的功能描述应做到全面,一致。然 而,在大型的软件开发中做到这一点,是有困难 的。
5
需求分析的重要性及困难是什么?
重要性 需求分析是发现、求精、建模、规格说明 和复审的过程; 需求分析是系统设计的基础,关系到工程 的成败和软件产品的质量。 一是用户需求的动态性(不稳定性) 需求获取 困难 ,原因有三 二是需求的模糊性(不准确性) 三是需求必须得到用户的确认,否则毫无 意义
6
3 = Serious
Scale: 5 = Very Serious
1 = No Serious
7
Source: Carnegie-Mellon University, Software Engineering Institute 2013-8-5
需求管理的重要性
2013-8-5
8
软件需求的3个层次:
1. 用户需求 是用自然语言加图表的形式给出的关 于系统需要提供哪些服务以及系统操作受到哪些 约束的声明。 2. 系统需求 详细地给出系统将要提供的服务以及 系统所受到的约束。它可能成为系统买方和软件 开发者之间合同的重要内容。 3. 软件设计描述 是对软件设计活动的概要描述, 是详细设计和实现的基础。这个描述是在系统需 求描述的基础上再加入更详细的内容构成的。
2013-8-5 30
商店业务处理系统中“检查发货单”
if 发货单金额超过$500 then if 欠款超过了60天 then 在偿还欠款前不予批准 else (欠款未超期) 发批准书,发货单 else (发货单金额未超过$500) if 欠款超过60天 then 发批准书,发货单及赊欠报告 else (欠款未超期) 发批准书,发货单