软件工程基础第2章课件

需求工程过程是一个可行性研究、需求获取、需
求分析与建模、需求评审的迭代过程。
需求评审：进行技术审查和管理复审，再次
确保所采纳的技术方案在技术上是可行的，在
Байду номын сангаас
操作上是符合用户习惯的，在经济上是有效的，
在法律上是合法的。
可行性分析
技术/成本分析
基 线
需求获取
需求分析
需求验证
需求变更
需求管理
需求工程的管理——贯穿整个需求工程的全过程。
把问题域中的问题转换成信息领域 问题。结构化方法采用数据流图、 数据字典等图形工具定义。面向对 象方法采用例图、类-对像图。
基线是进行需求变更的界线。在需求分析的基线定义 之前，能够随时进行需求变更，若在基线定义之后变 更，则需要重新进行审查和复审。
功能是否有约束，系统如何使用更能符合用户的操作习 惯。在需求评审中，软件人员需要在用户的配合下，对 需求规格说明进行管理复审，以确保和用户对需求规格 说明的理解达成一致。
S
软件需求工程
S
1
2 3 4
软件需求的基本概念
需求工程的过程 需求获取技术 结构化需求分析和建模 案例：简历自动获取和查询系统的需求建模 需求评审
5
6
实际项目经验表明：用户自身对将要开发的系统
也并不是完全理解，对需求目标的陈述带有主观片
面性、模糊性、不一致性，甚至还会出现错误；用
户不会把需求按照功能、性能、行为、约束等特性
代码、数据等；二是为软件产品服务的内容，如进度计划、
人员安排、报告等。
对传统的需求变更管理过程来说，主要包括软件配置、软 件基线和变更审查。
软件基线由一组软件配置项组成。当软件配置项处于稳
定状态后（如需求文档经过评审以后），就确定了这组软 件配置项的基线。在后续的开发过程中，软件配置项发生 变更，则这一变更须通过变更审查并确定，变更才能记录 在软件配置项中，并通知与之有关的人员。
通过用户对流程的描述，将有关概念和内容连接起来， 如信息、组织结构、处理规则、操作流程等，使得对问 题的定义既有宏观描述，也有微观解释。
设计模式重用（需求阶段考虑的重点）和代码重用。
例如：增量开发模型中迭代过程的增量选择， 主要就是通过需求分析优先级来确定的
立即通知所有相关人员， 并积极讨论变更带来的影 响和组织新的实施方案。
性（功能需求不能有相互矛盾之处）。
“简历信息自动获取系统”
基本业务功能
用户管理功能
数据管理功能
规定了软件必须满足的时间上或空间上的约束，
通常包括系统响应时间、主存容量、存储容量、
安全性、压力等方面的需求。
“简历信息自动获取系统” 提取简历信息准确性的要求 对系统安全性的要求 对系统可靠性的要求
对需求分门别类。
只有运用系统的方法学，并借助需求分析提供
的方法和工具，才能把软件系统功能、性能的总
体陈述转化为具体的软件需求规格说明，奠定软
件开发的基础。
软件需求实际上就是准确回答“系统必须做什
么”的问题。这一阶段还不能确定系统如何实现，
而是确定系统必须完成的任务是什么，用户操作
流程是什么顺序，系统约束条件如何规定。
具体应用范围。
“简历信息自动获取系统”
简历文本内容符合一般简历的要求，包括姓
名、年龄、专业等必要信息，否则该简历文
本会被系统自动放弃。
与软件系统有关的外在约束，如法律需求、道德
需求、外部数据交换需求、预期需求等。
“简历信息自动获取系统”
随着互联网文件格式标准和企业发展的需要，
对以XML格式或企业提供的简历模版编写的简
而是确定问题是否值得去解（技术可行性、操
作可行性、经济可行性、法律可行性）。
需求工程过程是一个可行性研究、需求获取、需
求分析与建模、需求评审的迭代过程。
需求获取：通过获取技术（对系统领域知识
有一定了解的前提下），得到用自然语言描述
的问题陈述和功能陈述。
需求工程过程是一个可行性研究、需求获取、需求分析与
历，系统预期将要能自动获取信息。
S
1
2 3 4
软件需求的基本概念
需求工程的过程 需求获取技术 结构化需求分析和建模 案例：简历自动获取和查询系统的需求建模 需求评审
5
6
需求工程过程是一个可行性研究、需求获取、需
求分析与建模、需求评审的迭代过程。
可行性研究：最初的计划阶段---确定问题是
否能够解决。其目的不是确定问题如何去解决，
在需求工程管理过程中存在两大难题：一是需求
确认困难；二是需求不断变更。
对传统的需求变更管理过程来说，主要包括软件配置、软
件基线和变更审查。
软件配置的目的是确保所做的工作是可回朔的，能够恢 复原来工作的文档、代码等内容，也能跟踪目前工作结果 的来龙去脉。需要进行软件配置的内容称为软件配置项， 主要有两类：一是属于产品自身需要的内容，如开发文档、
建模、需求评审的迭代过程。 需求分析与建模：以需求获取文档为基础，逐步细化需 求中的软件功能，找出系统各元素间的依赖和调用关系、 接口特性和设计上的性能约束。之后用软件开发方法提供 的图形工具，用形式化或半形式化的定义来描述初步需求。 将目标系统的物理模型转换为详细的逻辑模型，形成最终 的软件需求规格说明书和初步的用户手册。
确定系统功能、性 能、领域等内容
确定软件与其 他成分间的接 口和通信
3 2 任务 1 4 5
建立数据模型、 功能模型和行为 模型
定义软件的使用 领域和必须满足 的约束
最终定义需求规格说 明书、并经过技术审 查和管理复审，用作 评价确认测试和质量 评估的依据
恰当的给用户提出 将来系统可能进行 的扩充和修改
系统中最主要、最基本的需求是功能需求。功能体现 计算机能在多大程度上辅助用户完成任务，是用户体 验中最重要的部分。
数据从哪里来（收集过程），到哪里去（存储过程）， 系统内部如何操作和转换这些数据，如果表示数据，如 何共享数据等问题。 数据分析将数据从物理实体映射 为逻辑实体，分析逻辑数据间的连接、视图模型。
软件 需求
功能 需求 用户 操作 时 间
性能 需求
空 间 … …
领域 需求 安 全性
其它 需求
数据
法律 道德 预期 需求 需求 需求
描述系统提供的服务和在特定条件下的行为。包
括系统登录、输入、响应、输出、异常等，有时
还需要特别说明系统不应该做什么。通过需求分
析，划分出系统必须完成的所有功能。
完整性（尽量得到所有用户提出的服务）和一致