软件工程基础(胡思康)第2章

5 案例：简历自动获取和查询系统的需求建模
6
需求评审
➢需求工程过程是一个可行性研究、需求获取、需 求分析与建模、需求评审的迭代过程。 ➢可行性研究：最初的方案阶段---确定问题是否 能够解决。其目的不是确定问题如何去解决，而 是确定问题是否值得去解〔技术可行性、操作可 行性、经济可行性、法律可行性〕。
S
软件需求工程
S
1பைடு நூலகம்
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
5 案例：简历自动获取和查询系统的需求建模
6
需求评审
➢实际工程经历说明：用户自身对将要开发的系统 也并不是完全理解，对需求目标的陈述带有主观片 面性、模糊性、不一致性，甚至还会出现错误；用 户不会把需求按照功能、性能、行为、约束等特性 对需求分门别类。
外部系统 用户
输入数据
输出数据
目标 系统
输入数据
输出数据
外部系统 用户
或
数据加工，实现数据变换。其中要注明
加工的名字。
或
外部实体，即数据源或外部系统。其中
要注明数据源或外部系统的名字。
或
数据存储。其中注明数据存储名字或编
号。
数据流，描述变换的加工数据及数据流 方向。箭头上部要注明数据流的名字。
➢如果数据加工中不同的数据流同时“流〞向一 个数据加工，或当数据加工间同时输出多条数据 流时，需要用以下图所示的图例来定义语义信息 更明确的DFD图。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。 ➢软件基线由一组软件配置项组成。当软件配置项处于稳定 状态后〔如需求文档经过评审以后〕，就确定了这组软件配 置项的基线。在后续的开发过程中，软件配置项发生变更， 那么这一变更须通过变更审查并确定，变更才能记录在软件 配置项中，并通知与之有关的人员。
软件 需求
功能 需求
性能 需求
领域 需求
其它 需求
数据 用户 时 空 操作 间 间
…
安 法律 道德 预期
… 全性 需求 需求 需求
➢描述系统提供的效劳和在特定条件下的行为。包 括系统登录、输入、响应、输出、异常等，有时 还需要特别说明系统不应该做什么。通过需求分 析，划分出系统必须完成的所有功能。 ➢完整性〔尽量得到所有用户提出的效劳〕和一致 性〔功能需求不能有相互矛盾之处〕。
基线是进展需求变更的界限。在需求分析的基线定义 之前，能够随时进展需求变更，假设在基线定义之后 变更，那么需要重新进展审查和复审。
功能是否有约束，系统如何使用更能符合用户的操作习 惯。在需求评审中，软件人员需要在用户的配合下，对 需求规格说明进展管理复审，以确保和用户对需求规格 说明的理解达成一致。
➢与软件系统有关的外在约束，如法律需求、道德 需求、外部数据交换需求、预期需求等。 ➢“简历信息自动获取系统〞 ➢随着互联网文件格式标准和企业开展的需要，对 以XML格式或企业提供的简历模版编写的简历，系 统预期将要能自动获取信息。
S
1
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
数据从哪里来〔收集过程〕，到哪里去〔存储过程〕， 系统内部如何操作和转换这些数据，如果表示数据，如 何共享数据等问题。 数据分析将数据从物理实体映射 为逻辑实体，分析逻辑数据间的连接、视图模型。
把问题域中的问题转换成信息领域 问题。构造化方法采用数据流图、 数据字典等图形工具定义。面向对 象方法采用例图、类-对像图。
➢需求工程的管理——贯穿整个需求工程的全过程。 在需求工程管理过程中存在两大难题：一是需求 确认困难；二是需求不断变更。
➢对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。 ➢软件配置的目的是确保所做的工作是可回朔的，能够恢复 原来工作的文档、代码等内容，也能跟踪目前工作结果的来 龙去脉。需要进展软件配置的内容称为软件配置项，主要有 两类：一是属于产品自身需要的内容，如开发文档、代码、 数据等；二是为软件产品效劳的内容，如进度方案、人员安 排、报告等。
➢只有运用系统的方法学，并借助需求分析提供 的方法和工具，才能把软件系统功能、性能的总 体陈述转化为具体的软件需求规格说明，奠定软 件开发的根底。
➢软件需求实际上就是准确答复“系统必须做什 么〞的问题。这一阶段还不能确定系统如何实现， 而是确定系统必须完成的任务是什么，用户操作 流程是什么顺序，系统约束条件如何规定。
➢快速原型法有两种不同类型：抛弃型原型法和演化型原型法。 ➢演化型原型法：构造一个功能简单但满足一定质量的系统原 型，通常这个原型是最终系统的核心局部，然后通过不断地 增加功能，修改原型中存在的缺乏，最后得到符合用户需求 的、高质量的软件系统。
➢快速原型法有两种不同类型：抛弃型原型法和演化型原型法。 ➢抛弃型原型法：构造一个功能简单且质量要求不高的系统原 型，针对这个原型，用户和设计人员提出意见、缺乏和错误， 形成新的需求和设计方案。据此不用原有模型而重新设计更 加完整、准确、一致、可靠的软件原型。如此往复迭代，最 终得到符合用户需求的、高质量的软件系统
➢谈话提纲 用户背景 系统背景 维护
➢分析员给用户提供标准的问卷表，帮助用户 明晰问题的主旨。 ➢P40 表2-1
➢分析员实际观察用户的手工操作过程，体验用 户在工作中所遇到的不便和困难。 ➢用户环境就是将来系统运行的场景，用户的一 次手工操作过程就是一个用例。 ➢防止场景陷阱。
➢快速原型技术的根本思想是：在系统开发时期就 让用户尽早地接触系统，对系统原型进展评估，指 出缺乏之处并提出修改意见。 ➢分析员和开发人员按照用户的需求修改原型或重 新开发原型，最终得到满足用户需求的软件系统。
通过用户对流程的描述，将有关概念和内容连接起来， 如信息、组织构造、处理规那么、操作流程等，使得对 问题的定义既有宏观描述，也有微观解释。
设计模式重用〔需求阶段考虑的重点〕和代码重用。
例如：增量开发模型中迭代过程的增量选择， 主要就是通过需求分析优先级来确定的
立即通知所有相关人员， 并积极讨论变更带来的影 响和组织新的实施方案。
所属部 门编号*
权限* 参加工 作时间* 专业*
工号* 姓名*
M
用户
N 隶属
1
部门
特长
编号* 名称*
查看
职责*
编号* 姓名*
N 简历
性别* 年龄*
特长 手机 专业*
隶属*
管理
➢数据流图〔DFD〕是构造化建模中最流行的功能 建模工具，描述从数据输入、数据转换到数据输 出的全过程。 ➢能对DFD图分层，分层的DFD更进一步刻画了系 统的功能分解。
据属性包和括属在性分间析的、关设系计和实现中 数据对象
加工规格
说明
说明
涉 是系及统的的概行念为、建术模语，、通属性等所 有 过外内部容事，件并的把触这发些，内导容定义在
致系统采取相应操作
实体关系 数据
模型
字典
数据 流图
数据字典中。围绕数据字典，
状态转换图
完成功能模型、数据模型和行
控制规格说明
为模型的构造化建模过程。
确定软件与其
他成分间的接
确定系统功能、性
口和通信
建立数据模型、
能、领域等内容
3
功能模型和行为 模型
2
4
任务
最终定义需求规格说
定义软件的使用 领域和必须满足
1
的约束
5
明书、并经过技术审 查和管理复审，用作
评价确认测试和质量
评估的依据
恰当的给用户提出 将来系统可能进展 的扩大和修改
系统中最主要、最根本的需求是功能需求。功能表达 计算机能在多大程度上辅助用户完成任务，是用户体 验中最重要的局部。
➢属性是对象的静态特征，通常是系统需求描述 中的名词。 ➢在ER模型的模型元素中，用矩形表示实体、圆 矩形表示属性、并用无向边将对象与属性相连接。
➢关系说明了数据对象间的关联关系。基数那么说 明数据对象在关系上的数量约束。 ➢关系用菱形表示，它通常是一个动词或动宾短语。 ➢三种基数关系〔1：1，1：N，M：N〕。 ➢关系也可以具有属性。
➢ 实体关系模型〔ER〕是构造化建模的可视化图 形工具，它描述数据对象〔实体〕、对象属性和 对象间关系。
➢软件系统中涉及的概念、术语、属性，或需求描述中的名词、 主谓构造短语都能作为候选数据对象。如外部实体〔电子简历 文件〕、事件〔生成各部门视图〕、事物〔简历检索结果〕、 角色〔各部门的不同用户〕、组织单位〔企业内部〕、构造 〔简历库〕等对象。这些对象分别用一组属性来定义。 ➢在构造化数据建模中，数据对象是属性的集合。而在面向对 象建模中，数据对象是属性和行为的集合，更表达了对象是动 静相结合的有机体。
6
需求评审
➢个别会谈：会谈的双方是分析员、用户以及系统 领域专家。用户提供对系统功能、性能等方面的 需求；领域专家提供系统背景知识、领域需求等 方面的知识。在这个过程中，分析员学习和掌握 系统背景知识，保证需求获取的正确性。
➢小组会议：对于系统的不同用户，由于操作流程 的不同，使用功能的不同，对软件运行环境要求 的不同，他们对系统的需求也不尽一样。小组会 议保证各方需求获取的完整性、一致性。
➢需求工程过程是一个可行性研究、需求获取、需 求分析与建模、需求评审的迭代过程。 ➢需求获取：通过获取技术〔对系统领域知识有一 定了解的前提下〕，得到用自然语言描述的问题 陈述和功能陈述。
➢需求工程过程是一个可行性研究、需求获取、需求分析与 建模、需求评审的迭代过程。 ➢需求分析与建模：以需求获取文档为根底，逐步细化需求 中的软件功能，找出系统各元素间的依赖和调用关系、接口 特性和设计上的性能约束。之后用软件开发方法提供的图形 工具，用形式化或半形式化的定义来描述初步需求。将目标 系统的物理模型转换为详细的逻辑模型，形成最终的软件需 求规格说明书和初步的用户手册。
A
*T
C
B
A
+T
C
B
A
+T
C
B
B
A
T*
C
B
A
T+
C
B
A
T+
C
➢DFD图可以用来表示任何抽象级别的系统功能，随着系统功 能和信息的逐渐增加，DFD图通过分解来逐层细化用户需求。 ➢分解步骤如下： ➢确定系统的外部信息源、数据源或与外部系统的接口。 ➢画出顶层〔0层〕DFD图。 ➢第一次精化：划分系统的子系统。 ➢逐层求精：对各子系统进一步精化。
S
1
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
5 案例：简历自动获取和查询系统的需求建模
6
需求评审
完成对功能、操作流程的抽象和分解，
完成功能建模。通过将复杂问题自顶
主要描述数据建模过
向下逐层分解，把操作流程由物理过
➢程 状构， 态造刻 ，化画 它系包分统括析的实的静体核态的心是数据。数程 解抽 和象 抽为 象逻 ，辑 最过 终程解，决完问成题对问题的分
➢需求工程过程是一个可行性研究、需求获取、需 求分析与建模、需求评审的迭代过程。 ➢需求评审：进展技术审查和管理复审，再次确保 所采纳的技术方案在技术上是可行的，在操作上 是符合用户习惯的，在经济上是有效的，在法律 上是合法的。
基
可行性分析 技术/成本分析
线
需求获取
需求分析
需求验证
需求变更
需求管理
➢简历信息自动获取和查询系统 ➢数据源：企业各部门用户； ➢数据终点：企业各部门用户〔简历查询结果的显示〕 ➢主要数据流：简历、查询信息； ➢数据存储：原始简历库、简历库； ➢主要处理过程：简历的自动获取、简历查询；
➢“简历信息自动获取系统〞 ➢根本业务功能 ➢用户管理功能 ➢数据管理功能
➢规定了软件必须满足的时间上或空间上的约束， 通常包括系统响应时间、主存容量、存储容量、 平安性、压力等方面的需求。 ➢“简历信息自动获取系统〞 ➢提取简历信息准确性的要求 ➢对系统平安性的要求 ➢对系统可靠性的要求
➢具体应用范围。 ➢“简历信息自动获取系统〞 ➢简历文本内容符合一般简历的要求，包括姓名、 年龄、专业等必要信息，否那么该简历文本会被 系统自动放弃。
数据建模需要答复以下几个问题： 系统中有哪些数据对象？ 数据对象具有哪些属性？ 数据对象间有什么关系？ 数据对象分别处于系统的哪些功能或流程中？ 在面向对象建模中，从数据对象里能抽象出更高层次的对象 吗？或者数据对象能组合吗？ 在面向对象建模中，从数据对象里能细化出更具体的数据吗？ 或者数据对象能分解吗？
➢需求获取是需求分析的前提，没有完整、正确的 获取用户需求，就不能保证软件产品质量。因此， 软件人员与用户交流需要好的方法，以便能达成 共识。
申请 需求变更
变更 描述
变更 分析
变更 修改
确认后的
变更 需求
确认
S
1
2
软件需求的基本概念 需求工程的过程
3
需求获取技术
4
结构化需求分析和建模
5 案例：简历自动获取和查询系统的需求建模