2026下半年系统分析师案例简答题合集

针对2026下半年系统分析师案例题怎么做？2026下半年系统分析师案例简答题有什么参考吗？的问题，希赛网为考生整理了一份2026下半年系统分析师案例简答题合集资料，希望能帮助到考生。因篇幅有限，本文只展示部分内容，考生可在本文文首本文资料处或文末的资料下载栏目下载PDF完整版。

2026下半年系统分析师案例简答题合集部分内容如下：

一、希赛计划开发一套在线学习管理系统，以满足学生在线学习、教师授课及管理员管理课程的需求。以下是该系统的部分需求描述：

（1）在线学习管理系统应包含课程管理、学生管理、教师授课、在线测试、学习进度跟踪和系统设置等功能模块。

（2）系统的用户角色包括学生、教师和系统管理员。所有用户在使用系统前需完成注册，注册方式可以选择邮箱注册或手机号注册。

（3）学生在进入在线学习或参加测试前，必须通过身份验证登录系统；教师可以发布课程资料、布置作业并在线答疑，但在发布课程资料时如果其中涉及一些敏感词则需经过管理员审核。

（4）系统管理员可以设置课程的上架与下架时间，当课程达到预设的下架时间时，系统自动将该课程从学习列表中移除，并向学生发送下架提醒。

（5）学习进度跟踪功能要求系统每天自动更新学生的学习进度，并在学生未完成当天学习任务时发送提醒。

【问题1】（10分）请简要叙述需求工程的活动主要被划分为哪几个阶段？

【问题2】（8分）在OOA方法中，会分别建立用例模型以及分析模型，请简单描述一下两个模型的建立过程。

【问题3】（7分）建立了用例模型后，可以利用用例之间的关系调整用例模型，用例之间的关系包括哪几种？对于每种关系，请根据题目中所描述的需求分别给出一组用例。

试题答案：

【问题1】（10分）

需求工程覆盖了体系结构设计之前的各项开发活动，主要包括分析客户要求、对未来系统的各项功能性及非功能性需求进行规格说明。需求工程的目标简单明了：确定客户需求，定义设想中系统的所有外部特征。需求工程的活动主要被划分为以下几个阶段：

(1)需求获取。通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

(2)需求分析。为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多地捕获现实世界的语义。

(3)形成需求规格(或称为需求文档化)。按照相关标准，生成需求模型的文档描述，用户的原始需求说明书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述

规约作为后续软件系统开发的指南。

(4)需求确认与验证。以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性

和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。

(5)需求管理。需求管理包括需求文档的追踪管理、变更控制、版本控制等管理性活动。

【问题2】（8分）

构建用例模型一般需要经历4个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等。

【问题3】（7分）

（1）用例之间的关系主要包括：包含关系、扩展关系、泛化关系。（1分）

（2）用例关系示例（每个2分）：

包含关系：“在线学习”用例包含“登录”用例。学生在进行在线学习之前，必须先登录系统。

扩展关系：“发布课程资料”用例跟“审核敏感词”用例为扩展关系。当教师发布课程资料时如果其中涉及一些敏感词时，需进行敏感词审核。

泛化关系：“用户注册”用例是“邮箱注册”和“手机号注册”用例的泛化。无论是通过邮箱还是手机号注册，都遵循相同的注册流程，但具体输入信息有所不同。这里，“用户注册”是抽象用例，“邮箱注册”和“手机号注册”是具体用例。

试题解析：

【问题1】

需求工程的活动主要被划分为以下几个阶段：

(1)需求获取。通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。

(2)需求分析。为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多地捕获现实世界的语义。

(3)形成需求规格(或称为需求文档化)。按照相关标准，生成需求模型的文档描述，用户的原始需求说明书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述

规约作为后续软件系统开发的指南。

(4)需求确认与验证。以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性

和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。

(5)需求管理。需求管理包括需求文档的追踪管理、变更控制、版本控制等管理性活动。软件需求开发的最终文档经过评审批准后，就定义了开发工作的需求基线(Baseline)。

这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定(Agreement)。需求约定是需求开发和需求管理之间的桥梁。

【问题2】在OOA方法中，构建用例模型一般需要经历4个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，其中前三个阶段是必需的。

（1）识别参与者。参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备，甚至是系统时钟。

（2）合并需求获得用例。将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。首先，要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏；其次，进行合并操作。在合并之前，要明确为什么要合并，知道了合并的目的，才可能选择正确的合并操作。合并后，将产生用例。将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架

（3）细化用例描述。用例建模的主要工作是书写用例规约(UseCaseSpecification)，而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流(基本事件流和扩展事件流)和后置条件等，其他的还可以包括非功能需求和用例优先级等。

（4）调整用例模型。在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。

分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。建立分析模型的过程大致包括定义概念类、确定类之间的关系、为类添加职责、建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(Class-Responsibity-Collaborator,CRC)建模。

【问题3】在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化，利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。

（1）包含关系。当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。

（2）扩展关系。如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。

（3）泛化关系。当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。