《软件工程》第三讲-需求分析-2
《软件工程》第三讲-需求分析-2
3.1 需方面的需求指定系统必须提供的服务.通过需求分析应 该划分出系统必须完成的所有功能. 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束,通常 包括速度(响应时间),信息量速率,主存容量,磁盘容量, 安全性等方面的需求.
8. 将来可能提出的要求 应该明确地列出那些虽然不属于当前系统开发范畴, 但是据分析将来很可能会提出来的要求. 这样做的目的是,在设计过程中对系统将来可能的扩 充和修改预做准备,以便一旦确实需要时能比较容易地进 行这种扩充和修改. 用户或人的因素 用户类型? 各种用户熟练程度? 需受何种训练? 用户理解,使用系统的难度? 用户错误操作系统的可能性?
3.3 分析建模与规格说明
为了更好地理解复杂事物,人们常常采用建立 事物模型的方法. 所谓模型,就是为了理解事物而对事物做出的 一种抽象,是对事物的一种无歧义的书面描述. 通常,模型由一组图形符号和组织这些符号的 规则组成.
结构化分析实质上是一种创建模型的活动. 系统分析员应该从不同角度抽象出目标系统的特 性,使用精确的表示方法构造系统的模型,验证模型 是否满足用户对目标系统的需求,并在设计过程中, 逐渐把和实现有关的细节加进模型中,直至最终用程 序实现模型. 需求分析过程应该建立3种模型,它们分别是 3 数据模型, 功能模型, 行为模型. ERD实体-联系图 DFD数据流图 STD状态转换图
3.1.2 分析系统的数据要求
任何一个软件系统本质上都是信息处理系统,系统必须处 理的信息和系统应该产生的信息,在很大程度上决定了系 统的面貌,对软件设计有深远影响. 因此,必须分析系统的数据要求,这是软件需求分析的一 个重要任务. 分析系统的数据要求,通常采用建立数据模型的方法(见3.4 节).
3. 可靠性和可用性需求 可靠性需求定量地指定系统的可靠性. 可用性与可靠性密切相关,它量化了用户可以使用系统的 程度. 4. 出错处理需求 这类需求说明系统对环境错误应该怎样响应.例如,如果 它接收到从另一个系统发来的违反协议格式的消息,应该 做什么? 注意,上述这类错误并不是由该应用系统本身造成的.在 某些情况下,"出错处理"指的是当应用系统发现它自己 犯下一个错误时所采取的行动.但是,应该有选择地提出 这类出错处理需求.我们的目的是开发出正确的系统,而 不是用无休止的出错处理代码掩盖自己的错误.总之,对 应用系统本身错误的检测应该仅限于系统的关键部分,而 且应该尽可能少.
软件工程 03_需求分析
用例名称 用例编号
包 维护者
版本 简介 参与的角色
业务支持者
引用
2020/1/8
1 简短精炼的描述，一般为动宾短语的形式。
1 项目中唯一确定的数字编号。
在较复杂的系统中，用例被划归为不同的业务子系
2 统，可以使用UML的包进行封装。在用例识别过
程中可以确定用例归属的包。
1 创建和维护该用例的人员。
1
– 如，询问客户公司销售的商品种 类、雇用的销售人员数目以及信 息反馈时间应该多快等。
2020/1/8
– 在非正式的访谈中，将提 出一些可以自由回答的开 放性问题，以鼓励被访问 的人员表达自己的想法， 例如，询问用户为什么对 目前正在使用的系统感到 不满意。
14
用例（Use case）
• 使用一种交互的方式来描述系统 的场景，借以“捕获”用户的需 求。
2020/1/8
26
扩展关系与包含关系
• 一般来说被包含用例属于无条件发生的用 例，而扩展用例属于有条件发生的用例；
• 被包含用例提供的是间接服务，扩展用例 提供的是直接服务；
项目部 项目经理 质量保证
项目结构编辑
人力资源部
项目组组建
项目状态分析
项目成员
• 用例使用椭圆表示， 代表用户任务
员工数据维护
• 任务对应的涉众，用 例直接或间接与人形
符号（Stickman）关 联，叫做Actor。
• Actor理解成角色
工作状态更新
（Role）会更合适一
些，指使用系统的用
户类，不特指具体人。
– 每个这样的数据利用，都会导致新的用例的产生。
– “项目状态分析”用例需要将进行中的项目数据做严 格的分析和评估，并可能形成项目延期的结论。
软件工程v3_课件_03_需求分析_
正常使用主观题需2.0以上版本雨课堂
作答
主观题 10分
2.为方便旅客，某航空公司拟开发一个机票预订 系统。旅行社把预订机票的旅客信息（姓名、性 别、工作单位、身份证号码、旅行时间、旅行目 的地等）输入进该系统，系统为旅客安排航班， 印出取票通知和账单，旅客在飞机起飞的前一天 凭取票通知和账单交款取票，系统校对无误即印 出机票给旅客。请绘制该系统的ER图。
3.2 与用户沟通获获取需求的方法
面向数据流自顶向下求精 3.数据流分析的结果 • 清晰地定义了可实际操作的个数据元素； • 明确地展现了数据的来源与去处； • 初步描绘了数据处理的可能算法（方法）。 4.数据流描述方法 • 数据流图：数据及其处理关系 • 数据字典：数据元素 • IPO图：处理算法
可靠性Reliability：系统失效时间间隔的描述，以发生的失 效个数为驱动 可用性Availability：系统可供使用时间的描述，以丢失的 时间为驱动 4. 出错处理需求：如何响应环境错误 5. 接口需求：与环境通信的格式 6. 约束：应遵守的限制条件，精度、工具、标准、硬件平台 7. 逆向需求：不应该做什么 8. 未来的需求：不属于当前系统的开发范畴
析重要性
① 数据决定了需要的处理和算法，数据是需求分析的出 发点
② 信息系统的基本模型：输入数据 数据处理 输出数 据
③ 数据在流动中被处理，数据决定了处理所需的算法
3.2 与用户沟通获获取需求的方法
面向数据流自顶向下求精 1.基于数据流图的结构化分析方法 ① 结构化分析方法就是面向数据流自顶向下逐步求精进 行需求分析的方法
需求分析的原则
基本原则 P56 尽管目前有许多不同的用于需求 分析的结构化分析方法，但是所有 这些方法都遵循下述原则
软件工程03-需求分析
软件工程03.需求分析软件工程03.需求分析1.引言1.1 编写目的本文档旨在对软件需求进行详细的分析和描述，以便为软件开发团队提供明确的指导，确保软件开发过程中有一个清晰的方向和目标。
1.2 读者对象本文档的主要读者对象为软件开发团队成员、项目经理和相关利益相关者，包括技术和非技术人员。
1.3 背景在软件工程开发过程中，需求分析阶段是非常重要的一环。
通过对用户需求进行分析和整理，可以确保开发的软件具有良好的功能和性能，并满足用户的期望。
2.需求概述2.1 业务需求在这个章节中，我们将对软件开发项目的业务需求进行详细的描述。
包括用户需求、功能需求和性能需求等。
2.2 用户需求在这个章节中，我们将详细描述用户对软件的期望和需求。
例如，用户希望软件能够提供什么功能，以及对用户界面的要求等。
2.3 功能需求在这个章节中，我们将详细描述软件需要实现的各个功能。
每个功能需求都应该具有明确的描述，包括输入、处理和输出等。
2.4 性能需求在这个章节中，我们将详细描述软件在性能方面的要求。
例如，软件需要支持多少用户同时使用，响应时间要求等。
3.系统规约3.1 功能性规约在这个章节中，我们将详细描述软件系统的功能性规约。
例如，软件的总体结构和各个模块之间的关系等。
3.2 可靠性规约在这个章节中，我们将详细描述软件系统的可靠性规约。
例如，软件需要具备多少的可用性和可靠性等。
3.3 可维护性规约在这个章节中，我们将详细描述软件系统的可维护性规约。
例如，软件需要能够方便地进行维护和更新等。
4.接口需求4.1 用户界面在这个章节中，我们将详细描述软件的用户界面设计。
包括界面的布局、颜色和字体等。
4.2 硬件接口在这个章节中，我们将详细描述软件与硬件之间的接口要求。
例如，软件需要与某些特定的硬件设备进行通信等。
4.3 软件接口在这个章节中，我们将详细描述软件与其他软件之间的接口要求。
例如，软件需要与某些特定的软件进行数据交换等。
软件工程第三章(需求分析)
需求分析概述
准确地定义未来系统的目标，确定为了 满足用户的需求,系统必须做什么。用 <需求 规格说明书> 规范的形式准确地表达用户的 需求。
在需求分析阶段，系统分析员的主要焦 点是 “做什么（what）” ，不是 “怎样做 （how）”
下面是一组漫画 这组漫画形象地刻画了一个事实 获取完整正确的需求是一项十分困难的工 作
➢数学模型 ➢描述模型 ➢图形模型
三、模型的作用
• 在建模过程中了解系统 • 通过抽象降低复杂性 • 有助于回忆所有的细节 • 有助于开发小组间的交流 • 有助于与用户的交流 • 为系统的维护提供文档
3.3.2需求分析的过程
(1) 通过对现实环境的调查， 获得当前系统的物理模型
购
学
书 申 请
教务科
某出版社系统调查表
编
提出问题
号
1 您在哪个部门工作？
2 出版业务流程是什么？
3 您每日都处理那些文件、数据、报表？
4 工作中手工处理特别麻烦的事情是什么？
5 工作中手工处理什么问题解决不了？影响 效率的问题有哪些？
6 您认为提高工作效率，节省工作时间，减 轻工作强度可采取哪些办法？
某出版社系统调查表
设计约束或实现约束描述在设计或实现应用 系统时应遵守的限制条件。常见的约束有： 精度；工具和语言约束；设计约束；应该使 用的标准；应该使用的硬件平台。
7. 逆向需求 逆向需求说明软件系统不应该做什么。
8. 将来可能提出的要求
应该明确地列出那些虽然不属于当前系统开 发范畴，但是据分析将来很可能会提出来的 要求。
•关于系统将要完成什么工作…：需求描述了 系统应当完成的任务，不描述系统将如何实现。
软件工程之第3章-需求分析(第五版)(张海潘编著)精品PPT课件
3.2 与用户沟通获取需求的方法
访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件原型
需求的获取
需求获取是开发人员与客户或用户一起对应用领 域进行调查研究，收集系统需求的过程
层次的方法展示细节。
3.1 需求分析的任务
确定对系统的综合要求
---功能需求、性能需求、可靠性和可用性需求、出错处理需求、 接口需求、约束、 逆向需求、将来可能提出的要求。
分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划
3.1.1 确定对系统的综合要求
1. 功能需求 2. 性能需求 3. 可靠性和可用性需求 4. 出错处理需求 5. 接口需求 6. 约束 7. 逆向需求 8. 将来可能提出的要求
确定系统必须完成哪些工作，也就是对目标系 统提出完整、准确、清晰、具体的要求。
系统分析员应该写出软件需求规格说明书，以 书面形式准确地描述软件需求。
需求：正在构建的系统必须符合的事务。
需求管理：是一种获取、组织并记录系统需求 的系统化方案以及一个使客户与项目团队不断 变更的系统需求达成并保持一致的过程。
第四代技术特点：
简单易学，用户界面良好，面向问题、非过程化程度 高，用户只需告知系统做什么，而无需说明怎么做。 用4GL编程使用的代码量较少，并可成数量级地提高 软件生产率。
程序设计语言划代：
1GL是汇编语言；
2GL是高级程序设计语言，如FORTRAN，ALGOL， BASIC，LISP等；
术性的转换
功能范围更广，
现代
全过程的，注 重整个产品过 程的全部
软件工程第三章 软件需求分析 PPT课件
生
审查 有效性
开领 书单
书
学 生
学生购买教材的逻辑模型
需求分析过程示意
(3) 分析当前系统与目标系统的差别， 建立目标系统的逻辑模型
无效书单
学 购书单 审查并 发票 领书单 开领
生
开发票
书单
学 生
计算机售书系统的逻辑模型
需求分析过程示意
对象 系统
抽象（映射） 模型应用
模型 系统
模型构造的过程
逻辑模型 (本质模型、概念模型)
物理模型 (实施模型、技术模型)
现 行 系 统
描述重要的业务 功能，无论系统 是如何实施的。
描述现实系统是 如何在物理上实 现的。 描述新系统是如 何实施的（包括 技术）。
目 标 系 统
描述新系统的主要 业务功能和用户新 的需求，无论系统 应如何实施。
接收、发送数据的频率？
数据的准确性和精度？ 数据流量？ 数据需保持的时间？
(8)
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
需对访问系统或系统信息
加以控制吗？ 如何隔离用户之间的数据？ 用户程序如何与其它程序 和操作系统隔离？ 系统备份要求？
(1)
功能需求
系统做什么？
系统何时做什么？
系统何时及如何修改
或升级？
(2)
性能需求
软件开发的技术性指标：
存储容量限制 执行速度、相应时间 吞吐量
(3)
环境需求
软件工程03-需求分析
软件工程03-需求分析1、介绍在软件工程中，需求分析是一个关键的阶段，它旨在理解用户需求并确定一个系统或软件的功能和非功能需求。
本文档旨在详细描述需求分析的过程和结果。
2、项目概述在本章节中，将介绍项目的目标、范围和背景信息。
提供项目的背景和目的，明确软件需求分析的上下文。
3、用户需求描述主要用户群体，分析他们的需求和期望。
可能包括用户故事、使用案例或用户需求文档。
4、系统功能需求在本章节中列出系统的所有功能需求。
可以使用功能需求文档、使用案例或其他方法来详细描述每个功能需求。
5、系统性能需求描述系统的性能要求，如响应时间、吞吐量和容量要求等。
6、可靠性需求明确系统的可靠性要求，包括系统的可用性、可靠性、容错性等。
7、安全需求描述系统的安全要求，包括数据安全、身份验证和访问控制等。
8、可维护性需求说明系统的可维护性要求，如可扩展性、可修改性和易于测试等。
9、可移植性需求描述系统的可移植性要求，如平台的兼容性、系统的可移植性和可配置性等。
10、界面需求描述系统与用户、硬件和其他软件之间的交互。
包括用户界面设计、硬件接口和软件接口等。
11、数据需求描述系统需要存储、处理和管理的数据。
包括数据结构、数据库和数据流等。
12、非功能需求在本章节中描述其他非功能需求，如易用性、可访问性和可靠性等。
13、附录列出本文档所涉及的附件，如用户调研报告、需求变更记录和用户界面设计图等。
14、法律名词及注释本节包含文档中涉及的法律名词的解释和注释。
软件工程03-需求分析
软件工程03-需求分析需求分析是软件工程的一个重要阶段，它是在软件开发过程中进行的，旨在确定软件系统应具备的功能和性能要求。
本文将介绍需求分析的定义、目的、过程以及常见的需求分析方法。
1. 需求分析的定义需求分析是指对软件系统的需求进行识别、理解、描述和规范的过程。
它包括获取用户需求、分析需求、验证需求和管理需求等活动，通过系统化的方法，将用户的期望转化为可执行的软件需求。
2. 需求分析的目的需求分析的主要目的是为了确保软件系统的功能和性能要求得到满足。
它帮助开发团队深入了解用户需求，准确把握用户需求，避免功能冲突和需求错误，提高软件系统的可靠性和用户满意度。
3. 需求分析的过程需求分析的过程可以分为以下几个步骤：3.1. 需求获取需求获取是指通过与用户交流、观察和调查等方式，获取用户对软件系统的需求。
这个过程中需要与用户进行沟通，了解用户的期望、需求和约束，收集用户的需求文档和相关的资料。
3.2. 需求分析与建模需求分析与建模是在需求获取的基础上，对需求进行进一步的分析和建模。
这个过程中需要对需求进行分类、归纳、整理和整合，并利用建模工具进行需求建模，如用例图、活动图、类图等。
3.3. 需求验证需求验证是指对已经分析和建模的需求进行验证，确保需求的正确性、完整性和一致性。
这个过程中可以通过与用户和开发团队的沟通，进行需求评审和需求验证测试等方式，发现和解决需求中的问题。
3.4. 需求管理需求管理是指对需求进行统一的管理和控制，确保需求的变更和追踪能够有效进行。
这个过程中需要建立需求的变更控制机制，记录需求的变更历史和状态，并及时通知相关人员进行处理。
4. 常见的需求分析方法需求分析有许多不同的方法和技术，下面介绍几种常见的需求分析方法：4.1. 用例分析法用例分析法是一种基于用户故事的需求分析方法，通过描述用户使用软件系统的场景来识别和描述需求。
4.2. 面向对象分析法面向对象分析法是一种利用面向对象的概念和方法对需求进行分析和建模的方法，通过识别和定义对象、类和关系来描述需求。
《软件工程学》第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 需求分析图形工具。
软件工程 第三课 需求分析
活动表的语法格式如下：
事件名（参数表）/动作表达式
其中，事迹名可以是任何事件的名称，在活动 表中常使用3种标准事件：entry\exit\do,而entry 事件表示进入该状态的动作， exit事件表示退出 该状态的动作，do事件表示在该状态下的动作， 需要时可以为事迹指定参数表，活动表中的动 作表达式描述做的具体动作。它是一个过程表 达式，当状态转换开始时执行该表达式。
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外，还应该 写出软件需求规格说明书，它是需求分析阶段 得出的最主要的文档。 通常用自然语言完整、准确、具体地描述系统 的数据要求、功能需求、性能需求、可靠性和 可用性要求、出错处理需求、接口需求、约束、 逆向需求以及将来可能提出的要求。自然语言 的规格说明具有容易书写、容易理解的优点， 为大多数人所欢迎和采用。
3.1 需求分析的任务 进一步了解确定用户需求。准确地回答 “系统必 须做什么？” 的问题。对目标系统提出完整、准 确、清晰、具体的要求。获得需求规格说明书。 需求分析的具体任务:
需求分析阶段的任务：在可行性分析的基础上，
1、确定系统的综合要求
系统功能要求—这是最主要的需求，确定系 统必须完成的所有功能。
约束—描述在设计或实现应用系统时应遵守的 限制条件，常见的约束有精度 、工具和语言约 束、使用的标准、使用的硬件平台。 逆向需求—逆向需求说明软件系统不应该做什么 需求。 将来可能提出的要求—对将来可能提出的扩充及 修改作预准备。
2、分析系统的数据要求 软件系统本质上是信息处理系统，因此， 必须分析系统的数据要求，这是软件需求分析的 一个重要任务。分析系统的数据要求通常采用建 立数据模型的方法。必须考虑： 数据 （需要哪些数据、数据间联系、数据性 质、结构） 数据处理 （处理的类型、处理的逻辑功能）
软件工程的需求分析(二)
软件工程的需求分析（二）引言概述：需求分析是软件工程中的重要阶段之一，它旨在准确理解用户的需求并将其转化为可行的系统需求。
本文将继续探讨软件工程的需求分析，包括以下五个大点：需求获取、需求分析方法、需求验证与确认、需求文档编写和需求管理。
正文内容：1. 需求获取a. 用户需求调研与采集：通过与用户的沟通和观察，了解他们对软件系统的期望和需求。
b. 需求分解与整理：将获取到的需求进行分解和整理，将复杂的需求拆解成可管理的小块。
2. 需求分析方法a. 面向对象分析：通过识别系统中的对象、属性和行为来定义软件需求。
b. 数据流图分析：通过绘制数据流图来描述信息在系统中的流动和处理。
c. 数据字典分析：使用数据字典来定义和描述系统中的数据元素和数据关系。
d. 基于用例的分析：通过分析典型用户场景和用例来定义需求，重点在于系统与用户之间的交互和功能。
3. 需求验证与确认a. 原型验证：通过创建原型来验证需求的正确性和完整性，及时发现并修正潜在的问题。
b. 需求评审：邀请相关利益相关者对需求进行评审，确保需求符合系统目标和用户期望。
c. 需求确认：与用户进行确认，确保需求准确完整，并取得用户的认可和支持。
4. 需求文档编写a. 需求规格说明书：详细描述系统的功能、性能和约束条件，并提供相关的用例和用户故事。
b. 需求追踪矩阵：记录需求和设计之间的关联关系，便于跟踪和管理需求的实现情况。
c. 需求优先级排序：根据需求的重要性和紧急程度进行排序，确保开发按照优先级进行。
5. 需求管理a. 需求变更管理：建立一个变更控制过程，确保需求变更的审批和跟踪。
b. 需求跟踪和追踪：追踪需求的实现和修改情况，确保开发过程与需求保持一致。
c. 需求版本控制：管理需求的版本，确保只有经过授权的变更才会被实施。
总结：需求分析是软件工程中至关重要的步骤，它确保了软件系统可以满足用户的期望和需求。
通过需求获取、需求分析方法的选择、需求验证与确认、需求文档编写和需求管理，可以有效地进行软件需求分析，并为后续的软件开发过程提供准确的指导和参考。
《软件工程导论》第3章需求分析ppt课件
包括完善的数据流图、实体－联系图、状态转换图、 数据字典、主要的处理算法（IPO图）等。
3.1.4 修正系统开发计划
修订前期制定的开发进度计划、等。
3.2 与用户沟通获取需求的方法
3.2.1 访谈
正式访谈：系统分析员提出事先准备好的问题。 非正式访谈：提出一些用户可以自由回答的开放性问
题，鼓励被访者说出自己的想法。 需要访问大量人员时，利用调查表访问较佳。 情景分析技术：对用户将来使用目标系统解决某个具
体问题的方法和结果进行分析。
3.2.2 面向数据流自顶向下求精
借助数据流图、数据字典、IPO图等，细化、完善详
细的数据流图，等到各处理环节对应的功能。
需要分解
有补充修正
分析追踪数 据流图
3.6.2 事件
事件是某个特定时刻发生的事情，它是引起系
统做动作或状态转换的控制信息。 3.6.3 符号 初态：实心圆 终态：同心圆（内圆为实心园） 中间态：圆角矩形，分为上、中、下三部分
状态名称 状态变量 活动表
状态变量的名字和值 事件名（参数表）/动作表达式 标准事件：entry, exit, do
1.引言
1.1 目的 1.2 文档的约定 1.3 预期的读者和阅读建议 1.4 产品的范围 1.5 参考文献
2. 综合描述
2.1 产品的远景 2.2 产品的功能 2.3 用户类和特性 2.4 运行环境 2.5 设计和实现的限制
需求规格说明书
3. 外部接口
3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通信接口
用户接口、硬件接口、软件接口、通信接口、等。 6. 约束
精度、工具和语言、设计约束、硬件约束、标准，等。 7. 逆向需求 ：软件系统不应该做什么 8. 将来可能提出的要求 ：为将来的修改和扩充做准备。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3.3.2 软件需求规格说明
通过需求分析除了创建分析模型之外,还应该写出软件 需求规格说明书,它是需求分析阶段得出的最主要的文档. 通常用自然语言完整,准确,具体地描述系统的数据要 求,功能需求,性能需求,可靠性和可用性要求,出错处理 需求,接口需求,约束,逆向需求以及将来可能提出的要求. 自然语言的规格说明具有容易书写,容易理解的优点,为大 多数人所欢迎和采用.
第三章 需求分析(II)
结构化分析方法都遵守下述准则 准则: 结构化分析 准则 (1) 必须理解并描述问题的信息域,根据这条准则应 该建立数据模型. (2) 必须定义软件应完成的功能,这条准则要求建立 功能模型. (3) 必须描述作为外部事件结果的软件行为,这条准 则要求建立行为模型. (4) 必须对描述信息,功能和行为的模型进行分解, 用层次的方式展示细节.
3.1.3 导出系统的逻辑模型
综合上述两项分析的结果 可以导出系统的详细的逻辑模型, 通常用
数据流图, 实体-联系图, 状态转换图, 数据字典和主要的处理算法
描述这个逻辑模型.
3.1.4 修正系统开发计划
最早在什么时候制定过开发计划? 根据在分析过程中,获得的对系统的更深入更具体的了解, 可以比较准确地估计系统的成本和进度,修正以前制定的 开发计划.
情景分析技术 对用户将来使用目标系统,解决某个具体问题的方法和结 果进行分析. 用处主要体现在下述两个方面: (1) 它能在某种程度上演示目标系统的行为,从而便于用户 理解,而且还可能进一步揭示出一些分析员目前还不知道 的需求. (2) 由于情景分析较易为用户所理解,使用这种技术能保证 用户在需求分析过程中始终扮演一个积极主动的角色.需 求分析的目标是获知用户的真实需求,而这一信息的惟一 来源是用户,因此,让用户起积极主动的作用对需求分析 工作获得成功是至关重要的.
3.4 实体-联系图
数据模型 为了把用户的数据要求清楚,准确地描述出来,系统分析 员通常建立一个概念性的数据模型(也称为信息模型). 概念性数据模型是一种面向问题的数据模型,是按照用户 的观点对数据建立的模型.它描述了从用户角度看到的数 据,它反映了用户的现实环境,而且与在软件系统中的实 现方法无关. 数据模型中包含3种相互关联的信息:数据对象,数据对象 的属性及数据对象彼此间相互连接的关系.
3.2.1 访谈
访谈是最早开始使用的获取用户需求的技术,也 是迄今为止仍然广泛使用的需求分析技术. 正式访谈时,系统分析员将提出一些事先准备好 的具体问题. 在非正式访谈中,分析员将提出一些用户可以自 由回答的开放性问题,以鼓励被访问人员说出自 己的想法.
调查表 当需要调查大量人员的意见时,向被调查人分发调 查表是一个十分有效的做法.经过仔细考虑写出的 书面回答可能比被访者对问题的口头回答更准确. 分析员仔细阅读收回的调查表,然后再有针对性地 访问一些用户,以便向他们询问在分析调查表时发 现的新问题. 情景分析 在访问用户的过程中使用情景分析技术往往非常有 效.所谓情景分析就是对用户将来使用目标系统解 决某个具体问题的方法和结果进行分析.
3.1 需求分析的任务
3.1.1 确定对系统的综合要求
1. 功能需求 这方面的需求指定系统必须提供的服务.通过需求分析应 该划分出系统必须完成的所有功能. 2. 性能需求 性能需求指定系统必须满足的定时约束或容量约束,通常 包括速度(响应时间),信息量速率,主存容量,磁盘容量, 安全性等方面的需求.
3.2.4 快速建立软件原型
正如第1章已经讲过的,快速建立软件原型是最准确,最有 效,最强大的需求分析技术. 快速原型就是快速建立起来的,旨在演示目标系统主要功 能的可运行的程序. 构建原型的要点是,它应该实现用户看得见的功能(例如, 屏幕显示或打印报表),省略目标系统的"隐含"功能(例如, 修改文件). 尽快向用户提供一个可在计算机上运行的目标系统的模型, 以便使用户和开发者在目标系统应该"做什么"这个问题 上尽可能快地达成共识.因此,原型的某些缺陷是可以忽 略的,只要这些缺陷不严重地损害原型的功能,不会使用 户对产品的行为产生误解,就不必管它们.
3.3 分析建模与规格说明
为了更好地理解复杂事物,人们常常采用建立 事物模型的方法. 所谓模型,就是为了理解事物而对事物做出的 一种抽象,是对事物的一种无歧义的书面描述. 通常,模型由一组图形符号和组织这些符号的 规则组成.
结构化分析实质上是一种创建模型的活动. 系统分析员应该从不同角度抽象出目标系统的特 性,使用精确的表示方法构造系统的模型,验证模型 是否满足用户对目标系统的需求,并在设计过程中, 逐渐把和实现有关的细节加进模型中,直至最终用程 序实现模型. 需求分析过程应该建立3种模型,它们分别是 3 数据模型, 功能模型, 行为模型. ERD实体-联系图 DFD数据流图 STD状态转换图
信息收集中的主要问题
复查报表,表格和过程描述
商业文档和过程描述是了解过程的一个好方法. 表格和报表可以为面谈提供可视化的帮助,也可以 提供工作文档. 复查现有过程文档,将有助于识别面谈中不会提及 的商业规则. 有助于发现商业过程中的不一致和冗余.
面谈
面谈之前 确立面谈目的 确定要包括的相关用户 确定参加会议的项目小 组成员 建立要讨论的问题和要 点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关会 议的目的,时间和地点 进行面谈 衣着得体 准时到达 寻找异常和错 误情况 深入调查细节 详细记录 找出和记录未 回答的条目和未 解决的问题 面谈之后 复查笔记的准确性, 完整性和可理解性 把所收集的信息转 化为适当的模型和文 档 确定需要进一步澄 清的问题域 适当的时间向参加 会议的每一个人发一 封感谢信
第3章 需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 3.5 数据规范化 3.6 状态转换图 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
目标
列举信息收集技术技巧 设计项目的E-R图 设计项目的状态转换图 了解其他图形工具
图3.1 面向数据流自顶向下求精过程
3.2.3 简易的应用规格说明技术
前面方法定义需求时,用户处于被动地位而且往往有意 无意地与开发者区分"彼此".由于不能像同一个团队的人 那样齐心协力地识别和精化需求,这两种方法的效果有时并 不理想. 为了解决上述问题,人们研究出一种面向团队的需求收 集法,称为简易的应用规格说明技术. 这种方法提倡用户与开发者密切合作,共同标识问题, 提出解决方案要素,商讨不同方案并指定基本需求.
复杂的数据由许多基本的数据元素组成,数据结构表示数 据元素之间的逻辑关系. 利用数据字典可以全面准确地定义数据,但是数据字典的 缺点是不够形象直观. 为了提高可理解性,常常利用图形工具辅助描绘数据结构. 常用的图形工具有层次方框图和Warnier图,在本章第3.7节 中将简要地介绍这两种图形工具. 软件系统经常使用各种长期保存的信息,这些信息通常以 一定方式组织并存储在数据库或文件中,为减少数据冗余, 避免出现插入异常或删除异常,简化修改数据的过程,通 常需要把数据结构规范化(见3.5节).
快速地构建和修改原型方法和工具:
(1) 第四代技术 (2) 可重用的软件构件 (3) 形式化规格说明和原型环境
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明
3.4 3.5 3.6 3.7 实体-联系图 数据规范化 状态转换图 其他图形工具
3.8 验证软件需求 3.9 小结
3.1.2 分析系统的数据要求
任何一个软件系统本质上都是信息处理系统,系统必须处 理的信息和系统应该产生的信息,在很大程度上决定了系 统的面貌,对软件设计有深远影响. 因此,必须分析系统的数据要求,这是软件需求分析的一 个重要任务. 分析系统的数据要求,通常采用建立数据模型的方法(见3.4 节).
5. 接口需求 接口需求描述应用系统与它的环境通信的格式.常见的接 口需求有:用户接口需求;硬件接口需求;软件接口需求; 通信接口需求. 6. 约束 设计约束或实现约束描述在设计或实现应用系统时应遵守 的限制条件.在需求分析阶段提出这类需求,并不是要取 代设计(或实现)过程,只是说明用户或环境强加给项目的限 制条件.常见的约束有:精度;工具和语言约束;设计约 束;应该使用的标准;应该使用的硬件平台. 7. 逆向需求 逆向需求说明软件系统不应该做什么.理论上有无限多个 逆向需求,我们应该仅选取能澄清真实需求且可消除可能 发生的误解的那些逆向需求.
ERD的概念
联系可分为以下3种类型: (1) 一对门与经理的联系是一对一的. (2) 一对多联系(1:N) 例如,某校教师与课程之间存在一对多的联系"教",即每 位教师可以教多门课程,但是每门课程只能由一位教师来教. (3) 多对多联系(M:N) 例如,学生与课程间的联系("学")是多对多的,即一个学生 可以学多门课程,而每门课程可以有多个学生来学.
ERD的概念
实体: 指客观世界存在的且可以相互区分的事务.实体可以 是人,也可以是物,还可以是抽象概念.如职工,计算机, 产品等都是实体. 属性: 是指实体某一方面的特征.一个实体通常由多个属性 值组成,如学生实体具有学号,姓名,专业,年级等属性. 联系: 指实体之间的相互关系. 注意,联系也可以有属性.
3.2.2 面向数据流自顶向下求精
软件系统本质上是信息处理系统,而任何信息处理系统的 基本功能,都是把输入数据转变成需要的输出信息. 数据决定了需要的处理和算法,看来数据显然是需求分析 的出发点.在可行性研究阶段许多实际的数据元素被忽略 了,当时分析员还不需要考虑这些细节,现在是定义这些 数据元素的时候了. 通过可行性研究已经得出了目标系统的高层数据流图,需 求分析的目标之一就是把数据流和数据存储定义到元素级. 为了达到这个目标,通常从数据流图的输出端着手分析, 这是因为系统的基本功能是产生这些输出,输出数据决定 了系统必须具有的最基本的组成元素.