软件项目需求管理课程.ppt
合集下载
第04章 软件项目需求管理

❖软件的需求管理的复杂性主要体现在以下几 个方面。
❖ (1)需求的描述问题。 ❖ (2)需求的完备程度问题。 ❖ (3)需求开发的工期问题。 ❖ (4)需求的细致程度问题。 ❖ (5)需求的变化问题。
4.2.3需求管理的方法
❖ 在需求管理中,可以采用的方法主要包括以下一些 方面。
❖ (1)确定需求变更控制过程。 ❖ (2)进行需求变更影响分析。 ❖ (3)建立需求基准版本和需求控制版本文档。 ❖ (4)维护需求变更的历史记录。 ❖ (5)跟踪需求的状态。 ❖ (6)衡量需求的稳定性。
第4章 软件项目需求管理
本章目录
4.1软件需求概述 4.2需求管理方法与内容 4.3软件项目的任务分解 4.4软件需求的变更控制 4.5 案例与讨论
4.1软件需求概述
1 4.1.1软件需求的层次划分
2
4.1.2用户需求与特点分析
3
4.1.3系统需求与类型划分
4 4.1.4软件需求规格说明书 55
求是指用户对软件的功能和性能的要求,就 是用户希望软件能做什么事情,完成什么样的功能 ,达到什么样的性能。软件人员要准确理解用户的 要求,进行细致的调查分析,将用户的需求陈述转 化为完整的需求定义,再由需求定义转化为需求规 格说明。
❖ 软件需求可以按照层次进行划分,其内容包括业务 需求、用户需求、功能需求、软件需求规格等层次 。
4.2. 4需求管理的过程
❖ 需求管理的过程从需求获取开始,一直贯穿于整个 项目生命周期,其目的是力图实现最终产品同用户 需求的最佳结合。在整个需求管理过程中,主要包 括了以下内容。
❖ 1.需求获取 ❖ 2.需求确认 ❖ 3.建立需求状态 ❖ 4.需求验证 ❖ 5.需求承诺 ❖ 6.需求跟踪 ❖ 7.需求变更控制
❖ (1)需求的描述问题。 ❖ (2)需求的完备程度问题。 ❖ (3)需求开发的工期问题。 ❖ (4)需求的细致程度问题。 ❖ (5)需求的变化问题。
4.2.3需求管理的方法
❖ 在需求管理中,可以采用的方法主要包括以下一些 方面。
❖ (1)确定需求变更控制过程。 ❖ (2)进行需求变更影响分析。 ❖ (3)建立需求基准版本和需求控制版本文档。 ❖ (4)维护需求变更的历史记录。 ❖ (5)跟踪需求的状态。 ❖ (6)衡量需求的稳定性。
第4章 软件项目需求管理
本章目录
4.1软件需求概述 4.2需求管理方法与内容 4.3软件项目的任务分解 4.4软件需求的变更控制 4.5 案例与讨论
4.1软件需求概述
1 4.1.1软件需求的层次划分
2
4.1.2用户需求与特点分析
3
4.1.3系统需求与类型划分
4 4.1.4软件需求规格说明书 55
求是指用户对软件的功能和性能的要求,就 是用户希望软件能做什么事情,完成什么样的功能 ,达到什么样的性能。软件人员要准确理解用户的 要求,进行细致的调查分析,将用户的需求陈述转 化为完整的需求定义,再由需求定义转化为需求规 格说明。
❖ 软件需求可以按照层次进行划分,其内容包括业务 需求、用户需求、功能需求、软件需求规格等层次 。
4.2. 4需求管理的过程
❖ 需求管理的过程从需求获取开始,一直贯穿于整个 项目生命周期,其目的是力图实现最终产品同用户 需求的最佳结合。在整个需求管理过程中,主要包 括了以下内容。
❖ 1.需求获取 ❖ 2.需求确认 ❖ 3.建立需求状态 ❖ 4.需求验证 ❖ 5.需求承诺 ❖ 6.需求跟踪 ❖ 7.需求变更控制
软件项目需求管理教材(PPT 81页)

chapter__4
40
原型系统
原型实例
chapter__4
41
本章要点
一、软件需求定义 二、软件需求管理过程 三、需求建模的基本方法
原型方法 结构化分析法 面向对象的用例分析法 功能列表法 其他
四、案例分析
chapter__4
42
结构化分析方法
(SA,Structured Analysis)
项目经理自行决定
拒绝 修改合同相关信息
接受本次修改
chapter__4
修改相关需求
下个版本再修改
33
修改相应的项目计划
申请人
项目名称
阶段名称 文件名称
修改内容
韩万江
软件基表线4-3产需求品变修更提改交单提交单
申请日期
2002。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
同意RCR-PM-01.doc变更。RCR-PM-02.doc的变更可以推迟到下一个版本实施
验证人 韩万江,姜岳尊,孙泉
20世纪70年发展起来的面向数据流的方 法
是一种自顶向下逐步求精的分析方法
根据软件内部数据传递、变换的关系进 行分析的
chapter__4
43
结构化分析方法-技术
数据流图(DFD) 数据字典(DD) 系统流程图
chapter__4
44
描述银行取款过程的数据流图
第6章软件工程需求开发及管理PPT课件

需求包括:技术性需求、非技术性需求、功能需求、 非功能需求,来自客户的需求、来自项目组内部的需 求等。
项目组应该管理需求变更(当出现变更时),并且识 别在项目计划、工作产品和需求之间发生的不一致项 。作为需求管理的一个部分,需求变更及其理由应填 入记录文档,并且在最初需求与产品和产品组件的所 有需求之间维持双向可追溯性。
需求开发(RD)
目的:产生并分析用户、产品及产品组件需求。需求 作为设计的基础,在开发过程中,需要收集软件需求 、客户或其他利益同担者的需要,对所有可能的需求 及需要进行分析,并对分析的结果进行评审,最终针 对需求达成一致。
共计三类需求,分别是客户需求、产品需求、产品组 件需求,整体来说,这些需求侧重于相关干系人(含 客户)的需要,包括那些与各个产品生命周期(比如 ,接受测试准则)及产品属性(比如,安全性、可靠 性、可维护性)有关的需要。需求还侧重于由于解决 方案设计的选择而导致的约束(比如,与第三方外购 商业软件集成)。
SP 1.5 Identify Inconsistencies Between Project Work and Requirements(识别项目工作与需求之间的不一致项)
目的是发现需求与项目计划和工作产品之间的不一致项,并启 动纠正措施。
工作产品:记录不一致项目的文档;启动的纠正措施。
实践步骤:一是评审项目计划、活动和工作产品与需求及其变 更一致性;二是识别不一致项的来源和理由;三是识别因需求 基线变更而导致的项目计划、活动和工作产品的变更;四是启 动纠正措施。
SP 2.1 Establish Product and Product Component Requirements(建立产品和产品组件需求),基于客 户需求来建立和维护产品及产品组件需求。
项目组应该管理需求变更(当出现变更时),并且识 别在项目计划、工作产品和需求之间发生的不一致项 。作为需求管理的一个部分,需求变更及其理由应填 入记录文档,并且在最初需求与产品和产品组件的所 有需求之间维持双向可追溯性。
需求开发(RD)
目的:产生并分析用户、产品及产品组件需求。需求 作为设计的基础,在开发过程中,需要收集软件需求 、客户或其他利益同担者的需要,对所有可能的需求 及需要进行分析,并对分析的结果进行评审,最终针 对需求达成一致。
共计三类需求,分别是客户需求、产品需求、产品组 件需求,整体来说,这些需求侧重于相关干系人(含 客户)的需要,包括那些与各个产品生命周期(比如 ,接受测试准则)及产品属性(比如,安全性、可靠 性、可维护性)有关的需要。需求还侧重于由于解决 方案设计的选择而导致的约束(比如,与第三方外购 商业软件集成)。
SP 1.5 Identify Inconsistencies Between Project Work and Requirements(识别项目工作与需求之间的不一致项)
目的是发现需求与项目计划和工作产品之间的不一致项,并启 动纠正措施。
工作产品:记录不一致项目的文档;启动的纠正措施。
实践步骤:一是评审项目计划、活动和工作产品与需求及其变 更一致性;二是识别不一致项的来源和理由;三是识别因需求 基线变更而导致的项目计划、活动和工作产品的变更;四是启 动纠正措施。
SP 2.1 Establish Product and Product Component Requirements(建立产品和产品组件需求),基于客 户需求来建立和维护产品及产品组件需求。
软件开发项目管理-PPT精品.ppt

软件开发项目管理
北京邮电大学软件学院 韩万江
chapter__4
0
承上启下
项目合同管理 生存期模型
chapter__4
1
RoadMap
合同管理 生存期 需求管理 任务分解 规模估算 项目进度
质量计划 配置计划 风险计划 团队管理 项目度量
集成项目 跟踪控制 项目结束
chapter__4
2
软件开发项目管理
chapter__4
11
软件需求管理过程
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
需求变更
需求变更
chapter__4
13
需求开发(确认)和管理基本任务
需求工程
需求开发
需求管理
需求获取 需求验证
需求分析
需求规格说明
chapter__4
变更管理
版本控制 风险分析
14
5
软件需求定义
软件需求
需求是指用户对软件的功能和性能的 要求,就是用户希望软件能做什么事 情,完成什么样的功能,达到什么性 能。
chapter__4
7
软件需求的层次
业务需 求
用户需 求
非功能性需 求
系统需 求
功能需 求
质量特 性
约束和假 设
软件需求规格
chapter__4
8
需求管理的重要性
chapter__4
5. 建立需求基准版本和需求控制版本文档
6. 维护需求变更的历史记录
7. 跟踪每项需求的状态
8. 衡量需求稳定性
chapter__4
22
软件需求规格说明的原则
北京邮电大学软件学院 韩万江
chapter__4
0
承上启下
项目合同管理 生存期模型
chapter__4
1
RoadMap
合同管理 生存期 需求管理 任务分解 规模估算 项目进度
质量计划 配置计划 风险计划 团队管理 项目度量
集成项目 跟踪控制 项目结束
chapter__4
2
软件开发项目管理
chapter__4
11
软件需求管理过程
软件需求管理的过程
需 求 需求获取 确 认
需求验证
需求分析 编写需求规格
需求变更
需求变更
chapter__4
13
需求开发(确认)和管理基本任务
需求工程
需求开发
需求管理
需求获取 需求验证
需求分析
需求规格说明
chapter__4
变更管理
版本控制 风险分析
14
5
软件需求定义
软件需求
需求是指用户对软件的功能和性能的 要求,就是用户希望软件能做什么事 情,完成什么样的功能,达到什么性 能。
chapter__4
7
软件需求的层次
业务需 求
用户需 求
非功能性需 求
系统需 求
功能需 求
质量特 性
约束和假 设
软件需求规格
chapter__4
8
需求管理的重要性
chapter__4
5. 建立需求基准版本和需求控制版本文档
6. 维护需求变更的历史记录
7. 跟踪每项需求的状态
8. 衡量需求稳定性
chapter__4
22
软件需求规格说明的原则
软件项目需求管理教材(PPT 43张)

UML需求视图
用例视图(Use
case Diagram) 顺序图(Sequence Diagram) 状态图(State Diagram) 活动图(Activity Diagram)
用例实例
功能列表
需求类别(功能/性能) A.1 特性(Feature) A …… A.n B.1 特性Feature B …… B.n C.1 特性Feature C …… C.n 名称/标识 描述
规格文档参考
1.
2.
3. 4.
5.
6. 7. 8. 9. 10.
引言 系统定义 应用环境 功能规格 性能需求 产品提交 实现约束 质量描述 其它 签字认证
本章要点
一、软件需求定义 二、软件需求管理过程
需求的获取 需求分析 编写需求规格 需求验证 需求变更
三、需求建模的基本方法
需求验证
软件需求管理的过程
需 求 确 认
需求获取
需求分析
需求验证
编写需求规格
需求变更
需求变更
需求开发(确认)和管理基本任务
需求工程
需求开发
需求管理
需求获取
需求分析
变更管理 版本控制
需求验证
需求规格说明
风险分析
本章要点
一、软件需求定义 二、软件需求管理过程
需求的获取 需求分析 编写需求规格 需求验证 需求变更
• • • • • • • • • • • • • • • • • • • •
1、想要体面生活,又觉得打拼辛苦;想要健康身体,又无法坚持运动。人最失败的,莫过于对自己不负责任,连答应自己的事都办不到,又何必抱怨这个世界都和你作对?人生的道理很简单,你想要什么,就去付出足够的努力。 2、时间是最公平的,活一天就拥有24小时,差别只是珍惜。你若不相信努力和时光,时光一定第一个辜负你。有梦想就立刻行动,因为现在过的每一天,都是余生中最年轻的一天。 3、无论正在经历什么,都请不要轻言放弃,因为从来没有一种坚持会被辜负。谁的人生不是荆棘前行,生活从来不会一蹴而就,也不会永远安稳,只要努力,就能做独一无二平凡可贵的自己。 4、努力本就是年轻人应有的状态,是件充实且美好的事,可一旦有了表演的成分,就会显得廉价,努力,不该是为了朋友圈多获得几个赞,不该是每次长篇赘述后的自我感动,它是一件平凡而自然而然的事,最佳的努力不过是:但行好事,莫问前程。愿努力,成就更好的你! 5、付出努力却没能实现的梦想,爱了很久却没能在一起的人,活得用力却平淡寂寞的青春,遗憾是每一次小的挫折,它磨去最初柔软的心智、让我们懂得累积时间的力量;那些孤独沉寂的时光,让我们学会守候内心的平和与坚定。那些脆弱的不完美,都会在努力和坚持下,改变模样。 6、人生中总会有一段艰难的路,需要自己独自走完,没人帮助,没人陪伴,不必畏惧,昂头走过去就是了,经历所有的挫折与磨难,你会发现,自己远比想象中要强大得多。多走弯路,才会找到捷径,经历也是人生,修炼一颗强大的内心,做更好的自己! 7、“一定要成功”这种内在的推动力是我们生命中最神奇最有趣的东西。一个人要做成大事,绝不能缺少这种力量,因为这种力量能够驱动人不停地提高自己的能力。一个人只有先在心里肯定自己,相信自己,才能成就自己! 8、人生的旅途中,最清晰的脚印,往往印在最泥泞的路上,所以,别畏惧暂时的困顿,即使无人鼓掌,也要全情投入,优雅坚持。真正改变命运的,并不是等来的机遇,而是我们的态度。 9、这世上没有所谓的天才,也没有不劳而获的回报,你所看到的每个光鲜人物,其背后都付出了令人震惊的努力。请相信,你的潜力还远远没有爆发出来,不要给自己的人生设限,你自以为的极限,只是别人的起点。写给渴望突破瓶颈、实现快速跨越的你。 10、生活中,有人给予帮助,那是幸运,没人给予帮助,那是命运。我们要学会在幸运青睐自己的时候学会感恩,在命运磨练自己的时候学会坚韧。这既是对自己的尊重,也是对自己的负责。 11、失败不可怕,可怕的是从来没有努力过,还怡然自得地安慰自己,连一点点的懊悔都被麻木所掩盖下去。不能怕,没什么比自己背叛自己更可怕。 12、跌倒了,一定要爬起来。不爬起来,别人会看不起你,你自己也会失去机会。在人前微笑,在人后落泪,可这是每个人都要学会的成长。 13、要相信,这个世界上永远能够依靠的只有你自己。所以,管别人怎么看,坚持自己的坚持,直到坚持不下去为止。 14、也许你想要的未来在别人眼里不值一提,也许你已经很努力了可还是有人不满意,也许你的理想离你的距离从来没有拉近过......但请你继续向前走,因为别人看不到你的努力,你却始终看得见自己。 15、所有的辉煌和伟大,一定伴随着挫折和跌倒;所有的风光背后,一定都是一串串揉和着泪水和汗水的脚印。 16、成功的反义词不是失败,而是从未行动。有一天你总会明白,遗憾比失败更让你难以面对。 17、没有一件事情可以一下子把你打垮,也不会有一件事情可以让你一步登天,慢慢走,慢慢看,生命是一个慢慢累积的过程。 18、努力也许不等于成功,可是那段追逐梦想的努力,会让你找到一个更好的自己,一个沉默努力充实安静的自己。 19、你相信梦想,梦想才会相信你。有一种落差是,你配不上自己的野心,也辜负了所受的苦难。 20、生活不会按你想要的方式进行,它会给你一段时间,让你孤独、迷茫又沉默忧郁。但如果靠这段时间跟自己独处,多看一本书,去做可以做的事,放下过去的人,等你度过低潮,那些独处的时光必定能照亮你的路,也是这些不堪陪你成熟。所以,现在没那么糟,看似生活对你的亏欠,其 实都是祝愿。
软件项目管理课程PPT88页

一周的工作量(40小时)。
8 .2 软件项目任务分解
5.责任分配及成本分解
WBHS编o号t Ti预p算
责任者
1
0.1
张明
2
0.46
李立
3
0. 46
张明、李立
3.1
0.04
张明
3.2
0.15
李立
WBS编号 预算
3.3
0.15
3.4
0.1
3.5
0.02
4
0.08
5
0.1
责任者 李立 李立 张明 万风 张明
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴?
❖5W + 1H + 8C ❖5W就是 Who、When、Where、What、Why ❖ Why是关键 ❖1H就是 How – 需求本身的流程 ❖ 8C指的是8个约束和限制,即8个Constraints: ❖ 包括性能Performance、成本Cost、时间Time、
• •
H需流o求程t 分 优T析 化ip计划
• 编写需求说明书
• 编写需求规格词汇表
• 绘制业务流程
• 抽象业务类
• 建立数据模型
• 将需求分析图示加入规格文档
• 需求规格测试
① 需求规格确认
8 .2 软件项目任务分解
• 任务分解过程 1.H分ot解T步i骤p
(1)确认并分解项目的主要组成要素。 (2)确定分解标准 (3)确认分解是否详细,分解结果是否可以作为
东西时就会知道—感觉会随环境变化)
❖过早作出结论(截断需要表达过程——需求分析 需要耐心和自我控制)
8 .2 软件项目任务分解
5.责任分配及成本分解
WBHS编o号t Ti预p算
责任者
1
0.1
张明
2
0.46
李立
3
0. 46
张明、李立
3.1
0.04
张明
3.2
0.15
李立
WBS编号 预算
3.3
0.15
3.4
0.1
3.5
0.02
4
0.08
5
0.1
责任者 李立 李立 张明 万风 张明
Requirements 82%
Design 13%
Other Code 4% 1%
一个小故事
如何练就需求分析的火眼金晴?
❖5W + 1H + 8C ❖5W就是 Who、When、Where、What、Why ❖ Why是关键 ❖1H就是 How – 需求本身的流程 ❖ 8C指的是8个约束和限制,即8个Constraints: ❖ 包括性能Performance、成本Cost、时间Time、
• •
H需流o求程t 分 优T析 化ip计划
• 编写需求说明书
• 编写需求规格词汇表
• 绘制业务流程
• 抽象业务类
• 建立数据模型
• 将需求分析图示加入规格文档
• 需求规格测试
① 需求规格确认
8 .2 软件项目任务分解
• 任务分解过程 1.H分ot解T步i骤p
(1)确认并分解项目的主要组成要素。 (2)确定分解标准 (3)确认分解是否详细,分解结果是否可以作为
东西时就会知道—感觉会随环境变化)
❖过早作出结论(截断需要表达过程——需求分析 需要耐心和自我控制)
软件需求管理PPT课件

编写需求规格说明书
将分析和评估后的需求编写成正 式的需求规格说明书,明确软件 系统的功能、性能、非功能需求、 约束和假设条件等。
评审和确认
对编写好的需求规格说明书进行 评审和确认,确保其准确性和完 整性。
需求分析的工具
思维导图工具
如XMind、MindManager等,用于整理和 分析需求。
原型制作工具
初步需求收集
在项目启动阶段进行,主要目的是确定项目的目标和 范围。
深化需求收集
在初步需求收集之后进行,主要目的是细化功能需求 和非功能需求。
变更需求收集
在软件开发过程中进行,主要目的是应对利益相关者 提出的需求变更请求。
03 需求分析
需求分析的目标
确定软件系统的功能和性能 要求。
确定软件系统的约束和假设 条件。
软件需求的重要性
确保开发目标明确
提高软件质量
明确软件的目标和范围,避免开发偏 离方向。
明确的质量要求有助于提高软件的稳 定性和用户体验。
减少返工和变更成本
尽早识别和解决需求问题,降低开发 成本和时间。
软件需求管理过程
01
需求收集
通过与用户沟通、市场调研等方式 获取原始需求。
需求规格说明
编写详细的需求文档,明确各项需 求的细节。
03
为后续的软件开发和测试提供明确的依据。
04
便于需求变更的管理和控制。
需求规格说明的内容
功能需求
包括业务流程、数据流程、界面交互等。
约束和假设条件
如技术限制、开发环境、资源等方面的约束。
非功能需求
包括性能、安全、可用性、可维护性等方面 的要求。
验收标准
用于评估软件是否满足需求的明确标准。
软件项目管理第8章 软件项目需求及变更管理1PPT课件

第8章 软件项目需求与变更管理
1
第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
2
第8章 软件项目需求与变更管理
我们说,软件项目生命周期的划分有利于软件项目的 管理,尽管许多软件项目周期由于包含类似的工作任务 而具有类似的阶段名称,但很少含有完全相同的情况。 一般软件项目周期划分为以下几个阶段:
7
由上述两个例子可以看出,项目需求管理对于项目的 成功非常重要.只有系统的学习和掌握项目需求管理 知识体系,才能为项目的顺利启动打下坚实的基础.
8
第8章 软件项目需求与变更管理
★ 软件项目的需求 ★ 软件项目的需求开发 ★ 软件项目的需求管理 ★ 软件项目任务分解
9
软件项目需求
软件项目的需求来源于用户调查,即客户的需 要。需求是考虑用户自身的特性与要求,并参照行 业规范进行业务分析的结果。
分析、确认
客户“需要”
形成文档
该文档详细说明了产品“必须或应当”做什么或对 于模糊的部分不做什么。
10
软件项目需求
软件需求的特点:
◆ 模糊性 ◆ 不确定性 ◆ 变化性 ◆ 主观性 软件需求的这些特点,使得软件需求的开发是
软件开发的难点。
11
第8章 软件项目需求与变更管理
★ 软件项目的需求 ★ 软件项目的需求开发 ★ 软件项目的需求管理 ★ 软件项目任务分解
★ 使用户和开发者双方对该软件的初始规定有一个共同 的理解; ★ 给软件设计提供蓝图,精确描述了软件产品做什么以 及产品约束条件; ★ 给系统验收提供验收标准。
写作范例见书P124
1
第一部分
整体概述
THE FIRST PART OF THE OVERALL OVERVIEW, PLEASE SUMMARIZE THE CONTENT
2
第8章 软件项目需求与变更管理
我们说,软件项目生命周期的划分有利于软件项目的 管理,尽管许多软件项目周期由于包含类似的工作任务 而具有类似的阶段名称,但很少含有完全相同的情况。 一般软件项目周期划分为以下几个阶段:
7
由上述两个例子可以看出,项目需求管理对于项目的 成功非常重要.只有系统的学习和掌握项目需求管理 知识体系,才能为项目的顺利启动打下坚实的基础.
8
第8章 软件项目需求与变更管理
★ 软件项目的需求 ★ 软件项目的需求开发 ★ 软件项目的需求管理 ★ 软件项目任务分解
9
软件项目需求
软件项目的需求来源于用户调查,即客户的需 要。需求是考虑用户自身的特性与要求,并参照行 业规范进行业务分析的结果。
分析、确认
客户“需要”
形成文档
该文档详细说明了产品“必须或应当”做什么或对 于模糊的部分不做什么。
10
软件项目需求
软件需求的特点:
◆ 模糊性 ◆ 不确定性 ◆ 变化性 ◆ 主观性 软件需求的这些特点,使得软件需求的开发是
软件开发的难点。
11
第8章 软件项目需求与变更管理
★ 软件项目的需求 ★ 软件项目的需求开发 ★ 软件项目的需求管理 ★ 软件项目任务分解
★ 使用户和开发者双方对该软件的初始规定有一个共同 的理解; ★ 给软件设计提供蓝图,精确描述了软件产品做什么以 及产品约束条件; ★ 给系统验收提供验收标准。
写作范例见书P124
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
PDL 源于像Java或Ada这样 可通过软件工具 表达系统功能的能
的程序设计语言,包含 进行语法和语义 力不足、使用的符
附加的、更抽象的构造 检查
号只有具有程序设
来提高其表达能力
计背景的人才能理
解
2.1.2软件需求层次
➢系统需求的分类
功能需求 非功能需 领域需求
2.1.2软件需求层次
(1) 功能需求
为保证软件项目的成功,无论在哪个阶段,只要发现 问题,都必须修正需求文档.
2.1.2软件需求层次
(2) 非功能需求
非功能需求是指那些不直接与系统的具体功能相关的一类需求, 但它们与系统的总体特性相关,如可靠性,响应时间,存储空间 等。
非功能需求定义了对系统提供的服务或功能的约束,包括时间约 束,空间约束,开发过程约束及应遵循的标准等。
系统需求描述通常采用结构化语言和过程设计语言PDL.
2.1.2软件需求层次
系统需求的描述语言:
表2.1系统需求的描述语言
名称 说明
结构化 是对自然语言格式化, 语言 依赖于定义标准格式或
模板来表达需求描述
优点
缺点
表现能力强、易 于理解 、一致性 约束 、控制结 构 、图形化显示
仍然有一定程度的 二义性;细致程度 欠缺
2.1.3 软件需求质量评价
一个好的需求集应该满足用户解决问题需要的功能和服务,而且尽 量避免软件设计与软件实现的细节.
软件需求质量度量的九个元素:
正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可跟踪性 可理解性
2.1.4 需求工程发展历程
➢ 产生
人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段,而 是贯穿于软件项目开发的整个生命周期。
需求工程的对象化主要是指需求模型及其构造方 法的对象化,面向对象需求模型及需求定义语言是其 研究的关键。
2.1.4 需求工程发展历程
(2)形式化 需求规格描述方法有三种: 形式化方法、非形式化
方法和半形式化方法。 形式化方法:是具有严格数学基础的描述系统特征
的方法,具有准确、无二义性的特点,有助于验证有效 性和完整性。
与能力
2.1.1软件需求概念
➢软件需求在软件项目的作用(如图2.1所示)
制定项目计划
系统构建
基础
产品可 追溯到
用户编制
基础
文档过程
作为 基线确定前 输入 缩小范围
跟踪
状态
项目跟踪和 控制过程
需求管理
验证实现 作为 的正确性 参考
进行 变更 作为 基线
请求范围 缩减
变更控制过程
系统测试过程
图2.1 软件需求与其他软件过程的关系
系统需求和软件设计描述则是具体的,可以根据它 们来进行编码实现.
通常情况下,经常提到的是用户需求和系统需求.
2.1.2软件需求层次
➢ 用户需求
用户需求从用户的角度描述系统的需求,以便没有专业技术 背景的用户能看懂.它只描述系统的外部行为,尽量避免涉及系 统内部的设计特性,因而用户需求就不可能使用任何实现模型来 描述,而只能通过自然语言,图表,图形等来叙述.
2.1.2软件需求层次
使用自然语言可能出现如下问题 描述困难 需求混乱
因此写需求文档应遵守一些简单原则: 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语
2.1.2软件需求层次
➢系统需求
系统需求是比用户需求更为详细和专业的需求描述,是 系统实现的依据.一个完整且一致的系统需求描述,是 软件设计的起点.
可用性需求 效率需求
可靠性需求 可移植性需求 交付需求 实现需求 标准需求 互操作需求 道德需求 立法需求
性能需求 空间需求
隐私需求安全性需求
2.1.2软件需求层次
(3) 领域需求
领域需求的来源不是系统的用户,而是系统应用的领域,反应 了该领域的特点。
领域需求可能是功能需求,也可能是非功能需,其确定需要领 域知识。
的服务及系统的操作约束 ③ 系统需求:用详细的术语给出系统要提供的服务及受到的
约束,因而系统需求文档也称为功能描述. ④ 软件设计:描述是在系统需求的基础上加入更详细的内容
构成的,它作为软件详细设计和实现的基础,是对软件设
计活动的概要描述.
2.1.2软件需求层次
原始问题描述和用户需求的抽象层次比较高.能帮 助我们在较高的抽象层次上进行交流,便于用户和 软件开发人员之间的理解和沟通.
需求工程是一个包括创建和维护需求文档所必需的所有活动的过程, 是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。
需求规格说明又是软件设计、实现、测试直至维护的主要基础。
2.1.4 需求工程发展历程
➢ 发展
需求工程的发展趋势是对象化、形式化和自动化, 并将向着纵深发展和综合发展。 (1)对象化
2.1.2软件需求层次
➢软件需求的四个抽象层次
原始问题描述 用户需求 系统需求 软件设计描述
2.1.2软件需求层次
软件需求的抽象层次如图2.2所示:
图2.2 软件需求的抽象层次
2.1.2软件需求层次
① 原始问题:描述是对要提供
第2章 软件项目需求管理
2.1需求工程 2.2需求开发 2.3需求管理 2.4案例故事解析 2.5总结
2.1需求工程
2.1.1 软件需求概念 2.1.2 软件需求层次 2.1.3 软件需求质量评价 2.1.4 需求工程发展历程 2.1.5 需求工程研究内容
2.1.1软件需求概念
定义:
简单地说,软件需求就是确定系统需要做什么. 严格意义上,软件需求是系统或软件必须达到的目标
按照非功能需求的起源,可将其分为三大类:产品需求,机构需 求,外部需求;产品需求对产品的行为进行描述;机构需求描述 用户与开发人员所在机构的政策和规定;外部需求范围比较广, 包括系统的所有外部因素和开发过程。
2.1.2软件需求层次
表2.2 非功能需求的类别
产品需求
非 功 能 需 机构需求 求
外部需求
功能需求描述系统所应提供的功能和服务,包括系统 应该提供的服务,对输入如何响应及特定条件下系统 行为的描述.
系统的功能需求应该具备全面性和一致性.要做到全 面和一致几乎是不可能的.原因有二,其一是系统本 身固有的复杂性;其二是用户和开发人员站在不同的 立场上,导致他们对需求的理解有偏颇,甚至出现矛 盾