《软件需求分析》第4章需求获取概述PPT课件

格式：ppt
大小：333.50 KB
文档页数：16

下载文档原格式

软件工程PPT4

MiniLibrary：参与者
确定场景

确定参与者和场景的关键在于理解业务领域，这需要理解用户的工作过程和系统的范围。确定场景的问题
–参与者希望系统执行的任务是什么？ –参与者访问什么信息？谁生成数据？ –参与者需要通知系统的哪些外部变化？（时间和频率） –系统需要通知参与者什么事件？（时间）

MiniLibrary：借书
场景名称：借书参与者实例：Bob，图书管理员；John，普通读者事件流程：
1.John向Bob提供个人的注册号、所借图书的编号和书名等； 2.Bob在系统中查询该图书是否在图书馆； 3.Bob登记John的借书记录，并将图书借给John。
其他流程：
1.图书已被借出或者不存在： Bob告诉John无法借出。 2.John不是合法注册用户： Bob 请求John注册后在借书。
功能需求

功能需求
–描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。

举例：MiniLibrary
–用户可以从图书资料库中查询或者选择其中的一个子集。 –系统可以提供适当的浏览器供用户阅读电子文献。 –用户每次借阅图书应该对应一个唯一的标识号，它被记录到用户的帐户上。
内容提纲
软件需求

软件需求
①用户解决问题或达到目标所需的条件或能力。 ②系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 ③一种反映上面①或②所描述的条件或能力的文档说明。

对定义的理解
–软件需求的概念涵盖了用户角度（系统的外部行为）和开发人员角度（系统的内部特性）两个方面，其中的关键在于需求一定要文档化。

软件工程需求分析(精品PPT)

•确定被开发软件系统的系统元素
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页，共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务：
•确定对系统的综合要求
•系统功能要求
第四章析根底
软件工程需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页，共七十七页。
第四章需求分析根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页，共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识，重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件，了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求规格说明,对软件的需求获取是很有必要的
第十六页，共七十七页。
✓需求调查对象
对组织的高层管理者，进行组织管理目标或经营方针等组织战略问题的调查
对中层的管理者，进行全部业务流的调查对业务工作人员，进行详细业务信息的调查
✓市场调查了解市场对待开发软件有什么样的要求；了解市场上有无与待开发软件类似的系统
第十页，共七十七页。
需求(xūqiú)分析流程
第十一页，共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域信息域应包括：

《软件需求分析》课件

关系定义
定义实体之间的关系，如关联、依赖、聚合等。
实体关系图绘制
使用图形化工具绘制实体关系图，展示实体之间的关联关系。
Part
04
需求规格说明
需求规格说明编写
确定需求来源
明确软件需求来自哪些方面，如用户、市场、技术等，确保全面覆盖。
编写规范统一
遵循统一的编写规范，确保需求规格说明的清晰、准确和一致性。
需求分析的过程
需求调研
通过与用户沟通、调查问 1
卷、现场观察等方式，了解用户需求和业务场景。
需求确认
4
将分析出来的需求与用户进行确认，确保双方对需求的理解一致。
需求分析
2
对收集到的需求进行整理
、分类、抽象，形成系统
需求。
需求评审
3 对分析出来的需求进行审
查和评估，确保需求的正确性和完整性。
访谈技巧
注意倾听、引导和追问，以获得深入的需求信息。
记录和分析
详细记录访谈内容，并进行分析，提取关键需求。
问卷调查
设计问卷
根据软件的功能和目标，设计合理的问卷。
选择调查对象
确保调查对象的代表性和广泛性。
发布和收集问卷
通过适当的渠道发布问卷，并确保问卷的完整性和准确性。
数据分析
对收集到的数据进行统计分析，提取关键需求。
详细描述
社交网络平台用户数量庞大，用户交互频繁，对系统的可用性和响应速度要求极高。同时，由于社交网络平台的功能更新频繁，需求变化较快，需求分析需要关注系统的可扩展性和灵活性。此外，社交网络平台还需要考虑用户隐私和数据安全等问题。
THANKS
感谢您的观看
非功能需求定义

软件工程需求分析课件

当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要表明初始状态和最终状态。

43
例题：
办公室复印机的工作过程大致如下：未接到复印命令时处于闲臵状态，一旦接到复印命令则进入复印状态，完成一个复印命令规定的工作后又回到闲臵状态，等待下一个复印命令；如果执行复印命令时发现缺纸，则进入缺纸状态，发出警告，等待装纸，装满纸后进入闲臵状态，准备接受复印命令；如果复印时发生卡纸故障，则进入卡纸状态，发出警告等待维修人员排除故障，故障排除后回到闲臵状态。
系统对事件的响应，既可以是做一个（或一系列）动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。
40
初态：终态：中间状态：
状态名状态变量
活动表
事件：
事件名（参数表）[条件]/动作表达式
状态转换：
41
状态图中使用的主要符号
42

状态图可以表示系统循环运行过程，也可以表示系统单程生命期。
时就应该再次订货。
27

再次阅读可知：

事务有类型，需要根据不同情况处理；---处理事务

对各类事务要更改库存信息；对出库事务当库存量少于临界值时，要产生订货信息。
订货信息不同于订货报表，报表要有严格的格式。------产生报表

28
库存清单（信息）
订货订货报表 CRT终端事务 2 1 采购员（仓库管处理事务信息产生报表（部）理员）订货信息订货信息订货信息
11
系统流程图（4）
12
系统流程图（5）
13
数据流图（1）
一.数据流图的作用

《软件需求工程》课件

需求变更管理
需求变更分类
将需求变更分为功能性需求变更、非功能性需求变更和设计约束变更等。
变更影响分析
对需求变更的影响进行分析，评估变更对项目进度、成本和风险等方面的
影响。
变更控制流程
建立严格的变更控制流程，包括变更申请、审批、实施和验证等阶段。
变更实施与跟踪
实施需求变更，并对变更实施过程进行跟踪，确保变更的有效性和正确性。
用于记录和管理需求变更，确保需求的一致性和完整性。
如Enterprise Architect、Visio等，用于绘制数据流图、实体关系图等，帮助分析人员更好地理解和管理需求。
通过建立需求与设计、代码、测试用例之间的关联，确保需求的实现和验证。
如录音笔、屏幕录制软件等，用于记录用户的原始需求和问题，便于后续分析和整理。
风险识别
识别需求工程中可能出现的风险，如需求变更频繁、需求不清晰等。
风险应对措施
制定风险应对计划，包括风险预防、减轻和转移等措施。
风险评估
对识别出的风险进行评估，分析风险发生的概率和影响程度。
风险监控与报告
对风险应对措施的实施过程进行监控，定期报告风险状态和应对效果。
06 软件需求工程实践
需求分析的步骤
01
需求获取
通过与用户沟通、观察用户操作等方式，了解用户的需求和期望
。
03
需求评审
对已定义的需求进行审查和评估，确保需求的准确性和完整性。
02
需求分析和定义
对获取的需求进行整理、分类和细化，明确需求的范围、功能、
性能等要求。
04
需求变更管理
建立需求变更的流程和机制，确保在项目过程中对需求的变更进

第4章.需求获取概述

3.5 获取的结果

肯定会产生获取笔录（Elicitation Notes）

用户需求、问题域知识和约束可能具有组织差、冗余、遗漏、自相矛盾等诸多问题可以包括文字记录、录音、摄像等各种形式

可能会产生两份定义明确的正式文档

项目前景和范围文档用例文档
主要内容
1. 2. 3.
4.
需求获取概述主要内容尽力去研究应用的背景理解组织的状况形成一个能够和用户进行有效沟通的粗略的知识框架利用有效的获取方法与技巧角色扮演观察等来发现并获取默认知识普通用户的知识结构就相对局限于一些具体的业务细节开发人员在与用户接触之前就先行确定获取的内容主题然后设计具体的应用环境和场景条件由用户根据细节业务的执行来描述问题表达期望

默认（Tacit）知识现象

1. 需求获取的非平凡性

普通用户缺乏概括性、综合性的表述能力

普通用户的知识结构就相对局限于一些具体的业务细节

善于表达具体业务的细节问题

专家用户的知识结构因其渊博性而具有概括性和广泛性

能够回答概括性和综合性的问题

开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。
1. 需求获取的非平凡性

用户存在认知困境

潜在（Latency）知识

需要利用各种有效的需求获取方法和技巧

用户越俎代庖

用户提出的不是需求，而是解决方案

注意保持业务领域和解决方案的区分界限分析用户的深层目的，找到隐藏在背后的需求

第4讲需求获取报告

的执行过程；设计时，描述操作的流程。在描绘对象之间的交互协作方面，活动图不如交互图；在描绘对象的行为方面，活动图不如状态图。
2018/10/12
23
活动图事物
活动 (ActionState) 动作的执行起点 (InitialState) 活动图的开始终点(FinalState) 活动图的终点
2018/10/12
UML表示法
19
假如A类的某个方法中，使用了B类，那么
类之间的关系
就说A类依赖于B类，它们是依赖关系。 A类的某个方法使用B类，可能是方法的参数是B类，也可能是在方法中获得了一个B 类实例。但无论是哪种情况，B类在A类中都是以局部变量的形式存在的。
依赖关系是有向的
-attr11 -attr12 +op11() +op12()
1
*
（e）实现关系的表示
Class1 -attr11 -attr12 +op11() +op12()
c）组合关系的表示
Class1 -attr11 -attr12 +op11() +op12()
Class2 -attr21 -attr22 +op21() +op22()
用例图
需求获取类图
2018/10/12
活动图
7
4.1.1 用例
（一）用例的概念从外部用户的视角看，一个用例（use case）是执行者(actor)与目标软件系统之间一次典型的交互作用，其效果就是执行者在软件系统的帮助下完成了某项业务功能，或达成了某项业务目标。从软件系统内部的视角出发，一个用例代表着系统执行的一系列动作，动作执行的结果能够被外部的执行者所察觉。

《软件项目需求》课件

确定参与评审的人员，包括项目干系人、利益相关者等。
评审标准
制定评审标准，以便对需求规格说明进行客观评价。
PART 04
需求变更管理
REPORTING
需求变更的原因与影响
原因
市场变化、技术更新、客户需求变化等。
影响
可能导致项目进度延误、成本增加、质量下降等。
需求变更的处理流程
收集变更请求
通过各种渠道收集变更请求，如客户反馈、会议讨论等。
控制变更数量
限制不必要的变更，以确保项目按计划进行。
沟通与协调
及时与客户、团队成员沟通变更情况，协调各方利益。
PART 05
需求验证与确认
REPORTING
需求验证的方法与工具
原型法
通过制作软件原型来验证需求的可行性和有效性。
测试用例法
通过编写测试用例来验证需求的实现是否符合预期。
需求验证的方法与工具
案例一：在线购物网站的需求分析
总结词
用户体验需求
在线购物网站需求复杂，需考虑用户体验、功能需求、性能要求等多个方面。
网站界面应简洁明了，操作流程应简单易懂，购物流程应高效便捷。
功能需求
性能要求
包括商品展示、搜索、购物车、结算、支付、订单管理、退换货等功能。
系统应具备高可用性和可扩展性，能够承受大量用户同时访问和交易。
在编写需求文档时，应遵循公司或项目的标准规范，确保文档的一致性和可读性。
保持需求版本控制
随着项目进展，需求可能发生变化。应记录每个版本的修改内容，以便追踪和管理。
需求验证与确认的常见问题与解决方案
问题1
需求描述模糊不清
01
02
解决方案

软件工程中的软件需求管理

需求与设计的关联
建立需求-设计映射
确保设计是基于准确需求的
需求验证
验证设计是否符合需求规格
持续跟踪需求变化
不断迭代确认需求和设计的一致性
需求跟踪工具
JIRA
强大的项目管理和跟踪工具
VersionOne
适用于敏捷开发的需求跟踪软件
Trello
简单直观的需求管理工具
●05
第五章需求管理工具
需求管理工具概述
需求管理工具是通过软件工具来支持需求管理活动的工具，包括需求收集工具、需求建模工具、需求跟踪工具等。这些工具可以帮助团队更好地管理和跟踪需求，提
高项目管理效率。
常用的需求管理工具
JIRA
功能强大，适用于大型团队
Trello
简单易用，适用于小型团队
Rational RequisitePro
软件需求的分类
功能性需求
指明系统应该做什么
非功能性需求
指明系统应该如何做
软件需求管理的重要性
按时交付
预算内完成
满足用户需求
有效的需求管理可以确保项目按时交付
有效的需求管理可以确保项目在预算内完成
有效的需求管理可以确保项目满足用户需求
软件需求管理的挑战
需求不明确
需求可能存在不明确、不完整、不一大型团队需要强大的需求管理功能
预算
需求管理工具费用也是考虑因素
项目需求
不同项目需要不同的需求管理方法
易用性
工具易用性影响团队使用效率
需求管理工具的使用
培训团队成员
建立统一流程
有效使用工具
团队沟通
对工具的培训可以提高团队使用效率定期更新培训内容以跟上工具

软件工程课件之第4章用例和用例图

4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把这些用例组织起来。这种情况在一个系统包含很多子系统时就会出现。另一种可能就是，当你按顺序和用户会谈，收集系统需求时，每个需求必须用一个单独的用例来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货，销售员下班前将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的用户只可以使用一些常规的操作，如查询等，而管理员除了常规操作之外还需要进行一些系统管理工作，如一些关键数据的增加、删除、修改等，操作员既可以进行常规操作又可以进行一些配置操作。

需求获取 PPT课件

3
需求获取的困难
需求不明确
业务不规范，用户的IT素质不高，用自然语言进行表达的需求具有歧义性，这些都将造成需求的不确定性。
需求不稳定
需求是动态的，随着组织的发展
用户的需求往往是粗粒度的，但软件开发要求需求必须是具体的，由粗到细层次和路径很多，不易把握，双方的认识难以达成一致，容易扯皮。
30
4
需求获取示意图
5
需求获取的目的——解决做什么的问题
6
需求获取的目的
与客户共同建立组织模型、业务模型、功能模型、性能模型、接口模型、环境约定和界面约定；
通过评审，与客户达成完全一致的理解，让客户确认，在需求报告上签字，形成稳定可靠的需求文档基线；
明确在验收前，需求相对稳定；需求发生变化，必须经过需求变更程序。
N 项目经理审批
N 审批通过？
Y 财务部发放经费
结束
14
表格分析
单据与报表
名称、用途、使用单位、制作单位、使用频率、高峰时数据流量。
单据流
不同单据之间的先后流动顺序，以及同一单据中的不同数据项的先后流动顺序。
业务要素与数据项
名称、类型、长度、精度、计算方法。
15
需求规格
功能指标：功能点，功能列表性能指标：性能点，性能列表接口指标：接口点，接口列表
需求同行评审，对早期产品的质量保证
25
需求跟踪
需求跟踪矩阵跟踪不符合项的改正情况获得需求目前的实现状态确保用户所有的需求都得到满足对变更的需求进行跟踪
26
需求规格说明书
概述现有系统描述目标系统功能需求目标系统性能需求目标系统接口需求目标系统界面需求目标系统的其他需求目标系统假设与约束条件

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

14
3.4 获取的过程 ——注意事项
在整体上制定组织方案
确定系统的边界，建立上下文图或系统用例图
维护项目的前景和范围引导和控制获取过程接受需求的不稳定性控制探索性工作
15
3.4 获取的过程 —— 防止需求遗漏
务必让所有的涉众都表达出自己的意见。不要以抽象和模糊的需求作为结束。对抽象和
对
问
题
问题分析
解决
的
期
望
业务需求
采集范围
获取源
获取环境
目定义项目前景高层次解决方案项目前景和范
标
和范围Βιβλιοθήκη 系统特性围文档获取内容
选择获取方法、执行获取
业务问题的期望
业务解释
用户需求内容
高层次问题
业务范围
获取源
问题域特性内容记录结果
涉众
特征
涉众分析
采样涉众
涉众特征
成果获取笔录
10
主要内容
相关产品
协作产品的规格说明
原有系统竞争产品
客户的需求文档（委托开发的规格说明、招标书）
协作产品（和解系统存在接口相关技术标准和法规
的其他软件系统）
相关法律、法规及规章制度
行业规范、行业标准
13
3.3 获取的方法
传统方法
问卷调查、面谈、硬数据分析、文档检查、需求剥离等
集体获取方法
第4章. 需求获取概述
1
整体概况
+ 概况1
您的内容打在这里，或者通过复制您的文本后。
概况2
+ 您的内容打在这里，或者通过复制您的文本后。
概况3
+ 您的内容打在这里，或者通过复制您的文本后。
2
主要内容
1. 需求获取的非平凡性 2. 需求获取的活动过程 3. 需求获取活动的要点 4. 需求获取的实践调查情况
3
1. 需求获取的非平凡性
用户和开发人员的背景不同，立场不同
首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够和用户进行有效沟通的粗略的知识框架
默认（Tacit）知识现象
利用有效的获取方法与技巧（角色扮演、观察等）来发现并获取默认知识
4
1. 需求获取的非平凡性
头脑风暴（Brainstorming）、专题讨论会（Workshop）、 JAD等
原型认知方法
任务分析（Task Analysis）、协议分析（Protocol Analysis）等
基于上下文的方法
观察、民族志（Ethnography）和话语分析（Conversation Analysis）
普通用户缺乏概括性、综合性的表述能力
普通用户的知识结构就相对局限于一些具体的业务细节
善于表达具体业务的细节问题
专家用户的知识结构因其渊博性而具有概括性和广泛性
能够回答概括性和综合性的问题
开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。
5
1. 需求获取的非平凡性
用户存在认知困境
潜在（Latency）知识
需要利用各种有效的需求获取方法和技巧
用户越俎代庖
用户提出的不是需求，而是解决方案
注意保持业务领域和解决方案的区分界限
用户固执的坚持某些特征和功能
分析用户的深层目的，找到隐藏在背后的需求
6
1. 需求获取的非平凡性
缺乏用户参与
题可以包括文字记录、录音、摄像等各种形式
可能会产生两份定义明确的正式文档
项目前景和范围文档用例文档
18
主要内容
1. 需求获取的非平凡性 2. 需求获取的活动过程 3. 需求获取活动的要点 4. 需求获取的实践调查情况
19
4. 需求获取的实践调查情况
实践中的需求获取活动主要关注以下几个问题：
项目目标；
项目成功的十大影响因素之一[Standish Group]
项目范围；用户参与；交流问题；获取方法的使用；
20
4. 需求获取的实践调查情况
项目范围
项目的边界定义不清晰，或者根本就没有定义项目的边界；
定义的项目边界错误，使得最终的需求不完备或者冗余；
没有控制已建立的项目边界，使得项目范围失控
用户数量太多，选择困难用户认识不足，不愿参与用户情绪抵制，消极参与没有明确的用户
对系统的用户以及用户的替代源等相关涉众进行分析
7
主要内容
1. 需求获取的非平凡性 2. 需求获取的活动过程
1. 子活动 2. 过程描述
3. 需求获取活动的要点 4. 需求获取的实践调查情况
8
2.1 需求获取的子活动
用例的结合可以推导出该用例）；用户只是在重复已经讨论过的问题；新提出的特性、需求等都在项目范围之外；新提出的需求优先级都很低；用户提出的新功能都属于后继版本，而非当
前版本
17
3.5 获取的结果
肯定会产生获取笔录（Elicitation Notes）
用户需求、问题域知识和约束可能具有组织差、冗余、遗漏、自相矛盾等诸多问
模糊的需求，要进行细化，让真正的需求显露出来。使用多种方法表达需求信息。利用不同的分析技术为相同的需求进行建模，通过分析不同的关注点，考察需求是否完整。注意检查边界值和布尔逻辑。
16
3.4 获取的过程 ——结束获取活动的判断条件
用户想不出更多的用例；用户想出的新用例都是导出用例（通过其他
问题域特性
需要注意的是不要忽略系统的环境和约束
获取的内容不是一次得到的，而是逐步积累的
12
3.2 获取的来源
涉众
用户客户
硬数据
登记表格、单据、报表等定量文档
领域专家
备忘录、日志等定性文档
市场人员、销售人员等其他用重要文档
户替代源
原有系统的规格说明
竞争产品的规格说明
1. 需求获取的非平凡性 2. 需求获取的活动过程 3. 需求获取活动的要点
1. 获取的内容 2. 获取的来源 3. 获取的方法 4. 获取的过程 5. 获取的结果
4. 需求获取的实践调查情况
11
3.1 获取的内容
在项目的范围之内所有为用户创建解决系统必须的信息
需求
通常体现为用户的观点、看法、目标或者问题
研究应用背景，建立初始的知识框架；根据获取的需要，采用必要的获取方法和技
巧；先行确定获取的内容和主题，设定场景；分析用户的高（深）层目标，理解用户的意
图；进行涉众分析，针对涉众的特点开展工作。
9
2.2 需求获取的活动过程
问题域
业务数据资料
硬数据采样样本数据
文档资料
系统环境
应用背景资料