第3章.需求工程过程-1(1)
软件工程实践-3-需求工程(2用例)
用例的可视化描述
系统边界
藏书室
登录 用户管理 图书管理 通信
统计 参与者 藏宝者 晒书计划
规则制定 系统管理员 系统设置
借阅 关系 还书 资料管 理员 上报图书信息
<<actor>> 院图书管理 系统
计算机系统 参与者表示法
用例
2.用例之间的关系 用例之间的联系
预定游船 <<communicate>> <<include>> 收集支付信息 <<include>> <<communicate>> 预定航班 单向 代理人 用登录验证代理 人 用指纹扫描验证 代理人 <<extend>> 为飞行常客 预定航班
响应 编辑新书，并保存在系统中 告知藏书者要借阅的信息并进行记录 告知藏书者要借阅的信息并进行记录 产生图书统计清单 产生图书推荐清单 编辑资料，并保存在系统中 完成要求 完成要求 记录收藏信息 修改图书借阅状态 记录评语 编辑推荐信息并保存在系统中 产生到期催还通知单 产生图书统计表
将MSMS项目事件表进行分组
非正式形式的样例项目用例
用例UC2：藏书管理 对个人拥有图书信息的管理。 用例UC2.1：添加藏书 基本流程： •藏书者登记新购买图书的信息，包括书名、作者、译者、出版社、购买时间（系统自动 给出录入时间）、价格、对图书的推荐信息、喜爱程度（默认情况下为3星，最高等级为5 级，最低等级为1级），数量（默认为1本，极个别情况会出现多本重复书籍）、归类（方 便管理，可自己设定归类名称）。 •系统进行输入信息的有效性检查 •系统根据图书名称进行重复图书检查 •存储图书信息，并提示存储成功。 •系统重新显示初始录入界面，用户可以进行下一本图书的录入过程。 分支流程： 1.a、如果藏书者录入信息有误 1、系统提示藏书者此信息 2、返回添加藏书界面，界面保持原来填写数据 3.a、如果图书名称发生重复，系统将提示此信息，并给出相应图书列表，用户可以查阅图 书的详细信息，同时要求用户对此情况进行处理。 1、 如果确认图书录入重复，则系统放弃对当前图书信息的存储 2、 如果只是同名不同书，则用户确认此情况后，系统对当前录入的图书信息进行保存。
第3章需求工程概论
➢ 以便开发人员在代码生成后能够通过测试结果向客户表 明软件系统已完整地实现了所有需求。
2024/6/7
24
小结
➢ 软件需求指，利益相关方对目标软件系统在功能、 性能、质量等方面的期望，以及对目标软件系统 在运行环境、资源消耗等方面的约束。
➢ 软件需求可划分为功能需求、质量需求和约束性 需求三种类型。
2024/6/7
23
需求工程过程
➢ 联合工作组被分成两个小组，分别处理用户配置和 传感器监测子系统。
➢ 分组的目的是对子问题的需求进行获取、分析、规范化 等项工作。
➢ 在各子系统的需求已基本明确并形成需求模型后，联合 工作组还应就子系统的整合及需求验证标准展开讨论。
➢ 子系统整合包括：子系统接口之间的一致性检查、子系 统合成后系统功能和行为的完整性检查。
2024/6/7
27
问题A 图书馆管理()
一个小型图书馆管理系统，需完成以下工作： (1)借书、还书； (2)图书馆中增加/删除一本书； (3)照作者名或专业领域检索一批书； (4)出被某位读者借出的一批书； (5)出最近借走某本图书的读者。 该系统有两类用户：图书管理员与普通读者。 功能(4)可供普通读者查找他们自己借出的书目。 功能(1)、(2)、(5)只供图书管理员使用。 该系统必须满足以下限制： (1)馆中所有未借出的书籍能够供读者随时借阅。 (2)在同一时刻，一本书不能既被借出，又可供借阅。 (3)一个读者一次借出的书籍数目不能超过预定值。
➢ 质量需求和约束性需求统称为非功能需求。
➢ 软件需求的质量要素包括正确性、完全性和可行 性。
➢ 为了获得高质量的需求模型，需求工程师必须掌 握与用户/客户交流的技巧。
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
软件工程- 需求分析 (1)
需求文档模板
编写需求文档 规范化后的潜在需求
产品开发计划
需求文档审核 通过的需求
未通过的需求
需求组件库
需求规格说明书
需求文档评估
分析/设计/实现
需求评估报告
需求过程中的角色
名称 描述
用户
直接操作软件的人员。他们通常具有不同的业务角色， 有不同的业务需求。例如一个图书管理系统的用户包 括：读者、图书管理员、仓库管理员、系统管理员、 馆长 指软件开发的委托方或软件市场的目标客户。例如， 某一设备制造商委托软件开发商进行设备控制软件开 发，那么该设备制造商是系统的客户
(8)
•
资源需求
软件运行时所需的数据、软件。
内存空间等资源。
• 软件开发、维护所需的人力、
支撑软件、开发设备等。
(9)
安全保密要求
• 需对访问系统或系统信息加以控制吗？ • 如何隔离用户之间的数据？ • 用户程序如何与其它程序和操作系统隔
•
离？ 系统备份要求？
(10) 软件成本消耗 与开发进度需求
• 开发有规定的时间表吗？
• 软硬件投资有无限制？
(11) 质量保证
• • • • • • •
系统的可靠性要求？
系统必须监测和隔离错误吗？ 规定系统平均出错时间？
出错后，重启系统允许的时间？
系统变化如何反映到设计中？ 维护是否包括对系统的改进？ 系统的可移植性？
软件需求的特性
(1) 可验证性 可验证性是软件需要的基本属性。软件需求必 须是可验证的，否则软件的评审和测试就没有相 应的依据。但在某些情况下，很难对某些软件需 求进行验证或需要的代价很高。软件需求人员和 测试人员应以合理的代价实现需求的验证。 (2) 优先级 软件需求应具有优先级，可以在有限的资源 情况下进行取舍。 (3) 唯一性 软件需求应唯一地标识出来，以便在软件配 置管理和整个软件生命周期中进行管理。
需求工程资料
需求工程
需求工程是软件工程中至关重要的一个阶段，它涉及到软件开发的前期阶段，是整个软件开发过程中的基础。
在需求工程中，我们需要明确和分析用户的需求，将用户的需求转化为可用的软件规格说明，以指导后续的软件设计和开发工作。
需求工程包含需求获取、需求分析、需求规格说明等阶段，每个阶段都至关重要。
需求获取
需求获取是需求工程的第一步，也是最关键的一步。
在这个阶段，我们需要与用户、客户和利益相关者沟通，了解他们的需求和期望。
可以通过面对面的会议、问卷调查、访谈等方式获取用户需求，确保对需求的全面理解和收集。
只有充分了解用户需求，才能为软件开发提供正确的方向和依据。
需求分析
需求分析是将获取到的需求进行分析和整理，确保需求的一致性、完整性和可行性。
在这个阶段，我们需要对需求进行验证和确认，识别需求中的隐含需求和冲突需求，消除需求的不一致之处。
需求分析的结果是需求规格说明书，其中包含了用户需求的详细描述和开发团队对需求的理解。
需求规格说明
需求规格说明是对需求进行形式化描述的过程，将用户需求转化为具体的软件规格说明。
在这个阶段，我们需要使用各种工具和技术，如用例图、数据流图、状态图等，将用户需求进行详细的分解和描述。
通过需求规格说明书，开发团队可以清晰地了解软件系统的功能、性能、界面等方面的要求，从而指导后续的软件设计和开发工作。
需求工程是软件开发过程中不可或缺的一个环节，有效的需求工程可以帮助开发团队更好地理解用户需求，减少软件开发过程中的风险和错误，提高软件开发的成功率和质量。
因此，对于任何软件开发项目来说，需求工程都是非常重要的。
软件工程导论第讲义3章需求分析
2 原型法处理界面设计问题
在不少项目中，一旦用户对界面挑剔起来将会花 费大量时间。因此，在原型阶段，就应包括界面 设计的原则。从界面风格，易用性，友好化，用 户习惯等多方面达成一定规定，会对程序员在界 面设计上节省大量时间。
1 界面处理流程和后台业务处理流程是否正确。
- 界面处理流程： 界面是指用户面对的界面。 用户只有看到具体的软件界面，才会形成感性 的知识，才能对开发的系统提出具体要求，和 进一步的改进需求。才能理解我们推荐的解决 方案。另一方面，这也是检验PM对用户需求的 理解是否正确，能否做出符合要求的产品。
例如：大多数的动态网站，都是在客户初步的 需求基础上，先制作一个大体上能表现功能的 静态网站出来，然后客户根据这个静态网站提 出进一步的详细需求，开发便按照这个详细需 求来进行。
为了快速地构建和修改原型，通常使用下述3 种方法和工具：
(1) 第四代技术
第四代技术包括众多数据库查询和报表语言、 程序和应用系统生成器以及其他非常高级的 非过程语言。第四代技术使得软件工程师能 够快速地生成可执行的代码，它们是较理想 的快速原型工具。
3.1.3 软件需求分析的任务
一、综合需求
需求分类
功能需求 性能需求 环境需求
(1) 功能需求
• 系统做什么？ • 系统何时做什么？ • 系统何时及如何修改或升级？
(2) 性能需求
软件开发的技术性指标 例如：
• 存储容量限制 • 执行速度、相应时间 • 吞吐量
(3) 环境需求
• 硬件设备：机型、外设、接口、
优点：经济、易于管理；
可以快速将结果制表并分析
需求工程过程PPT课件
一、数据流图的图符 四种基本图形符号：
T
A
B
*
C
T
A
B
*
C
T
A
B
+
C
T
A
B
+
C
T
A
B
C
+
T
A
B
C
+
* 与
+ 或
互斥
+
“先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。
一批 订单
出版社档案文件
订货存根文件
画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。
注意：标注各加工框及数据流名称。
例1：图书预定系统（顶层DFD图）
2.2.2 数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据流程的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻辑输入转换为逻辑输出所需的加工处理。
数据存储
数据源点 或终点
加 工
加工名
数据流
数据流名
文件名
实体名
箭 头
圆或椭圆
单或双杠
矩形框
还有一些辅助的图例:
2.2.3 画分层DFD图的方法
顶层图说明了系统的边界,即系统的输入和输出数据流，顶层图只有一张。底层图由一些不能再分解的加工组成，这些加工都已足够简单，称为基本加工。在顶层和底层之间的是中间层。中间层的数据流图描述了某个加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。
需求工程讲稿(第三讲)需求工程的方法
需求工程的方法过程、方法和技术描述的重要性建模的作用需求工程的维度♦表示维（代表需求的可维护、可验证的程度）⏹非形式的：自然语言⏹半形式的：图形语言（如：UML，DFD，等）⏹形式的：数学或逻辑语言（如：Z，等）♦内容维（代表需求工程的进行程度）⏹模糊的客观世界现象⏹明确的需求规格说明♦一致性维⏹代表某个投资者的观点得到全部投资者的认可需求工程的三维视图非形式非形式形式规格说明表示一致的程度模糊一般完全个人观点公共的观点表示维内容维接受度维再论描述的重要性♦软件开发：获取描述+逐步精化♦需求：是过程的起点需求代码设计系统需求问题描述什么、怎样、相互转化♦传统地，需求应该说明‘什么’而不说明‘怎样’⏹但是这不很容易区分：●一辆小汽车做什么？●一个WEB浏览器做什么？⏹在某个抽象层次上的‘怎样’形成下一个层次上的‘什么’♦Jackson&Zave的工作提供了一个区分：⏹‘什么’涉及系统的目的●对系统来说是外部的●是应用领域的特性⏹‘怎样’涉及系统的结构和行为●对系统是内部的●是机器领域的特性需求需求需求设计设计设计系统子系统单元什么什么什么怎样怎样怎样关注于问题♦问题先于解决方案⏹硬件和软件都能正常运行，但它起的作用却不是所想要的⏹对提早发现潜在的困难有帮助，困难越后发现越难解决♦计算机系统和现实世界的关系计算机系统计算机系统以外的世界解决方案在此问题在此世界和计算机之间的连接需求处于环境之中♦机器⏹我们称要被开发出来的软件系统为机器⏹硬件是为了运行软件而存在的，因此是机器的一部分♦应用领域⏹机器将与它所处的环境发生交互⏹建立机器为了实现现实世界中的某个目的⏹定义机器的环境，就是定义应用领域⏹应用领域常常是人类活动的系统♦实现的决策是出于那些在应用领域中没有基础的需求⏹例子：字典要存放在Hash表中；病人记录要存放在一个面向对象数据库中需求的环境零售企业系统客户银行帐户部门仓库供应商订购，付款帐单信用状态帐单，查询订购财务报告发货通知运送报告需求的环境借书还书续借需求就是描述♦指代：⏹环境中的实体：为它规定一个名字⏹观察到的现象：告诉你怎样识别它，并为它规定一个名字⏹指代通常是非形式的，但它将一个模糊的现象映射到一个形式的（或者说可表达的）语言上♦定义⏹为一个术语给出形式的定义，使这个术语能在其它描述中使用⏹定义或多或少是有用的，但它却是没有对错的需求就是描述♦可反驳的描述：领域的特性⏹陈述领域的某种特性，这种特性在原理上是可反驳的●可能实际上并不会去反驳它，但应该有这样的意识⏹可反驳性依赖于对我们正在描述的领域中的这个被指代的现象的一种询问♦一个粗略的框架⏹是要被开发出来系统描述的一个尝试性描述●允许包含未定义的术语例子♦指代：MOTHER(X,M)：表示M是X的母亲♦定义：CHILD(X,Y) ::= MOTHER(Y,X)∨FATHER(Y,X)♦可反驳的描述：对所有M和X有，MOTHER(X,M) →⌝MOTHER(M,X)♦粗略的框架：每个人实际上都只属于一个家庭描述的语气问题♦描述的不同语气⏹直述：给出一个事实⏹询问：问一个问题⏹命令：传递一个命令⏹假设：陈述一种可能⏹希求：表达一种愿望需求是希求式的♦需求一定包含“应该做什么”♦对需求工程来说，一般应该有的语气：⏹领域特性：直述式语气⏹需求：希求式语气♦语气随开发进程不断变化需求描述需求的表示维坐标语言语言的形式化程度需求的内容维：模型♦现实中的三类模型⏹图示模型：一个雕塑，可视化⏹类比模型：一架模型飞机，使能测试经验的决策⏹分析模型：表示社会经济的一组数学方程，使能分析所描述的系统的可能行为需求中的模型分析模型类比模型理解问题，为问题世界的相关部分建模映射为实现，比如：用数据库存放信息模型的抽象性♦模型不仅仅是描述⏹它具有自己的现象，和它自己的关于这些现象之间的关系●只有当模型的现象按一种系统的方法对应到要被建模的领域的现象时，这个模型才是有用的。
第三章 软件工程 需求分析-基础部分
3.1.4 需求分析的过程
分析与综合 从信息流和信息结构出发,逐步细化所有的软件功能, 从信息流和信息结构出发,逐步细化所有的软件功能,找 出系统各元素之间的关联,接口特性和设计上的约束, 出系统各元素之间的关联,接口特性和设计上的约束,分 析它们是否满足功能要求,是否合理. 析它们是否满足功能要求,是否合理.剔除其不合理的部 增加其需要部分.最终综合成系统的解决方案, 分,增加其需要部分.最终综合成系统的解决方案,给出 目标系统的详细逻辑模型. 目标系统的详细逻辑模型. 常用的分析方法 面向数据流的结构化分析方法 面向数据流的结构化分析方法 (SA) 面向数据结构的Jackson方法 面向数据结构的Jackson方法 (JSD) 面向数据结构的结构化数据系统开发方法 面向数据结构的结构化数据系统开发方法 (DSSD) 面向对象的分析方法 面向对象的分析方法 (OOA) 等
16
3.2.1 需求获取技术
需求调查对象 对组织的高层管理者, 对组织的高层管理者,进行组织管理目标或经营方针等 组织战略问题的调查 对中层的管理者, 对中层的管理者,进行全部业务流的调查 对业务工作人员, 对业务工作人员,进行详细业务信息的调查 市场调查 了解市场对待开发软件有什么样的要求; 了解市场对待开发软件有什么样的要求;了解市场上有 无与待开发软件类似的系统 考察现场 了解用户实际的操作环境,操作过程和操作要求. 了解用户实际的操作环境,操作过程和操作要求.对照用 户提交的问题陈述,对用户需求可以有更全面, 户提交的问题陈述,对用户需求可以有更全面,更细致的 认识. 认识. 观察用户工作流程 用户和开发人员共同组成联合小组
具体化 表 达 需 求
3
目标系统
物理模型
实例化
逻辑模型
软件工程 第3章需求分析
位置：定货报告 定货信息 库存清单
面向数据流方法的分析的应用
6 D1 库存清单 事务 1 包含零件编 号、名称、 目前价格
深入调查
外部输入或系 统生成
3.2.2 面向数据流的自顶向下求精
• 回溯时常遇到的问题：为了得到某个数据元素需要 用到数据流图中还没有的数据元素，或者得出这个 数据元素要用的算法尚不完全清楚。 • 因此，需要向用户等有关人员请教，他们的回答使 分析员对目标系统的认识更深入具体，系统中更多 的数据元素被划分出来，更多的算法搞清楚了。 • 把分析过程中得到的有关数据元素的信息记录在数 据字典中，把对算法的简明描述记录在IPO图中。 通过分析而补充的数据流、数据存储和处理，应该 添加到数据流图的适当位置上。
• 主要目标：把数据流和数据存储定义到元 素级别（不可分解为止）
数据的来源、去 向、数据结构定 义等
可行性 分析忽 略了细 节
3.2.2 面向数据流的自顶向下求精
自顶向下，逐 层细化的方法
• 结构化分析方法是一种什么方法呢？ • 从数据流图的输出端着手分析，这是因为系 统的基本功能是产生这些输出的关键原因。 • 输出数据决定了系统必须具有的最基本的组 成元素（包括功能和数据结构组成）。
3.4.1 数据对象
• 它的范畴很大，可以是外部实体(例如，产生 或使用信息的任何事物)、事物(例如，报表)、 行为(例如，打电话)、事件(例如，响警报)、 角色(例如，教师、学生)、单位(例如，会计 科)、地点(例如，仓库)或结构(例如，文件) 等。 • 总之，可以由一组属性来定义的实体都可以 被认为是数据对象。
需求工程
� 什么是需求工程
� 把所有与需求直接相关的活动通称为需求工 程。通常是一些过程的集合：需求获取(需求引出)、需求
分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。
� 需求工程中的活动可分为两大类，一类属于 需求开发，另一类属于需求管理。
11
需求工程
需求开发
需求管理
需求获取
需求分析 编写规格说明
⑸ 将系统级的需求分为几个子系统，并将需求中 的一部份分配给软件组件。 ⑹ 了解相关质量属性的重要性。 ⑺ 商讨实施优先级的划分。 ⑻ 将所收集的用户需求编写成规格说明和模型。 ⑼ 评审需求规格说明，确保对用户需求达到共同 的理解与认识，并在整个开发小组接受说明之前 将问题都弄清楚。
需求管理的目的是维护需求并且确保能把对需求的更改反映到项目 计划、活动和工作产品中。
需求
设计
编码 开发测试 系统测试 实际运行
5
在软件工程中，所有的相关共利益者(stakeholder) 都感兴趣的就是需求分析阶段。
这些相关共利益者包括客户、用户、业务或需 求分析员(负责收集客户需求并编写文档，以及负责客 户与开发机构之间联系沟通的人)、开发人员、测试人 员、用户文档编写者、项目管理者和客户管理者。
� 按照《客户访谈记录分析表》模板填写记录。
� 如果同一部门意见不一致，则由部门领导确定意 见；
� 如果不同部门意见不一致，则应再召开部门间会 议统一意见。
� 注意：这时的会议需要不同部门的领导参加，并 且不同部门的与会人的级别应相同。如会议上不 能统一意见，则报请上级确定。
� 需求开发人员需抽象和总结用户的直接活动，以 确保所获取的需求具有普遍性。主要观察业务流 程、业务发生频率、业务量及业务信息
需求工程课后重点答案解析
1获取需求活动的展开只要保证项I I范伍.可以有需求遗漏。
＜P68 应该为不允许需求遗漏〉错心2涉众是指所有能够影响软件系统的实现或者是会被实现后的软件系统所影响的个人和团体是固定不变的。
CP93 P95应该为不是固定不变的）错“3面对面的会见被认为是最貝丰富内容的交淤方式.是实践中应用最为广泛的需求获取的方法之一。
P113对卍4原型是一个系统.它内化了一个更迟的本质特征•原型系统通常被构造为完整的系统口倒数第八行应该为不完整的系统）错亠1.需求分析与系统设计之间的界限是什么？何时从分析阶段进入设计阶段？需求分析关注系统“做什么”，系统设计关注“如何做”。
当分析阶段完成后才能进入到设计阶段2.需求处理要注意哪些非技术因素？为什么？要注意的非技术因素：组织机构文化、社会背景、商业目标、利益协商等。
二________________________因为利用建模与分析技术构建的解决方案一定要和具体的应用环境相关，不存在不依赖具体应用环境的解决方案，因此，在利用建模分析技术进行要求处理是不能忽视具体应用环境的相关因素3.需求分析与需求工程之间的关系那就是需求工程含义更广，包括需求获取、需求分析、需求定义第二章：1.解释名词：问题域，解系统和共享现象，并结合他们的含义说明软件系统如何与现实世界形成互动的问题域：现实的状况与人们期望的状况产生差异就产生问题。
解系统：软件系统通过影响问题域，能够帮助人们解决问题称为解系统通过共存现象仅仅是问题域和姐系统的一个部分。
而不是他们的全部。
软件系统仅仅是现实世界的一种抽象。
所以问题除了共享现象之外。
还有很多在进行模型抽象时忽略的其他现实因素。
2.解释下列名词，需求，规格说明，问题域特性和约束，并结合他们的含义说明需求工程的主要任务是什么？需求是用户对问题域中的实体状态或事件的期望描述规格说明：规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。
问题域的特性：在和解系统相互影响的同时，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变，这种自治的规律性称为问题域特性，当这些特性非常明确时称之为约束。
软件工程导论第五版张海藩第03章-需求分析
3.1 需求分析的任务 3.2 与用户沟通获取需求的方法 3.3 分析建模与规格说明 3.4 实体-联系图 （？） 3.5 数据规范化（？） 3.6 状态转换图+有穷状态机 3.7 其他图形工具 3.8 验证软件需求 3.9 小结
需Байду номын сангаас分析的意义
软件需求的深入理解是软件开发工作获得成 功的前提条件，不论我们把设计和编码做得如何 出色，不能真正满足用户需求的程序只会令用户 失望，给开发带来烦恼。
软件需求规格说明书，是需求分析阶段得出的最主要 的文档。
软件需求说明书的编写提示（GB856T—88）
1 引言 1.1 编写目的 1.2 背景 1.3 定义 1.4 参考资料
2 任务概述 2.1 目标 2.2 用户的特点 2.3 假定和约束
软件需求说明书的编写提示（GB856T—88）
3 需求规定
建模方法
在过去的数年中，人们提出了许多种分析建模的方法，其中两种 在分析建模领域占有主导地位：
第一种是结构化分析 (Structured Analysis，SA)，70年代末由 DeMarco等人提出，这是传统的建模方法。该方法不是被所有的使用 者一致地使用的单一方法，众多科学家对其进行了扩充，因此它是发 展了超过30年的一个混合物。
2） 项目相关人员用自己的语言表达需求，这些 语言包含很多工作中的专业术语和专业知识。系统分 析员没有这些知识和经验，而他们又必须了解这些需 求。
3）不同的项目相关人员有不同的需求，可能以 不同的方式表达，分析人员必须发现所有潜在的需求 资源，而且能发现这些需求的相容或冲突之处。
4）经济和业务环境决定了分析是动态的，需求 在分析过程中会发生变更。个别需求的重要程度会改 变，新的需求会从新的项目相关人员那里得到。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
内容
技术、方法 问题分析 明确问题 发现业务需求 定义问题解决方案和系统特性 定义问题解决方案的边界 定义系统边界 涉众识别方法 涉众的描述特征 涉众的优先级评估 涉众的风险评估 涉众的共赢分析 代表采样 制定参与策略 使用用户替代源 用户参与 涉众分析的各种方法（如前述） 硬数据采样 建立合作关系，维护交流气氛 利用适当的交流途径、交流方式 面谈/调查问卷 群体会议面谈/头脑风暴原型 观察 文档分析/需求重用/需求剥离 面向目标的方法 基于场景的方法 基于用例的方法
差异性管理
获取
分析
确定可行性 形式化建模
规格
基于视图的文 档化 确保可跟踪性 文档化需求理 由 描述可度量、 可测试的需求 使用标准的文 档结构 原型
验证
获取非功能需 求
获取任务与业 务过程
GUI界面建模
用户行为建模
确定范围
获取目标
领域建模
数据建模
文档化客户需 求 文档化开发者 需求
形式化需求验 证
需求工程过程实例 RUP
商业建模：
1.评价组织的当前状态，包括支持新系统的能力； 2.探索当前业务的过程、角色和职责； 3.识别与评价业务过程改造的潜在策略； 4.开发反映业务内容的领域模型。
需求：
1.与项目涉众紧密接触，理解他们的需要； 2.定义项目的范围； 3.通过恰当的建模，探索功能、非功能、业务规 则、用户界面等需求； 4.识别项目中新的及变更的需求，并明确他们的 优先级。
2. 需求工程过程的活动
需求获取子活动
收集背景资料 定义项目前景和范围 选择信息的来源 选择获取方法，执行获取 记录获取结果
2. 需求工程过程的活动
需求信息，以使得人们更好的理解问题 为问题定义出一个需求集合，这个集合能够为问题 界定一个有效的解决方案 检查需求当中存在的错误、遗漏、不一致等各种缺 陷，并加以修正
· 需求文档草稿 · 详细的范围表 示 · 更新POR
· 最终的需求文档 · 初始结构与原型 下一个产品 项目活动计划阶段 ……
需求工程过程实例
Practices-Based
管理需求变更 成本与时间 估算 确定角色与责 任 需求优先级与 协商
管理
风险评估 产品规划 需求复用
需求工程过程 改进
技术选择
6. 需求工程过程与软件工程过程
需求工程过程更应该是软件工程过程的一部分，而不是独立 出来作为单独部分 < Requirements Engineering and Software Project Success- An Industrial Survey in Australia and the US >
第3章.需求工程过程
主要内容
1. 2. 3.
4.
5. 6.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性 实践方法的应用 需求工程过程实例分析 需求工程过程与软件工程过程
1. 需求工程过程
过程是一组相关活动的集成，通过这些活动的执行，可以 完成一项任务或者达到一个目标。 需求工程过程是系统开发当中需求开发活动的集成，它的 模版是产生一个能够在用户环境下解决用户业务问题的系 统方案 需求工程过程可能会表现出极大的差异，但是除了少数情 况之外，主要的需求工程活动是比较固定的
主要内容
1. 2. 3.
4.
5. 6.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性 实践方法的应用 需求工程过程实例分析 需求工程过程与软件工程过程
需求工程过程实例
螺旋RE
需求工程过程实例
依赖原型方法的需求开发过程
应用领域 基础及高阶 模型开发 同级评审
领域分析
涉众反馈
编写规格
需求分析
通过建模手段明确和理解需求信息 为需求建模 使用多种手段从多角度建模相同的内容 在合适的层次上描述需求 唯一的标识每一条需求 划分需求的优先级 需求细化 需求细化 确定需求优先级 累计投票 区域划分 Top-N 数据量化 面向目标的方法 面向问题域的分析 领域分析 企业建模 上下文图和系统用例图 ERD和数据字典 DFD、FDD和PDD 状态(转移)图/矩阵 UML（分析部分） 多视点方法 Wiegrnga框架 Zachman框架
需求变化
变更控制
项目活动
系统开发
主要内容
1. 2. 3.
4.
5. 6.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性 实践方法的应用 需求工程过程实例分析 需求工程过程与软件工程过程
2. 需求工程过程的活动
需求获取
需求获取是从人、文档或者环境当中获取需求的过 程 需求工程师必须要利用各种方法和技术来“发现” 需求 需求获取和需求分析是交织在一起的
需求规格说明 进行良好的写作 学习有效的写作实践
需求验证
验证需求
使用有效方法进行需求的验证 和确认
需求评审 原型与模拟 开发测试用例 用户手册编制 利用跟踪关系 自动化分析
建立和维护需求基线
建立和维护需求基线
配置管理 状态维护 变更控制过程 变更控制事项（策略） 低端/高端的需求跟踪使用 需求跟踪矩阵 需求依赖
需求工程过程实例
需求 活动
需求 • 将需求获取为Story 获取 • 客户书写User Story • 需求 • 分析 • • 需求 规格 • • • 需求 • 验证 • • 需求 • 管理 •
Agile RE
表3-3 XP和Scrum的需求工程活动组织，源自[Lucia2010] XP方法 Scrum方法
分析与设计（仅列举需求开发工作）：
1.理解并分析系统的需求。
主要内容
1. 2. 3.
4.
5. 6.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性 实践方法的应用 需求工程过程实例分析 需求工程过程与软件工程过程
6. 需求工程过程与软件工程过程
意识到的需要
软件的问题 域比较成熟 和易于明确 化，并且需 求也比较稳 定 不利于用户 的有效参与
原型开发
场景走查
需求工程过程实例
HP 需求过程
……
前一个产品 项目活动执行阶段
当前产品 项目活动计划阶段 高层次范围 · 产品数据表格 · 带有收益率、 价值、成本等 信息的范围幻 灯片 · 已批准的产品 列表 需求，详细范 围，资源规划 POR创建
是否继续进行的决策点
当前产品 项目活动执行阶段 · 范围规划 POR(Plan Of Record) · 项目利润 分析 设计、实现...后续 开发活动
执行验证 问题修正
2. 需求工程过程的活动
需求管理
保证需求作用在整个软件的产品生命周期中的持续、 稳定和有效发挥 建立和维护需求基线集 建立需求跟踪信息 进行变更控制
需求管理子活动
主要内容
1. 2. 3.
4.
5. 6.
需求工程过程 需求工程过程的活动 需求工程过程的并发和迭代性 实践方法的应用 需求工程过程实例分析 需求工程过程与软件工程过程
设计
实现
测试
集成
运行与维护
6. 需求工程过程与软件工程过程
问题域极其复杂或者需求不稳定 更好的应对需求的改变 提高用户的有效参与度 使得开发工作的协同和管理工作变得困难
需求开发 需求管理 需求 设计 实现 测试 集成 运行与维护
版本1
版本2
需求
设计
实现
测试
集成
运行与维护
版本3
需求
设计
3.需求工程过程的并发和迭代性 ——需求开发中的分析模型复杂度
3.需求工程过程的并发和迭代性
Framing Requirements Work as Learning
3.需求工程过程的并发和迭代性 ——迭代的需求开发过程模型
3.需求工程过程的并发和迭代性 ——需求开发活动的并发性
主要内容
2. 需求工程过程的活动
需求分析子活动
背景分析 业务分析（问题分析、目标分析、涉众分析），确 定系统边界 需求建模 需求细化 确定优先级 需求协商
2. 需求工程过程的活动
需求规格说明
获取的需求需要被编写成文档，主要目的是为了在 系统涉众之间交流需求信息 业务需求被写入项目前景和范围文档 用户需求被写入用户需求文档（或者用例文档） 系统需求被写入需求规格说明 定制文档模版 编写文档
定义项目前景 需求获取 控制项目范围
定义项目前景
控制项目范围
实现用户价值 需求获取 促进用户参与
涉众识别 涉众描述 涉众分析
涉众采样 用户参与 涉众分析 硬数据采样 需求重用 建立有效交流机制
识别并使用各种需求源
需求获取
有效的获取需求
正确使用需求获取方法
收集和组织需求获取的结 果
建立收集和组织需求需求结 果的机制
• 产品负责人（Product Owner）明 确叙述产品功能(Product Backlog) • 任何涉众都可以参与产品功能确定 并非独立阶段 • 功能(Backlog)精化会议 开发时进行分析 • 产品负责人划分产品功能优先级 客户为User Story划分优先级 • 产品负责人分析需求可行性 User Story和验收测试用例作 为需求文档 • 面对面的交流 软件产品本身作为文档信息 面对面的交流 测试驱动 • 评审会议 验收测试 频繁反馈 短的规划周期 • 蓝图规划会议 跟踪User Story • 跟踪产品功能项 按需重构 • 对产品功能变更需求