需求管理知识点案例参考

Posted 2022-12-10 鱼竿钓鱼干

案例分析

Tip：仅供参考，如有错误评论区说

案例1：

如果你是一个项目经理，你根据你所了解的软件生命周期模型，分析各个模型的优点、缺点以及适用的项目，总结一下对不同的项目所采取的生命周期模型，应如何选择?

瀑布模型：

优点

1、各阶段文档齐全，减少沟通成本。

2、每个阶段评审通过才开始下一阶段，质量有保障。

缺点

1、不适应需求变更，如果变更之前所有阶段都必须调整。

2、每个阶段产生大量文档，管理困难。

3、用户不能很快看到软件产品

适用

适合用户需求无明显变化，无变动

快速原型模型：

优点

1. 不带反馈环
2. 本质是快速
3. 基本线性顺序执行
4. 用途是感知用户需求
5. 减少较大返工
6. 减少后续犯错可能

缺点

1. 没考虑软件总体质量和长期可维护性
2. 可能采用了不合适的操作系统，编程语言，低效的算法
3. 开发过程不方便管理

适用
已有产品或产品的原型，只需客户化的工程项目

增量迭代模型：

优点

1. 优先实现基本和核心功能，提供用户评估平台
2. 整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。
3. 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
4. 设计阶段多付出的劳动将在维护阶段获得回报。

缺点

1. 在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品
2. 软件体系结构必须是开放的
3. 开发人员既要把软件系统看作整体。又要看成可独立的构件，相互矛盾
4. 多个构件并行开发，具有无法集成的风险

适用

慎重考虑使用渐进模型的情况

1. 不能充分理解客户需求或客户需求有可能迅速发生变化
2. 事先拟采用的技术迅速发生变化
3. 客户突然提
4. 出一些新的功能需求
5. 长时期内仅有有限的资源保证（开发人员和资金）

使用渐进模型的情况

1. 需要在尽短的时间内得到系统基本功能的演示或使用
2. 各版本都有中间阶段产品可提供使用
3. 系统可以被自然地分割成渐增的模式
4. 开发人员与资金可以逐步增加

螺旋模型：

优点

1. 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
2. 减少了过多测试或测试不足
3. 维护和开发之间并没有本质区别

缺点

1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
2. 过多的迭代次数会增加开发成本，延迟提交时间

适用

内部大型软件系统

喷泉模型：

优点

1. 支持面向对象模型，无缝迭代
2. 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间

缺点

由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况

适用

适应于面向对象的软件开发过程。

---

案例2：

结合你所学的软件工程相关知识，请你表述一下结构化的开发方法与面向对象的开发方法思想的不同之处。

结构化的开发方法：

从功能化和流程化角度考虑

思想：先彻底了解、分析问题，再规划、实现系统

面向对象的开发方法：

从对象角度考虑

思想：调查问题并细化问题，最后根据这些内在联系实现整个系统

---

案例3：

小明刚入职，项目经理安排他参加需求的培训课程，培训老师了解到他是一名软件工程专业毕业的同学，就让他谈谈对软件需求的理解，软件需求工程主要的活动有哪些，具体完成哪些内容，需求工程有哪些特性？

软件需求：

1. 用户解决某一问题或达到某一目标所需要实现的软件功能
2. 系统或系统构建为了满足合同、规约、标准或其他正在实行的文档而必须满足或具备的软件功能

软件需求工程的主要活动：

需求开发

• 需求获取：从用户那里通过合适的方法获取需求
• 需求分析：需求的分类、建模与需求冲突的发现与解决
• 需求规格说明：需求文档化
• 需求验证：验证需求的正确性，保证需求以及文档的完整性和一致性

需求管理
在需求基线完成之后，跟踪后续阶段中的需求实现与需求变更情况，确保需求得到正确的理解和实现

需求工程特性：

必要性

• 解决现实世界的问题：利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的
• 计算机应用于现实世界的广泛性

复杂性

• 处理范围广泛
• 涉及诸多参与方
• 处理内容多样
• 处理活动相互交织
• 处理结果要求严苛

并发性

迭代性：需求分析模型复杂度会随和时间推移不断增加

---

案例4：

小李是一名软件需求工程师，刚刚参加工作，项目经理让小李谈一谈需求如何从业务问题转化为系统模型以及需要获取哪些需求？请结合案例从对需求的层次、每一层次的需求的含义和产出文档、不同层次间需求的关系以及需求的分类角度阐述。

需求的层次

业务需求（目标）

• 来源于决策者
• 是系统的目标和效益
• 表现为解决方案与系统特性
• 描述为什么开发软件或系统why
• 形成的文档为项目的前景和范围文档

用户需求（任务）

• 来源于用户
• 是系统需要提供的具体任务
• 表现为问题域知识
• 描述用户使用系统能够做什么事情（what）
• 形成的文档为用户文档（或称用例文档）

系统需求（系统行为）

• 来自软件开发者
• 是软件系统行为
• 表现为系统分析模型
• 描述开发人员如何设计具体的解决方案来实现这些需求（how)
• 形成的文档为需求规格说明文档

不同层次之间的关系

需求的分类

功能需求：

是和系统主要工作相关的需求，主要表现为系统和环境之间的行为交互

非功能需求：

• 性能需求：速度、容量、吞吐量、负载、实时性
• 质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
• 对外接口：与其他系统的软硬件接口和用户界面
• 约束：运行环境、相关标准、社会性因素、将来可能提出的需求

---

案例5：

小王是一名需求工程师，在获取需求的过程中，她在与用户面谈的过程中，用户提出需要在系统功能的角度增加“月结算”的功能，同时系统的查询时间不多于1秒，系统应当能够存放1万条结算记录，系统可以允许100人同时在线工作。小王在面谈结束后，记录下了系统应添加的“月结算”功能，但是对于其他的内容认为不是系统的功能，不需要考虑到需求中，因此就没有写入用户的需求中。请结合需求的分类，谈一谈功能需求与非功能需求的含义和包含的具体内容，以及在软件系统中非功能需求的重要性。

功能需求

是和系统主要工作相关的需求，主要表现为系统和环境之间的行为交互

非功能需求

• 性能需求：速度、容量、吞吐量、负载、实时性
• 质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
• 对外接口：与其他系统的软硬件接口和用户界面
• 约束：运行环境、相关标准、社会性因素、将来可能提出的需求

非功能需求的重要性

非功能性需求往往影响整个系统用户体验，在资源、时间有限的情况下，有限完成功能性需求，很多情况下是优先功能性需求，从而忽略了非功能性需求，这样导致后面软件稳定性差、扩展困难等问题

另外，非功能性需求需要在设计过程中在软件开发后期或者软件交付后调整困难，经常涉及颠覆性改动，改造成本大，增加软件开发风险。

---

案例6：

质量是软件的生命，这要从软件需求阶段就要体现出来，请结合质量属性谈一谈质量属性包括哪些方面，如何从用户那里获得对质量属性方面的需求呢？举例说明。

质量属性包括

质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性

如何获取质量属性方面需求

---

案例7：

项目经理安排小明完成一个项目的需求工作，小明应当如何完成一个完整的需求工程的过程以及如何衡量需求做的是否优秀呢？请结合需求工程的路线以及优秀的需求的特性谈一谈。

需求工程的过程

1. 需求获取
   • 选择信息的来源
   • 定义项目前景和范围
   • 选择获取方法、执行获取
   • 记录获取结果
   • 收取背景资料
2. 需求分析
   • 背景分析
   • 确定系统边界
   • 需求建模
   • 确定优先级
   • 需求协商
3. 需求规格说明
   • 业务需求被写入项目前景和范围文档
   • 用户需求被写入用户文档
   • 系统需求被写入需求规格说明
4. 需求验证
   • 执行验证
   • 问题修正
5. 需求管理
   • 建立和维护需求基线集
   • 建立需求跟踪信息
   • 进行需求变更

需求工程的路线

1. 问题分析和背景分析

2. 需求获取

   • 确定问题域范围
   • 确定获取的源头、主题和内容，选择获取的方法
   • 得到需求获取的文档资料

3. 需求分析

   • 建立系统模型
   • 将用户需求转化为系统需求

4. 文档化和验证

   • 产生需求规格说明文档
   • 对需求规格说明文档进行需求验证

优秀需求的特性

完整性：充分包括用户需求
正确性：真实反映用户需求
可行性：检查是否具备实现可能性
必要性：保证需求简介、不冗余
无歧义：定义词汇表，避免二义性
可验证：采用分析、检查、模拟或测试等方法验证需求是否被满足

---

案例8：

在实际的需求获取的过程，常常涉及到的范围和内容都是比较复杂的，结合所学的需求获取的非平凡性的相关知识，谈一谈为什么需求的获取过程是一个具有相当难度的活动？

需求获取的非平凡性

• 用户和开发人员的背景立场不同
• 默认知识现象
• 普通用户缺乏概括性、综合性的表述能力
• 用户存在认知困境
• 用户越俎代庖
• 缺乏用户参与

---

案例9：

需求工程师小王被安排完成需求获取的工作，他了解到需求获取就是从用户哪里获得系统具体要做什么，即具体的任务。结合需求获取的要点谈一谈小王在需求获取过程中需要考虑的要点以及每个要点中需要完成的相关内容？

需求获取过程(子活动)

1. 研究应用背景，收集背景资料，建立初始的 知识框架；
2. 获取问题，项目前景和范围文档
3. 分析涉众，选择信息的来源
4. 确定获取的内容和主题，建立系统边界，设 定场景；
5. 根据获取的需要，采用必要的获取方法和技 巧；执行获取。分析用户的高（深）层目标， 理解用户的意图；
6. 记录获取结果，写出 项目前景和范围文档。

要点

• 获取的内容
  • 在项目的范围之内
  • 所有为用户创建解决系统必须的信息：需求、问题域描述 、环境与约束
  • 获取的内容不是一次得到的，而是逐步积累的
• 获取的来源：涉众、相关产品、硬数据、重要文档、相关技术标准和法规
• 确定需求获取的方法：传统方法、集体获取方法、原型、模型驱动方法、认知方法、基于上下文的方法、采样方法
• 获取的过程：防止需求遗漏、结束获取活动的判断条件
• 需求获取的结果：笔录，正式文档（项目前景和范围文档 、用例文档）

---

案例10：

需求工程师小王在需求获取的活动中需要找到项目的相关涉众并及进行涉众的分析工作。请给小王一些建议他该如何完成这个工作，即应考虑哪些涉众以及涉众分析的具体步骤。

涉众

1 用户: 最终使用和操作产品的人
关注软件功能，是需求信息来源
2 客户: 为软件系统的开发付费的人
关注经济上的成本、收益
3 开发者: 负责实现软件系统的人
关注技术上的成本和收益
4.管理者：参与软件系统开发事务管理的人
投资方管理者 、执行负责人、项目管理者
关注系统的开发进程
5.领域专家: 在问题域中具有丰富知识的专家
关注软件中的知识
6.政府力量 :法律法规 、长远规划、政策意向等
起约束和指导作用
7.市场力量：组织中的市场部门人员
关注用户的想法
8.维护人员：系统管理员，关注用户的想法人员
系统的日常维护

涉众分析具体步骤

1. 识别涉众
2. 描述涉众
3. 评估涉众
4. 选择涉众
5. 制定涉众代表参与需求开发（软件系统）的参与策略

案例11：

硬数据是需求工程师所获取的文档资料，需求工程师在需求获取的过程中，一般采用的硬数据类型有哪些？两种硬数据的形式和特点有哪些？

硬数据类型有哪些

定量硬数据

• 数据收集表格
• 统计报表
• 数据收集表格
• 统计报表

定性硬数据

• 整个组织的描述文档
  • 组织结构图 ：帮助发现项目的关键涉众
  • 门户网站：反映组织的业务开展状况
• 业务指导文档
• 业务备忘

两种硬数据的形式和特点有哪些

---

案例12：

项目经理让小张完成需求获取的过程，小张没有想好采取何种方式完成需求的获取以及需要获取的结果的形式。你能结合需求获取的方法和获取结果的形式给他一些建议吗？

需求获取的方法

1. 以用户的语言表达为关注点（传统方法）

• 传统方法：
  • 问卷调查、面谈、硬数据分析、文档检查、需求剥离等
• 集体获取方法：
  • 头脑风暴（Brainstorming）、专题讨论会（Workshop）、联合应用开发JAD、联合需求计划JRP等
• 原型：适用于需求模糊和不确定性较大的情况
• 模型驱动方法
  • 定义明确的模型，确定所收集的信息类型，模型建立和完善的过程就是进行需求获取的过程
  • 面向目标的方法、基于场景的方法、基于用例的方法
• 认知方法
  • 以认知的方式获取用户无法表达的潜在知识
  • 任务分析（Task Analysis）、协议分析（Protocol Analysis）等

2. 注重用户在一定环境下表现出来的行为

• 基于上下文的方法
  • 通过分析用户的行为得到信息：观察、民族志（Ethnography）和话语分析（Conversation Analysis）

3. 采样方法：
   • 随机采样
   • 分层抽样

需求获取结果的形式

肯定会产生获取笔录

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

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

• 项目前景和范围文档
• 用例文档

---

案例13：

小李刚接手一个项目，项目经理分配小李完成项目前景和范围文档，他需要查阅相关资料了解前景和范围包括的内容、如何通过问题分析得到业务需求和解决方案与系统特性，以及前景和范围文档涉及到的人员、文档的结构。请回答他查阅资料以后得到的结果。

前景和范围包括的内容

业务需求、高层次解决方案和系统特性

如何通过问题分析得到业务需求和解决方案与系统特性

前景和范围文档涉及到的人员、文档的结构

撰写人：需求工程师
文档负责人：投资负责人、执行主管或其他类似角色

---

案例14：

小李是一名软件需求工程师，刚刚参加工作，项目经理让小李安排一次与用户的面谈，请你给他一些建议，包括如何选择面谈的结构、如何选择面谈的类型、提出的问题的类型、记录面谈的方式、内容以及面谈结果的形式。

面谈的结构

• 金字塔型：话题逐渐式展开
• 漏斗型：开放式话题不断深入
• 菱形：逐步展开，话题深入

如何选择面谈的类型

• 结构化面谈：完全按照事先的问题和结构来控制面谈
• 半结构化面谈：实现根据面谈内容准备，在面谈过程中，会见者可以采取灵活的策略
• 非结构化面谈：没有事先预定的情况下就某个主题展开面谈

提出的问题的类型

• 开放式问题：适用于面谈前期，问题的回答一般是开放和不受限制的
• 封闭式问题：适用于面谈后期，问题的回答一般是受到限制的

记录面谈的方式

• 笔录
• 录音录像

面谈内容

• 事实和问题（主要）
• 被会见人的观点
• 被会见人的感受
• 组织和个人目标

面谈结果的形式

---

案例15：

小王是一名需求工程师，在获取需求的过程中，他想用比较直观且快速的方式获取需求，他的同事建议他采取原型的方式。请给他一些建议，包括原型的含义，原型的类型、采取原型法的过程以及原型的风险。

原型的含义

原型是在一定广度和深度范围内表现最终物件的一个中间物件，它内化了一个更迟系统的本质

原型的类型

• 按照使用方式分类
  • 演示原型：启动项目阶段，让用户相信应用系统的开发是可行的
  • 严格意义上的原型：需求分析阶段，阐明用户界面或者系统功能的某些特定方面
  • 试验原型：主要被用在构建系统阶段，帮助开发者澄清他们所面对的一些和系统构建相关的技术问题
  • 引示系统原型：会被用在系统开发的各个阶段，用作最终系统的构建核心，在后续开发中不断增强
• 按照开发方法分类
  • 探索式（开发的原型为抛弃式原型）
    • 以缺陷需求开始继而不断调整和修正需求的原型开放方式
    • 适用需求确定性不高，不确定的需求来自于用户需求方面
  • 实验式（开发的原型为抛弃式原型）
    • 以清晰的用户需求和模糊的视线方法、实现效果、可行性开始，明确需求的可行性和技术实现方案
    • 适用需求不确定性高，不确定的需求主要来自技术细节
  • 演化式（开发的原型为演化式原型）
    • 以清晰的原型化需求和项目积累下来的原型资产为开始，不断传递和不断增强的原型资产成为最终的软件系统
    • 适用需求不确定性低
• 按照构建技术分类
  • 水平原型方法
    内容
    仅仅实现选定功能所有层次中的某些特定层次
    注意力集中在概括性需求和工作流问题上，处理范围较大但并未实现所涵盖的功能
    关注层次
    人机交互原型—关注用户使用时的感觉体验
    功能与任务原型—关注用户的任务
    实现原型—关注特定功能实现的技术细节
  • 垂直原型方法
    会触及到选定功能实现的所有层次
    要保证真实实现它的各种功能，考虑所有技术细节
• 按照介质分类
  • 低保真原型
    • 形式：纸面、幻灯、动画
    • 特点：保真度低、成本低
  • 高保真原型
    • 形式：快速语言和工具、程序语言
    • 特点：保真度高、成本高
• 按照表现分类
  • 静态画面
  • 动态程序
  • 情节串联图版（故事版）:交互性介于静态页面和动态程序之间的一种表现形式，它能够表现场景式的互动

采取原型法的过程

1. 确定原型需求：为什么开发模型，拥有的起点时说明？期望的结束标准是什么
2. 原型开发：依据原型的需求特点和开发目的，以最低成本建立初识原型
3. 原型评估：对上一阶段原型进行评估，根据评估者的反馈判断原型是否满足结束标准
4. 原型修正：如果原型达到了目的，就结束；否则根据评估者反馈进行原型调整，调整完成后准备再次进行模型评估

原型的风险

• 最大的风险是成本失控
• 第二个风险是给用户造成错误印象，认为产品几乎已经完成，提出交付产品的需求
• 第三个风险是用户过多的关注原型的非功能特性，容易忽略功能特性
• 第四个风险是原型掩盖可能一些用户假设

---

案例16：

小明作为一名需求工程师，很了解需求分析在需求工程中的作用，因此，他通过建立需求分析模型来表达用户需求和系统需求，但是他不是很了解又哪些常用的需求分析技术。

请结合你所学的相关知识谈一谈

（1）你对需求分析的根本任务的理解、如何建立需求分析模型、常用的需求分析技术、这些技术的建模思想和具体的建模内容。

需求分析的根本任务

建立分析模型：达成开发者和用户对需求信息的共同理解

建立解决方案：集中关注问题的计算特性（数据、功能、规则等）

如何建立需求分析模型

1. 依据获取的问题域信息建立初步的模型
2. 分析用户需求，对模型进行调整，得到一个中间形式的模型形式
3. 对调整后的模型进行逻辑推理和验证，如果符合预期的期望，就确定为最终的解决方案模型

常用的需求分析技术

• 结构化技术：数据建模、过程建模、行为建模、过程/数据关系建模、信息工程方法
• 面向对象技术：用例图、活动图、类图、状态图、交互图、对象约束语言
• 综合运用需求分析技术
  • 如何选择：针对每一种需求分析技术的特点选择
  • 如何实现它们之间的配合：通过多种需求分析技术的结婚才能充分描述复杂应用

这些技术的建模思想和具体的建模内容

（2）需求分析的活动包括前期的需求分析活动和后期的需求分析活动，这两个活动都分别包括哪些内容？

前期：背景分析、问题分析、目标分析、业务分析、确定系统边界

后期：需求建模、需求细化、确定需求优先级和需求协商

---

案例17：

结合所学谈一谈

（1）面向对象分析中五个层次以及具体所包含的内容。

• 主题层：表示识别主题（子系统）活动，将性质相同的类与对象归纳为同一主题
• 类及对象层：识别类与对象
• 结构层（关系层）：识别结构（继承结构和组合结构）
• 属性层（有的叫特征层）：定义属性（包括实例）
• 服务层：定义服务（包括消息连接）

（2）你对面向对象建模技术中的五大视图、四种（或者六种）关系在软件体系结构角度进行模型的思想的理解。
5大视图

• 用例视图（核心）
  • 作用：描述系统的功能需求，找出用例和执行者
  • 适用对象：客户、分析者、设计者、开发者和测试者
  • 描述使用的图：用例图和活动图
  • 重要性：系统的中心，它决定了其他视图的开发，用于确认和最终验证系统
• 逻辑视图
  • 作用：描述如何实现系统内部的功能
  • 适用对象：分析者、设计者、开发者
  • 描述使用的图：类图和对象图、状态图、顺序图、合作图、活动图
  • 重要性：描述了系统的静态结构和因发送消息而出现的动态协作关系
• 构件视图
  • 作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系
  • 适用对象：设计者、开发者
  • 描述使用的图：构件图
  • 重要性：描述系统如何划分软件构件，如何进行编程
• 进程视图
  • 作用：描述系统的并发性，并处理这些线程的通信和同步
  • 适用对象：开发者和系统集成者
  • 描述使用的图：状态图、顺序图、合作图、活动图、构件图和配置图
  • 重要性：将系统分割成并发执行的控制线程及处理这些线程的通信和同步
• 配置视图
  • 作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接
  • 适用对象：开发者、系统集成者和测试者
  • 描述使用的图：配置图
  • 重要性：描述硬件设备的连接和哪个程序或对象驻留在哪台计算机上执行

4种关系

• 依赖：两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义
  • 两种依赖关系：包含依赖include，扩展依赖extend
• 关联：一种结构关系，连接模型元素及链接实例
• 实现：类元之间的语义关系，一个类元指定了由另一个类元保证执行的契约，如接口和实现它们的类或构件之间，用例和实现它们的协作之间
• 泛化：表示一般与特殊的关系，即一般元素是特殊关系的泛化
  • 两种泛化关系：聚合，组合

（3）UML建模过程中的三大类十种图有哪些？

三大类

• 用例模型图（功能模型）：用例图
• 静态模型图（对象模型）：类图、对象图、包图、构件图和配置图
• 动态模型图（行为模型，包括交互、状态模型）：由活动图、顺序图、状态图、合作图组成

十四种图

用例图、活动图、顺序图、状态图、合作图、类图、对象图、包图、构件图、配置图、新增四种（时间图、交互纵览图、组合结构图、外廓图）

（4）UML建模过程中所产生的模型和文档有哪些？

9种模型

业务模型、领域模型、用例模型、分析模型、设计模型、进程模型、实现模型、配置模型、测试模型

2种文档
技术文档

• 需求分析信息集，包括软件规格说明书、需求补充说明、业务用例图等
• 设计信息集，包括软件设计规格说明书、图形界面、类图、对象图、包图、顺序图、状态图、合作图、活动图
• 实现信息集，包括源程序清单、动态链接库说明、用户适用手册、构件图
• 配置信息集，包括配置图及详细说明

管理文档，包括风险分析说明，软件开发进度计划，配置计划，测试计划，测试方案及步骤

---

案例18：

需求工程师小王被安排完成需求建模和编写用户文档的工作，他采用面向对象的建模方式，他需要了解用例建模的过程、用例模型中用例图包含的内容以及用例文档的组成。请根据你的所学为他提供相关知识。

用例建模的过程

1. 定义系统
2. 确定业务参与者(行为者）
3. 确定用例
4. 确定用例之间的关系
5. 构建用例模型图（层次化用例图）
6. 记录业务需求用例描述
7. 检查（确认）用例模型：检查有没有单独的角色或用例，检查缺失和冗余

用例图包含的内容

主要元素：用例，参与者，依赖、类属、关联关系
可选元素：注释和约束，包，系统边界框

用例文档的组成

用例名称：学生选课
执行者：学生
目的：完成一次学生选课的完整过程。
类型：主要的、基本的
级别：一级
过程描述：
（1）学生输入标识码（ID），系统识别标识码的有效性；
（2）对学生进行注册识别；
（3）流览本学期预开课程；
（4）选择学生自己要上的课程并确认；
（5）退出系统，系统给出所选课程列表及相应学分合计。

---

案例19：

用例图中的依赖关系有两种情况，包含依赖和扩展依赖，请根据相关知识说明两种依赖应用于具有何种关系的用例之间，两种依赖的相同之处和不同之处有哪些？

包含

• 方向：基本用例指向被包含用例
• 两个以上用例有大量一致的功能可以分解到一另一个用例中，其他用例和这个用例建立包含关系
• 被包含的是一种公共用例
• 执行基用例时必须执行被包含用例，被包含用例可以单独执行

扩展

• 方向""扩展用例指向被扩展用例（基本用例）
• 要在扩展点扩展，指明在原用例中的扩展位置

包含与扩展区别

• 方向不同
• 包含
  • 基本用例必须执行被包含用例
  • 包含用例是一个完整的用例，可以独立存在
• 扩展
  • 基本用例可以不执行扩展用例
  • 扩展用例不是一个完整的用例，不能独立存在必须依赖基本用例
  • 扩展用例不能单独被执行者调用

包含与扩展相同点

都是描述用例与用例之间的依赖关系

案例20：

需求工程师小王采用活动图绘制用例描述（或者用例规约），请结合所学谈一谈活动图中动作状态和活动状态的相同之处和不同之处。

动作状态

• 最小单位的构造块。
• 表达不可中断的动作或操作的执行
• 原子性，瞬时性

活动状态

• 拥有一组不可中断的动作或操作，表达一个非原子（可分）的运行。它的控制流由其他活动状态或动作状态组成。
• 活动状态可以有附加的部分，如指定入口动作、出口动作、动作状态以及内嵌状态机。
• 动作状态是活动状态的一个特例，如某活动状态只包括一个动作，那它就是一个动作状态

---

案例21：

请结合实际谈一谈

（1）在用例建模过程中，用例的粒度所代表的含义以及如何采用一定的粒度对用例进行分层？

（2）对于复杂的项目，用例的粒度应当如何划分，需要考虑哪些问题？

功能目标有大小，有些功能还会重复或重叠，有的是商业目标，有的是要构建系统的目标。为更好获取用例，建模时要考虑粒度

三个级别：概述级、用户目标级、子功能级

用例是一组用例实例的抽象；其内部要有路径，路径要有步骤

错误

• 粒度过细，陷入功能分解
• 把步骤当作用例
• 把系统活动当作用例

扩展实践案例（实际项目案例，来自知乎）

扩展案例1：

根据公司高层领导要求，该公司软件研发部开发了一个内部数据平台，用于集团内部的业务交流。

初期，研发部根据该领导的要求按进度完成了阶段目标，功能得到了认可，平台也小范围投入试运行，但使用率一直徘徊低位，领导对此不太满意。

随后，在每次项目例会上，该领导都会根据其他部门的反馈提出新的需求，并建议研发部需结合用户的满意度调查再提炼一下需求，确保平台使用率上升。

如果你是项目经理，你该如何应对？

【解决方案1】

“项目完成了阶段目标”，“功能得到了认可”，“小范围投入试运行”，“不断提出新的需求”，这个项目比较适合敏捷管理。起初的低使用率，不见得是坏事，恰好记录下来，观测一段时间后（例如几个月）的趋势变化。

这个项目开发的本身，既得到了认可，又低使用率。我认为是在帮助用户逐渐了解自己的需求。后续建议，对于每次例会都应及时反馈需求。

1、项目经理需要收集需求，排优先级，不能来了需求就做，越堆越多。

2、排出优先级后，找所有干系人，可以是客户的代表，来review需求，并渐进明细地让需求更加清晰和准确。

3、按照优先级，对高优先级的需求，进行估算和给计划，并迭代交付。其中，不明确的需求，不能作为高优先级需求来投入开发。只能对确定的需求来进行开发和交付。

【解决方案2】

读题理解这个项目的目标被分成了两部分，前期目标是开发一个内部平台，后期目标是提高使用率。前期如果需求搜集做的很充分，这两个部分连起来是很自然的事。

现在使用率很低，其它部门又总是对领导提要求。所以这个项目现在的目标是，怎么提高使用率？建议将关键干系人都找出来，重新搜集需求，并排序，考虑成本时间因素确定要怎么变更或升级。

【解决方案3】

建议从以下几个方面着手解决：

1、可以考虑给业务部门培训，增加用户对新系统的熟悉度和接受度，尽可能提高使用率，当然如果能配合制度就更好啦。因为一般大家喜欢用自己熟悉的系统或方法，培训可以带着大家熟悉起来，意识到优化点，逐渐就喜欢上了。如果新系统的确好用，管理层通过对流程的规定，来限制大家去使用，用上几天也就喜欢和习惯了。

2. 组织项目组再次和业务部门进行系统功能问题解析，可以用系统优化名义，一定要主动和热情积极，这样可以提高干系人参与度，也向业务部门和领导表达出项目组的重视度，也算提高影响力，并符合领导目标。

需要补充的是，收集的优化需求一定要有优先级，见效快且相对简单的功能尽快上线，这样才能提高使用率和口碑。