吉林大学软件需求与分析期末常考题型及答案

我是直接复制粘贴上来我做的笔记，很多图片都失效了。我也懒得重新上传了
想看完整版的可以直接下载这个PDF

============================================================================
2024.3.12更新，成绩出来了，按照这个复习，至少能90+。

一、单选

1、软件生产中产生需求问题的最大原因在于对应用软件的 ( C ) 理解不透彻或应用不坚决。
（A）复杂性（B）目的性 （C）模拟性（D）正确性
2、需求分析的目的是保证需求的（B ）。
（A）目的性和一致性 （B）完整性和一致性
（C）正确性和目的性 （D)完整性和目的性

3、系统需求开发的结果最终会写入（D ）。
（A）可行性研究报告 （B）前景和范围文档
（C）用户需求说明 （D）系统需求规格说明
4、解决问题必须涉及的（B）构成了问题解决的基本范围，称为该问题的问题域。
（A）属性和状态（B）事件和事物（C）实体和操作（D）状态和操作
5、功能需求通常分为三个层次，即业务需求、用户需求和（D）。
（A）硬件需求（B）软件需求 （C）质量属性 （D）系统需求

6、目前景和范围文档定义了系统的（B）
A、用户需求 B、业务需求 C 系统需求 D 软件需求
7、哪些不是需求管理阶段的主要任务 (D)
A、建立和维护需求基线集 B 建立和需求跟踪信息
C、进行变更控制 D、进行需求验证

8、以下哪个方法不是常用的模型驱动方法（D）。
A. 面向目标的方法 B.基于场景的方法
C.基于用例的方法 D.话语分析法
9、（B）方法在软件系统的很多开发阶段都起着十分重要的作用，其中就包括需求获取。在需求模糊和不确定性较大的情况下，该方法有其有效。
A．认知 B.原型 C. 集体获取 D. 模型驱动
10、以下哪个不是获取结束的依据（C）
A. 用户想不出更多的用例
B. 用户只是在重复已经讨论过的问题
C. 新提出的需求优先级都很高
D. 新提出的特性、需求都在项目范围之外

11、下列（D）不是需求获取常见的模型驱动方法？
（A）面向目标的方法 （B）基于场景的方法。
（C）基于用例的方法 （D）基于采样的方法
12、功能目标可以分为 (B)。
（A）安全目标和可用性目标 （B）满足型目标和信息型目标
（C）软目标和硬目标 （D）维护目标和实现目标
13、在表达软目标的分解和细化时使用的AND Contribution链接和OR Contribution链接，Contribution的作用是（C）。
（A）积极的 （B）消极的 （C）积极的或消极的（D）不能确定
14、AND链接将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细化的子目标，那么将（D）父目标。
（A）无法确定 （B）阻碍 （C）不能满足 （D）足以满足
15、OR链接是将一个父目标连接到一系列细化的子目标，意思是如果能够满足所有细化子目标中的（B），那么将足以满足父目标。
（A）每一个（B）任何一个 （C）特定的（D）某一个
16、下列选项中，（D）不是在目标模型中使用的其他模型元素。
（A）行为者 （B）场景 （C）操作 （D）概念
17、面向目标方法的目标分析阶段的主要任务是（C）。
（A）获取目标 （B）确定解决方案
（C）建立目标模型 （D）发现问题和缺陷
18、下列哪个不属于项目环境应该描述的内容：（ C ）
A、 操作环境 B、涉众 C、 业务目标 D、项目属性

19、下列（C）属于定量硬数据？
（A）工作手册 （B）规章手册 （C）统计报表 （D）备忘录
20、下列（D）属于定性硬数据？
（A）数据收集表 （B）月报表 （C）年报表 （D）规章手册

21、场景的分类框架将场景方法从场景的（A）4个方面进行了分类和描述。
（A）形式、目的、内容和生命周期 （B）外观、目的、内容和生命周期
（C）描述、目的、内容和形式 （D）描述、外观、目的和内容
22、场景的形式是指场景的表达模式，从形式上分为两个方面：（C）
（A）内容和目的（B）内容和生命周期（C）描述和外观（D）描述和目的
23、描述场景所使用的表示法要符合正规性要求，一般可使用非形式化语言、半形式化语言和形式化语言。在实践中，（B）是主要的描述方式。
（A）形式化的程序语言 （B）非形式化的自然语言
（C）形式化的图形工具 （D）非形式化的设计语言
24、外观是指场景被表达出来时的效果，主要有（ D ）三种类型。
（A）静态、动态和结构化 （B）线性、非线性和交互
（C）静态、动态和动静结合（D）静态、动态和交互
25、场景的内容是指场景所表达的知识类型。它被分为6个不同的方面。下列（C）不是场景的内容。
（A）主要关注点 （B）环境范围 （C）目的 （D）抽象层次
26、需求工程利用场景的目的可能有三种：即：（ A ）。
（A）描述、探索和解释 （B）描述、表示和探索
（C）描述、探索和发现 （D）表示、解释和证明
27、使用解释性场景在需求分析时能够（B），或者被用于进行需求的验证。
（A）提高模型的复杂性 （B）降低模型的复杂性
（C）提高预见性 （D）降低编程量
28、下列（B）不是场景方法在需求工程中的应用。
（A）帮助进行详细的需求分析
（B）编写系统需求规格说明
（C）结合面向目标的方法，指导需求获取活动的开展
（D）组织需求获取得到的信息
29、与其他的场景方法相比，用例最大的特点是采用了（C）的描述方式。
（A）静态非结构化文本 （B）动态非结构化文本
（C）静态结构化文本 （D）动态结构化文本
30、用例之间的关系主要有（D）三种。
（A）包含、扩展和简化 （B）合取、析取和扩展
（C）包含、多态和继承 （D）包含、扩展和泛化

31、下列哪种问题类型不推荐使用（B）
A.封闭式问题 B.双筒问题 C.程序性提示 D.探究式问题

32、按照使用方式进行分类，原型可分为：演示原型、（ D ）、试验原型和引示系统原型。
（A）非操作原型（B）系列首发原型
（C）选定特征原型（D）严格意义上的原型
33、按照开发方法进行分类，原型可分为：演化式原型和抛弃式原型，其中抛弃式原型又被细分为（ C ）。
（A）演示原型和试验原型 （B）系列首发原型和选定特征原型
（C）探索式原型和实验式原型 （D）样板原型和纸上向导原型
34、水平原型的关注的常见层次有3个：即（A）。
（A）人机交互、功能与任务和实现 （B）开发、实现和作用
（C）成本、技术和实现 （D）需求、作用和功能与任务

35、当用户无法完成主动的信息告知，或与需求工程师之间的语言交流无法产生有效的结果时，有必要采用（ B ）。
（A）民族志 （B）观察法 （C）话语分析 （D）任务分析

36、（B）是建模最为常用的两种手段。
（A）具体和抽象 （B）抽象和分解（C）分解和细化 （D）抽象和细化
37、抽象通过强调本质的特征，（D）了问题的复杂性。
（A）调整 （B）避免 （C）增加 （D）减少
38、需求分析仅仅需要描述解决方案，不需要探索实现细节的情况下，分析模型又是（ B ）的，尤为适用。
（A）形式化 （B）半形式化 （C）结构化 （D）非结构化
39、上下文图描述系统与环境中外部实体之间的界限和联系。它从现实世界的角度说明了系统的（ C ），并确定了所有的输入和输出。
（A）环境与外观 （B）边界和联系（C）边界和环境 （D）输入和输出
40、（A）是结构化分析方法的核心技术，它表明系统的输入、处理、存储和输出，以及它们如何在一起协调工作。
（A）数据流图DFD （B）实体联系图ERD （C）状态转换图（D）上下文图
41、结构化、信息工程和面向对象三种方法学下的需求分析技术都是（B）的。
（A）面向问题域 （B）面向解系统 （C）面向设计 （D）面向需求
42、使用面向问题的技术对问题世界的建模就被称为（A）需求阶段的分析。
（A）前期 （B）中期 （C）后期 （D）全过程
43、使用面向解系统的技术对软件系统解决方案的描述称为（C）需求阶段的分析。
（A）前期 （B）中期 （C）后期 （D）全过程
44、需求分析活动的一个重要任务是进行（ B ），明确用户需求的隐含信息，展开为明确的对软件系统的行为期望，即系统需求。
（A）需求整理 （B）需求细化 （C）需求获取 （D）需求分析

45、在分层结构中，DFD定义了三个层次类别的DFD图：（C）、0层图和N层图。
（A）1层图 （B）底层图 （C）上下文图（D）顶视图
46、因为数据存储是系统内部的功能实现，所以在将系统视为黑盒的情况下，上下文图中不会出现（B）。
（A）实体 （B）数据存储实例 （C）需求信息 （D）过程处理

47、数据建模技术能够弥补过程建模在 (C）方面的缺陷，它描述数据的定义、结构和关系等特性。
（A）需求分析 （B）数据转换 （C）数据说明（D）数据分析
48、概念实体是一种抽象概念，不考虑概念背后的物理存在，所以通常不包含与之相关联的其他（ B ）。
（A）模型 （B）特征（即属性） （C）关系 （D）处理
49、在ERD建模中，实体通常所指的就是（ A ）。
（A）逻辑实体 （B）概念实体 （C）物理实体 （D）进程实体
50、ERD中属性是实体的特征，不是数据。属性会以一定的形式存在，这种存在才是数据，被称为属性的（ D ）。
（A）域（B）实例 （C）说明 （D）值
51、ERD中关系的度数（Degree）是指参与关系的实体数量，是度量关系（ B）的一个指标。
（A）模型 （B）复杂度 （C）精确度 （D）属性值
52、ERD中关系的基数分为最大基数和最小基数。最大基数又被称为（A）。
（A）键约束 （B）参与约束（C）自然约束 （D）一般约束
53、在实体之间建立关系时，可能会产生一些附带的实体，被称为关联实体，最常见的形式是（ B ）。
（A）逻辑实体 （B）进程实体 （C）概念实体 （D）自然实体
54、在实现ERD与过程模型同步的技术中，（ C ）是一种较为常见的技术。
（A）用例图 （B）数据流图 （C）功能／实体矩阵 （D）微规格说明

55、下列（A）不是用例模型中的关系？
（A）属性 （B）关联 （C）泛化 （D）包含
56、系统边界是指一个系统所包含的系统成分与系统外事物的分界线。用例模型使用一个（D）来表示系统边界，以显示系统的上下文环境。
（A）圆形框 （B）菱形框 （C）虚线框 （D）矩形框

57、项目的前景和范围文档、用户需求文档都被视为属于（ D ），重点都是用户的现实世界。
（A）开发文档 （B）需求文档 （C）前景文档 （D）用户文档
58、系统需求规格说明文档、软件需求规格说明文档、硬件需求规格说明文档、接口需求规格说明文档和人机交互文档一起被用于系统开发的目的，都被认为是（A）。
（A）开发文档 （B）需求文档 （C）过程文档 （D）用户文档
59、下列（C）不是需求规格说明文档的读者？
（A）项目管理者 （B）编程人员 （C）销售商 （D）律师

二、多选

三、简答题

1.迷你超市

迷你超市的收银系统需求描述如下:
系统用户:超市经理和收银员
(1) 用户输入用户名和密码后可以登录系统;

(2) 用户登录后可以录入商品信息，商品信息包括商品编号、商品名称单价、生产日期、保质期、数量;

(3) 用户登录后可以进行收银业务，一次收银即为一次交易，扫描商品条码或者录入商品编号和数量后系统l动记录顾客购买商品，计算本次交易的总金额。顾客付款后，用户录入顾客付款金额，系统自动计算找零金额,用户确认后可以打印本次交易的清单(包括所有商品的名称、单价、数量、以及应付金额、实际付款金额、找零金页、交易时间等);

(4) 经理可以查询、修改和删除商品信息与交易信息；

(5) 系统能够提示所有过保质期的商品列表。

1.根据上述描述，为该系统绘制出0层数据流图和实体关系(E-R)图。

2.定义1个解释性场景、1个可替换场景、1个异常场景、1个负面场景和1个不当使用场景。

3.定义可能的上下文环境的四个刻面(要求针对该系统列举出四个刻面的实例，而不是列出四个刻面的定义)。

4…试为题2中的系统定义1个可靠性需求，1个可用性需求，1个易用性需求，2 个设计约束。

2. 场景定义

• 解释性场景：
  • 顾客购物完成后，收银员录入实际付款金额，系统计算找零金额并生成交易清单，包括所有商品的详细信息、应付金额、实际付款金额、找零金额、交易时间等。
• 可替换场景：
  • 顾客可以选择通过扫描商品条码或手动输入商品编号和数量进行购物，两种方式可以互相替换使用。
• 异常场景：
  • 在录入商品信息时，用户未填写必要的字段，系统显示错误提示，要求用户重新输入完整信息。
• 负面场景：
  • 用户在收银过程中错误录入实际付款金额，系统计算的找零金额不准确，导致顾客和收银员之间的不满。
• 不当使用场景：
  • 收银员试图删除已完成的交易信息，系统应当拒绝该操作并提供错误提示。

3.四个刻面

主体刻面：

• 主体： 超市经理、收银员、顾客。
• 关系：
  • 超市经理负责管理商品信息和交易记录。
  • 收银员负责录入商品信息、进行收银业务。
  • 顾客是购物主体，与系统进行商品购买交互。

使用刻面：

• 主体： 收银员、超市经理。
• 关系：
  • 收银员使用系统进行商品录入和收银操作。
  • 超市经理使用系统进行商品信息的查询、修改、删除。

IT系统刻面：

• 主体： 数据库管理系统、用户身份验证服务、计算找零算法。
• 关系：
  • 数据库管理系统存储商品信息和交易数据。
  • 用户身份验证服务用于用户登录验证。
  • 计算找零算法用于计算找零金额。

开发刻面：

• 主体： 系统开发人员、数据库管理员。
• 关系：
  • 系统开发人员负责开发和维护收银系统。
  • 数据库管理员负责管理系统所使用的数据库。

4. 系统需求

可靠性需求：

• 系统应能够保证每次交易的数据完整性，防止数据损坏或遗失。
• 系统在超市运营时间内，无失效运行的概率是90%。

可用性需求：

• 系统应在超市营业时间内的大部分时间内保持可用，确保收银业务的连续性。
• 系统实际可用且完全正常运行的时间占超市运营时间的90%。

易用性需求：

• 用户登录界面应简单直观，提供友好的用户界面，以确保用户容易学习和使用系统。
• 用户可以容易地登陆系统，进行收银的相关操作。

设计约束：

• 使用关系型数据库管理系统来存储商品信息和交易数据。
• 收银系统应能够适配常见的商品条形码扫描器和打印机设备。
• 对开放过程的约束：系统开发的工作量不能超过250h 人/月。
• 对系统的约束：两次扫码时间不超过2s。

2.需求是否存在问题

请指出下列求描述存在的问题，并进行适当的修改。
(1) 系统用户界面友好。
(2) 系统运行时应该占用尽量少的内存空间。
(3) ATM 系统需要快速响应用户的需求。
(4) 所有命令的响应时间小于1秒;BUILD 命令的相应时间小于5秒。
(5) ATM系统需要检验用户存取的合法性。

1. 系统用户界面友好。

   • 问题： 描述过于笼统，不清楚友好的具体含义。
   • 修改： 改为具体描述，例如：“系统用户界面应该采用直观、易于导航的设计，以确保用户能够轻松理解和完成操作。”

2. 系统运行时应该占用尽量少的内存空间。

   • 问题： 描述模糊，未定义"尽量少"是多少。
   • 修改： 指定具体的内存占用限制，例如：“系统运行时内存占用不应超过X兆字节。”

3. ATM系统需要快速响应用户的需求。

   • 问题： 描述过于一般化，未定义“快速”是多少。
   • 修改： 指定具体的响应时间目标，例如：“ATM系统应在用户输入请求后的X秒内提供响应。”

   5.ATM系统需要检验用户存取的合法性。

   • 问题： 描述过于抽象，未说明检验的具体方面。
   • 修改： 具体说明检验的合法性，例如：“ATM系统需要验证用户账户的有效性、密码的正确性，以及确保用户有权执行所请求的操作。”

3.考务系统

某考务系统的功能需求如下:

(1)系统采集考生的报名数并对其进行检查，对不符合报考条件的考生进行拒绝报名通知，合格报名数号将出系统进行保存，并在编排考生编号、考试时间及地点后为考生打印准考证;

(2)在考试结束后，系统向阅卷老师提供参加各科考试的考生名单，采集该科目的成绩信息，并对其进行检查，对两次输入不一致的成绩信息产生成绩错误通知，合格的成绩信息由系统进行保存；

(3)招生办依据由系统获得的考试成绩统计情况，在系统设定录取分数线，系统将结合考生报名信息绩信息完成录取审核，为达到录取标准的考生打印录取通知单，并为所有套加考试的考生打印成绩通知单；

(4)录取结束后，招生办可由系统获得录取情况的统计结果。

根据上述需求描述，给出该考务系统第0层数据流图的外部实体、数据加工(过程)和数据存储，并绘制出0层数据流图

试为上述考务系统定义1个解释性场景、1个可替换场景、1个异常场景、1个负面场景和1个不当使用场景。

试为上述考务系统定义可能的上下文环境的四个刻面（要求针对系统列举出四个刻面的实例，而不是列出四个刻面的定义）。

在第0层数据流图中，我们可以识别外部实体、数据加工（过程）和数据存储。下面是一个简化的描述：

• 外部实体：
  • 考生
  • 阅卷老师
  • 招生办
• 数据加工（过程）：
  • 报名处理
  • 阅卷处理
  • 录取处理
• 数据存储：
  • 报名数据
  • 成绩数据
  • 录取数据

场景定义：

1. 解释性场景：
   • 场景： 在报名截止后，系统自动对考生的报名信息进行检查，拒绝不符合报考条件的考生，并生成合格报名名单。系统自动编排考生编号，确定考试时间和地点，并为合格考生打印准考证。
   • 目的： 保证只有符合条件的考生被允许参加考试，并为他们提供必要的准考证信息。
2. 可替换场景：
   • 场景： 阅卷老师输入某科目的成绩信息时，系统检测到两次输入的成绩不一致，生成成绩错误通知，提示阅卷老师检查并核实成绩。
   • 目的： 确保输入的成绩信息准确，防止因输入错误导致的成绩混乱。
3. 异常场景：
   • 场景： 在录取审核过程中，系统发现某考生的报名信息和成绩信息存在矛盾，无法完成录取审核，生成异常通知。
   • 目的： 引起招生办的注意，需要手动处理异常情况，确保录取过程的准确性。
4. 负面场景：
   • 场景： 恶意用户试图通过非法手段修改他人的成绩信息，系统检测到并生成安全警报，同时拒绝修改请求。
   • 目的： 保障成绩数据的安全性，防止不当的修改行为。
5. 不当使用场景：
   • 场景： 一名考生试图多次报名，系统检测到并生成拒绝报名通知，禁止考生重复报名。
   • 目的： 防止考生滥用系统，确保公平的招生流程。

上下文环境的四个刻面的实例：

1. 主体刻面（Subject Matter Context）：

• 实例： 考生、阅卷老师、招生办工作人员

2. 使用刻面（Use Context）：

• 实例：
  • 考生使用系统进行报名、查询成绩和获取准考证；
  • 阅卷老师使用系统查看考生名单和录入成绩；
  • 招生办工作人员使用系统进行录取审核和统计分析。

3. IT系统刻面（IT System Context）：

• 实例：
  • 报名子系统：用于处理考生报名，保存合格报名信息；
  • 阅卷子系统：用于提供考生名单给阅卷老师，检查和保存成绩信息；
  • 录取子系统：用于完成录取审核，生成录取通知单和成绩通知单；
  • 统计子系统：用于提供录取情况的统计结果。

4. 开发刻面（Development Context）：

• 实例：
  • 软件开发团队：负责开发、测试和维护考务系统；
  • 数据库管理员：负责管理系统中的报名数据、成绩数据等信息；
  • 系统管理员：负责系统的部署、配置和维护；
  • 测试团队：负责进行系统测试和验证。

4.ATM机

假设你自己是ATM机的唯一用户
(1) 写出你对 ATM机系统的用户需求；
(2) 对 ATM 机系统，除功能性需求之外，还有哪些需求需要定义?

一一写出这些需求。

(1) 用户需求：

• 查询余额：能够查看当前账户的余额。
• 取款：能够从账户中取出现金，需要支持多种面额的钞票。
• 存款：能够向账户中存入现金或者支票。
• 转账：能够将钱款转账到其他账户。
• 交易记录查询：能够查看近期的交易记录。
• 修改密码：能够修改账户密码。

(2) 除功能性需求之外的其他需求：

• 可用性需求：ATM机应易于使用，界面友好，对于所有操作提供清晰的指导。
• 性能需求：ATM机在处理交易和请求时应具有高效率，响应时间短。
• 安全性需求：ATM机应具有强大的安全防护措施，保护用户信息和交易安全，防止非法访问和欺诈。
• 可靠性需求：ATM机应能在各种条件下稳定运行，包括电力中断、网络问题等情况。
• 兼容性需求：ATM机应能接受各种银行的银行卡。
• 无障碍需求：ATM机应考虑到残疾人的使用，比如设置语音提示、盲文标识等。

5.结构化需求分析与建模

请说明结构化需求分析与建模方法的主要思想

结构化需求分析与建模方法主要思想是将系统的需求和规格以一种结构化的方式进行表示和分析。这种方法强调将系统需求划分为较小、可管理的部分，然后对这些部分进行详细的分析和设计。以下是结构化需求分析与建模方法的主要思想：

1. 模块化： 结构化方法强调将系统划分为模块（也称为子系统、模块或过程）。每个模块都应该具有清晰的功能和职责，并且与其他模块有明确定义的接口。这有助于降低复杂性，使系统更易于理解和维护。
2. 层次化： 结构化方法采用层次化的组织结构，将系统划分为多个层次的模块。每个层次都关注特定的功能，且层次之间有清晰的依赖关系。这种层次化结构有助于管理系统的复杂性，同时也方便了分阶段的开发和测试。
3. 自顶向下分解： 结构化方法通常采用自顶向下的分解策略，即从整体系统开始，逐步分解为更小的子系统或模块。这种方法使得分析人员能够专注于高层次的概念和功能，然后逐步细化为更具体的细节。
4. 模块独立性： 结构化方法鼓励模块的独立性，即每个模块应该尽可能地与其他模块解耦。这有助于提高系统的灵活性和可维护性，因为对一个模块的修改不应该对其他模块造成不必要的影响。
5. 明确的接口： 结构化方法强调在模块之间定义清晰、明确的接口。这包括输入和输出的数据格式、调用的参数和返回值等。明确的接口有助于不同团队或开发者之间的协作，并降低了模块之间的耦合度。
6. 数据流和数据存储： 结构化方法使用数据流图和数据字典等工具，以图形化和标准化的方式表示系统的数据流和数据存储。这有助于分析人员更好地理解系统的数据处理和存储需求。

总体而言，结构化需求分析与建模方法的主要思想是通过模块化、层次化和自顶向下的分解来管理和理解系统的需求，以达到提高系统设计的可理解性、可维护性和可扩展性的目的。

6.图书管理系统

下面是一个简单图书管理系统的需求定义。
R1:一个简单图书馆系统，可以为读者提供如下服务：
1、查询图书馆资料情况；
2、借阅图书馆资料。
R2:系统必须由一名图书馆工作人员来作为系统管理员来管理，他可以对图书进行分类;
R3:读者必须先要想系统管理员在借阅之前登记注册；
R4:读者可以是学生、数工、外来读者；
R5:所有读者必须包含名字、图书证号、地址、账号信息；
R6:此外，在登记时还必须提供如下信息:
3、学生:学位类别和学生证号
4、教工:工作证号.
5、外来读者:单位详细信息
请说明如果对上面的需求定义实施面向对象需求分析与建模过程，那么
1.识别出的核心类有哪些?

2.这些类的属性及其关系如何?

3.每个类的操作有哪些?

对上面的需求定义进行面向对象需求分析与建模，可以识别出以下核心类：

1. 图书馆系统（LibrarySystem）类：
   • 属性：系统管理员、读者列表、图书列表
   • 操作：查询图书馆资料情况、借阅图书馆资料、管理员对图书分类、读者注册
2. 系统管理员（Administrator）类：
   • 属性：用户名、密码
   • 操作：对图书进行分类、读者注册
3. 读者（Reader）类：
   • 属性：名字、图书证号、地址、账号信息
   • 操作：查询图书馆资料情况、借阅图书馆资料
4. 学生（Student）类：
   • 属性（继承自读者类）：学位类别、学生证号
   • 操作：（继承自读者类的操作）
5. 教工（Faculty）类：
   • 属性（继承自读者类）：工作证号
   • 操作：（继承自读者类的操作）
6. 外来读者（ExternalReader）类：
   • 属性（继承自读者类）：单位详细信息
   • 操作：（继承自读者类的操作）

通过这些类，可以建立它们之间的关系：

• 图书馆系统（LibrarySystem）包含多个读者（Reader）和多本图书。
• 系统管理员（Administrator）负责对图书进行分类和管理读者的注册。
• 读者（Reader）可以是学生（Student）、教工（Faculty）或外来读者（ExternalReader），它们都继承自读者类。
• 学生（Student）、教工（Faculty）、外来读者（ExternalReader）都是读者（Reader），共享读者的基本属性和操作。

每个类的属性及其关系如下：

• 图书馆系统（LibrarySystem）类：
  • 属性：系统管理员（Administrator）、读者列表、图书列表
  • 关系：包含多个读者（Reader）和多本图书。
• 系统管理员（Administrator）类：
  • 属性：用户名、密码
  • 关系：负责对图书进行分类和管理读者的注册。
• 读者（Reader）类：
  • 属性：名字、图书证号、地址、账号信息
  • 关系：可以是学生（Student）、教工（Faculty）或外来读者（ExternalReader），继承自读者类。
• 学生（Student）类：
  • 属性（继承自读者类）：学位类别、学生证号
• 教工（Faculty）类：
  • 属性（继承自读者类）：工作证号
• 外来读者（ExternalReader）类：
  • 属性（继承自读者类）：单位详细信息

每个类的操作如下：

• 图书馆系统（LibrarySystem）类：
  • 查询图书馆资料情况
  • 借阅图书馆资料
• 系统管理员（Administrator）类：
  • 对图书进行分类
  • 读者注册
• 读者（Reader）类：
  • 查询图书馆资料情况
  • 借阅图书馆资料

7.选课系统UCSS

功能性需求定义：

1. 浏览课程信息：
   • 描述： 系统应提供学生浏览下一学期开放的课程信息的功能，包括课程名称、授课教师、上课时间和地点等详细信息。
   • 要求： 学生能够通过系统界面查看课程列表，获取关于每门课程的全面信息。
2. 选择课程并检查时间冲突：
   • 描述： 学生应能够通过系统选择自己感兴趣的课程，并在提交选课申请时，系统应对所选课程的上课时间进行检查，以确保选课过程中不存在时间冲突。
   • 要求： 如果所选课程之间存在时间冲突，系统应向学生发出提示“!”，并要求学生调整选课安排。

非功能性需求定义：

1. 用户友好性（Usability）：

   • 描述： 系统的界面应设计得用户友好，易于学生操作。用户应能够轻松地浏览课程信息、选择课程，并理解系统发出的提示信息。
   • 要求： 系统应符合直观的设计原则，提供清晰的导航和易于理解的界面，以促进用户学习和使用。

2. 性能要求（Performance）：

   • 描述： 系统应具有良好的性能，能够在选课高峰期快速响应学生的请求。此外，在课程时间冲突检查方面，系统应实时进行检查并迅速给出结果。
   • 要求： 系统响应时间应控制在2秒以内，确保在高峰期也能够快速处理学生的选课请求。时间冲突检查应在学生提交选课请求时立即执行，及时提供反馈。

学生实体属性：

1. 学生ID： 每个学生在系统中的唯一标识符。
2. 姓名： 学生的全名，包括姓和名。
3. 年级： 学生所属的年级或年级水平，如大一、大二等。
4. 专业： 学生所主修的专业或学科方向。
5. 选修课程列表： 学生当前已选修的课程列表。

课程实体属性：

1. 课程ID： 每门课程在系统中的唯一标识符。
2. 课程名称： 课程的名称或标题。
3. 授课教师： 负责教授该门课程的教师的姓名。
4. 上课时间： 课程安排的上课时间，可能包括具体的上课日期和时间段。
5. 课程容量： 课程所能容纳的学生人数上限。

分析和需求协商：

1. 需求描述 (1):
   • 描述： 学生在登录后，可以从列出的课程列表中任意选择多门课程作为下学期的课程。
   • 问题： 描述中存在模糊性，未明确学生可以选择的课程数量的上限。
   • 解决方案： 在描述中明确学生可以选择的最大课程数量，以防止歧义。例如，可以指定学生最多选择多少门课程。
2. 需求描述 (2):
   • 描述： 学生每学期至少要选5门课程，其中至少2门课程是必修课程。
   • 问题： 描述中存在二义性，未明确“至少2门课程是必修课程”是在5门课程中还是在所有选修课程中。
   • 解决方案： 为避免歧义，可以明确描述为：“学生每学期至少要选5门课程，其中至少2门课程是必修课程，这两门必修课程可以包含在5门选修课程中”。

重写需求描述：

1. 修订的需求描述 (1):
   • 描述： 学生在登录后，可以从列出的课程列表中选择多门课程，但最多不超过8门课程作为下学期的课程。
2. 修订的需求描述 (2):
   • 描述： 学生每学期至少要选5门课程，其中至少2门课程是必修课程。这两门必修课程可以包含在5门选修课程中，但不能全部为必修课程。

7.面向对象分析和建模过程

请针对下面待开发系统(简单图书馆系统)的描述，完成面向对象分析和建模过程，其中步骤.(e)只需要针对“借阅图书”和“查询图书”给出序列图。面向对象分析和建模通常包含如下步聚，

a) 在问题域确定核心类；

b)通过类图类之间的关系建模;

c)定义每个类的属性;

d)确定每个类的操作;

e)定义对象的行为以及对象间的信息传递(基于状态机、序列图等）

系统描述如下 一个简单图书馆系统，可以为读者提供如下服务:

• 查询图书馆资料情况
• 借阅图书馆资料

系统必须为一名图书馆工作人员作为系统管理员来管理，可以对图书进行分类;

读者在借阅之前必须先要向系统营理员登记注册;

读者可以是学生、教工、外来读者；

所有读者必须包含名字、图书证号、地址、账号信息;

此外，在登记时还必领提供如下信息:

• 学生:学院、学位类到和学生证号
• 教工:学院、工作证号
• 外来读者: 单位详细信息和身份证号

a) 在问题域确定核心类：

1. 图书馆（Library）
2. 系统管理员（Librarian）
3. 读者（Reader）
   • 学生（Student）
   • 教工（Faculty）
   • 外来读者（ExternalReader）
4. 图书（Book）

b) 通过类图类之间的关系建模：

• Library与Librarian之间是关联关系，表示一个图书馆由一个系统管理员管理。
• Library与Book之间是关联关系，表示图书馆拥有多本图书。
• Reader与Library之间是关联关系，表示读者与图书馆有关联，可能借阅图书。
• Student、Faculty、ExternalReader与Reader之间是继承关系，表示它们都是读者，但具有不同的属性。

c) 定义每个类的属性：

• Library: name, location
• Librarian: name, staffID
• Reader: name, libraryCardNumber, address, accountInfo
• Student: college, degreeCategory, studentID
• Faculty: college, staffID
• ExternalReader: organizationDetails, IDNumber
• Book: title, author, ISBN, genre, availabilityStatus

d) 确定每个类的操作：

• Library: searchBooks(), borrowBook(Book), registerReader(Reader)
• Librarian: manageBooks(), manageReaders()
• Reader: register(), borrowBook(Book), returnBook(Book), searchBooks()
• Book: checkAvailability()

e) 定义对象的行为以及对象间的信息传递（基于状态机、序列图等）： 对于“借阅图书”和“查询图书”，我们可以使用序列图表示对象间的交互。

借阅图书的序列图：

归还图书的序列图：

查询图书的序列图：

这两个序列图展示了系统管理员、图书馆、读者、图书之间的交互过程，以及相应的消息传递和操作。

8.需求工程的活动

简述需求工程包含哪些基本活动?每一项活动的主要任务是什么?

需求工程分为需求开发和需求管理两个部分,而需求开发又可进一步分为需求获取、需求分析、规格说明和需求验证四个阶段。这些基本活动的主要任务包括:

(1) 需求定义:定义项目的业务需求，明确项目的目标和范围。

(2) 需求获取:采集、识别和提取用户的需求,对问题和需求形成文档化的描述,使各种人员达成一致的理解和认可。确定用户需要

(3) 需求分析和建模:分析和综合所采集的信息,建立系统的详细逻辑模型。确定软件系统功能

(4) 需求规格说明:编写软件需求规格说明书,明确、完整和准确地描述已确定的需求。确定需求基线

(5) 需求验证:评审软件需求规格说明,以保证其正确性、一致性、完备性、准确性和清晰性。确保需求规格说明准确、完整地表达用户需要

(6) 需求管理:定义需求基线,在整个项目过程中跟踪需求状态及其变更情况。维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其他需求和其他项目工作之间的可追踪性

9.简答

1.常见的需求制品

常见的需求制品包括需求规格说明书、用户故事、用例、原型图、流程图、思维导图等。

2.举例说明质量属性包含哪些类别？

3.需求冲突是否是可以避免的？

需求冲突是无法完全避免的。

在软件开发过程中，由于涉及到多个利益相关方，他们有不同的关注点和期望，因此冲突和问题常常出现。例如，用户和开发人员之间的需求理解差异、不同部门之间的资源分配争执等。

然而，通过有效的沟通、采用版本控制系统、调整项目管理方式以及培养开发者能力等方法，可以有效地解决各种问题，维护软件开发进程和产品质量。

同时，团队内部的人际冲突也是软件开发过程中常见的冲突之一。这类冲突通常是因为开发者之间的观念差异、工作方式不同或对任务优先级的理解不同等原因引起的。为了处理这类冲突，需要采用平等和公正的方式来解决，多听取不同观点、寻找共同点并寻求共同的解决办法！

4.请解释需求分析与需求工程之间的关系

需求分析是软件开发过程的初始阶段，侧重于理解和定义系统需求；而需求工程是软件工程的整个生命周期的一个阶段，包括需求分析在内，致力于整个开发过程中的需求管理、变更控制和验证确认。需求分析为需求工程奠定基础，而需求工程确保在整个软件开发过程中满足用户需求。

5.请列举4种可能的需求获取信息源以及该种信息源对应的需求获取技术。

1. • 信息源： 最直接的需求获取信息源是系统的最终用户。用户通常能够提供对系统功能和性能的直接期望。
   • 需求获取技术： 采用面对面的访谈、问卷调查、焦点小组讨论等技术，以直接与用户交流、收集他们的需求和反馈。
2. 利益相关者：
   • 信息源： 利益相关者包括项目经理、客户、业务分析师等，他们对系统的成功实施和满足业务目标有关切。
   • 需求获取技术： 利用工作坊、会议、协作工具等形式，与利益相关者深入讨论、确认需求，确保系统对他们的期望进行了充分考虑。
3. 文档和现有系统：
   • 信息源： 现有文档、报告以及已经存在的系统可能包含了关于业务流程和需求的重要信息。
   • 需求获取技术： 进行文档分析、系统审查，以了解和提取现有文档和系统中的关键需求信息。
4. 竞争对手和市场调研：
   • 信息源： 通过对竞争对手和市场进行调研，可以获取关于行业标准、趋势和市场需求的信息。
   • 需求获取技术： 进行市场调查、竞品分析，以了解行业标准，预测未来趋势，确保系统在市场上具有竞争力。

6.请指出需求分析阶段需要执行哪些活动？

1. 需求识别： 识别项目的背景、目标、范围以及相关的利益相关者。明确项目的基本方向和关键约束。
2. 需求收集： 通过面对面的访谈、问卷调查、观察等方式，与用户和利益相关者沟通，收集他们的需求和期望。
3. 需求分析和整理： 对收集到的需求进行分析，区分功能性需求和非功能性需求，理清需求之间的优先级和关系。整理需求，确保其一致性和完整性。
4. 需求建模： 使用不同的建模技术，如用例图、活动图、时序图等，对需求进行图形化的表示，以更好地理解系统的行为和交互。
5. 原型开发： 创建初步的软件原型，用于演示系统的基本功能和界面，以便用户更好地理解和反馈。
6. 验证和确认： 与用户和利益相关者一起验证和确认需求，确保它们准确地反映了用户的期望，并且可以满足项目的目标。
7. 需求规格书编写： 撰写详细的需求规格书，将需求以清晰、明确、可验证的方式记录下来，成为后续开发的依据。
8. 变更管理： 建立变更管理机制，以便在需求分析阶段发现的变更能够被妥善管理，确保变更的影响得到适当评估和控制。

7.请指出需求规格说明有哪些描述手段？在实践中应怎样结合运用它们？

需求规格说明是对系统需求的详细描述，为软件开发提供了指导。在实践中，需求规格说明可以通过以下描述手段进行表达和记录，并常常结合运用它们：

1. 自然语言描述： 使用自然语言，例如英语，对需求进行详细的文字描述。这是最直观和常见的描述手段，但需要确保描述准确、清晰，避免歧义。
2. 用例描述： 用例描述是一种通过场景和交互来说明系统如何满足用户需求的方法。用例通常包括主要参与者、前提条件、触发事件、主要流程和替代流程等元素。
3. 流程图： 使用流程图，如流程图、活动图，展示系统中各个模块之间的交互和信息流动。流程图能够直观地呈现系统的流程和控制逻辑。
4. 状态图： 描述系统中对象的状态及其状态之间的转换。状态图有助于理解系统在不同情境下的行为。
5. 数据模型： 使用数据模型，如实体关系图，描述系统中的数据结构和数据之间的关系。这对数据库设计和数据管理非常有帮助。
6. 原型： 创建原型，即系统的简化版本，用于演示和验证特定功能。原型可以是界面原型、交互原型等，有助于用户更好地理解和确认需求。
7. 可追溯性矩阵： 创建可追溯性矩阵，将每个需求与相关的设计、开发、测试等活动关联起来，确保每个需求都能够被追踪到项目的各个阶段。

8.请指出需求管理中的4个活动及其主要任务

需求管理是确保需求在整个软件开发生命周期中被有效管理和满足的过程。以下是需求管理中的四个主要活动及其主要任务：

1. 需求识别与收集：
   • 主要任务： 识别和收集与项目相关的所有需求。这包括与利益相关者的沟通，收集用户需求、系统需求以及任何其他与项目成功实施相关的需求。任务还包括确保需求是明确、一致且完整的。
2. 需求分析与规格：
   • 主要任务： 对收集到的需求进行深入分析，并将其规范化为清晰、详细的需求规格。这可能涉及需求建模、用例分析、需求分解等技术。目标是确保需求能够为后续的设计和开发提供详尽的指导。
3. 需求变更管理：
   • 主要任务： 管理需求变更的过程。这包括对提出的需求变更进行评估，了解变更对项目进度、成本和风险的影响，并决定是否接受或拒绝变更。任务还包括确保变更的记录和追踪。
4. 需求验证与确认：
   • 主要任务： 与项目的利益相关者合作，验证和确认需求规格是否准确地捕捉了他们的期望。这可能涉及原型演示、用户验收测试、系统测试等活动。目标是确保系统按照用户需求和规格要求进行开发。

9.请说明需求验证和需求确认之间的区别，并列举常用的需求验证和确认技术

需求验证和需求确认 是需求管理过程中的两个关键步骤，它们有不同的焦点和目标：

1. 需求验证：
   • 定义： 需求验证是确保项目团队理解并正确实现了用户需求的过程。验证的目的是确保系统开发的产品符合用户的期望，即系统是否满足了最初定义的需求。
   • 焦点： 焦点在于验证开发的系统是否正确地满足了用户和利益相关者的需求，强调的是开发的产品与规格和期望的一致性。
   • 技术： 常用的验证技术包括用户验收测试、系统测试、集成测试、性能测试等。
2. 需求确认：
   • 定义： 需求确认是确保项目团队正确理解并正确地记录了用户需求的过程。确认的目的是确保需求规格书（或其他需求文档）准确地反映了用户和利益相关者的期望。
   • 焦点： 焦点在于确认需求文档是否准确地捕捉了用户需求，即需求规格书是否是一个正确的、一致的、可验证的文档。
   • 技术： 常用的确认技术包括需求审查、原型演示、面对面的用户反馈等。

常用的需求验证和确认技术包括：

1. 用户验收测试（UAT）： 在系统交付之前，由最终用户执行的测试，以确认系统是否符合他们的期望。
2. 系统测试： 对整个系统进行测试，以验证其是否满足需求规格书中定义的各项功能和性能要求。
3. 集成测试： 针对系统中不同组件的集成进行测试，确保各组件能够协同工作以实现整体功能。
4. 性能测试： 测试系统在不同负载和条件下的性能，确保其在实际使用情境中能够满足性能需求。
5. 需求审查： 通过会议或其他合作方式，项目团队和利益相关者一起审查需求规格书，确保其准确、一致，并得到共识。
6. 原型演示： 创建系统的简化版本，用于演示和验证特定功能，以确保用户需求得到正确理解。

10.一般地，软件生命周期包含几个阶段？

软件生命周期通常包含以下几个阶段：

1. 需求分析阶段： 在这个阶段，团队与利益相关者沟通，收集并分析系统的需求。目标是明确定义系统的功能、性能和约束。
2. 设计阶段： 在需求分析的基础上，进行系统的总体和详细设计。包括定义系统架构、模块划分、数据库设计等。
3. 实施（编码）阶段： 在设计完成后，开发团队开始编写源代码，实现系统的各个模块和功能。这是软件生命周期中的具体编码和实现阶段。
4. 测试阶段： 完成编码后，进行系统测试，验证软件是否符合需求规格书中的要求。测试包括单元测试、集成测试、系统测试和用户验收测试等。
5. 部署阶段： 在测试通过后，将软件部署到目标环境中，使其可以供最终用户或客户使用。
6. 维护阶段： 软件交付后，需要进行维护工作，包括修复错误、更新功能、适应新的环境等。维护阶段可能会持续很长时间，特别是对于大型和长寿命的软件项目。

11.请给出软件需求的定义

软件需求是对计算机软件系统或应用程序所需功能、性能、约束和其他特性的详细描述。需求是对系统应该如何工作、执行什么任务以及对其性能和限制等方面的规范。软件需求通常分为功能性需求和非功能性需求两大类。**

1. 功能性需求： 描述了软件系统应该提供的具体功能、服务或操作。这包括用户的交互、数据处理、算法实现等。功能性需求是用户和开发团队之间沟通的核心，为开发人员提供了构建软件系统的基本指导。
2. 非功能性需求： 描述了软件系统的质量属性、性能特征、约束和其他与系统功能无直接关系的方面。非功能性需求包括性能要求、可靠性、可维护性、安全性、可用性、兼容性等。

12.请出软件需求的分类

软件需求可以分为多个类别，其中最常见的分类方式包括以下两大类：

1. 功能性需求：
   • 描述了系统应该提供的具体功能、服务或操作。这些需求定义了软件系统应该如何响应用户的输入，以及执行哪些任务。
   • 例子：用户登录、数据输入、查询和报告生成等功能。
2. 非功能性需求：
   • 描述了软件系统的质量属性、性能特征、约束和其他与系统功能无直接关系的方面。这些需求通常关注软件系统的性能、可用性、安全性等方面。
   • 例子：
     • 性能要求： 响应时间、吞吐量等。
     • 可靠性： 系统的可靠性和容错性。
     • 可维护性： 系统易于维护和更新的能力。
     • 安全性： 系统保护数据和资源的能力。
     • 可用性： 系统可用性和可访问性。

除了这两大类之外，需求还可以进一步细分为其他子类，以更详细地描述系统的各个方面。例如：

1. 性能需求：
   • 描述了系统对性能方面的要求，包括响应时间、吞吐量、资源利用率等。
2. 可靠性需求：
   • 描述了系统的可靠性、可用性和容错性等方面的要求。
3. 安全性需求：
   • 描述了系统如何保护数据、防止未经授权的访问等安全方面的要求。
4. 可维护性需求：
   • 描述了系统易于维护和更新的要求，包括代码可读性、模块化等方面的要求。
5. 兼容性需求：
   • 描述了系统与其他系统、硬件或软件的兼容性要求。
6. 法规和标准性需求：
   • 描述了系统需要符合的法规和标准，如隐私法规、安全标准等。

13.请列举三种需求获取方法，说明每种方法的适用情形

需求获取是软件开发中的重要活动，有多种方法可用于获取用户和利益相关者的需求。以下是三种常用的需求获取方法及其适用情况：

1. 面对面访谈：
   • 适用情况： 面对面访谈适用于需要深入理解用户需求、获取详细信息、澄清疑虑或解决复杂问题的情况。这种方法在项目初期、需求不明确或变化频繁时尤为有效。
   • 优势： 提供直接的交流渠道，使分析师能够深入了解用户的期望和需求，便于即时的反馈和澄清。
2. 问卷调查：
   • 适用情况： 问卷调查适用于大规模用户群体或利益相关者的需求获取。它可以用于快速收集广泛的观点，特别是在需求相对稳定、主要涉及到一般性信息的情况下。
   • 优势： 能够迅速收集大量信息，对于覆盖面广、相对标准化的问题非常有效。同时，问卷调查也有助于保护用户的隐私。
3. 原型演示：
   • 适用情况： 原型演示适用于需要通过可视化方式展示系统功能，获取用户对系统界面和交互的反馈的情况。这种方法在强调用户体验、界面设计的项目中非常有用。
   • 优势： 允许用户直接与系统的简化版本进行互动，能够更好地理解用户的期望，发现潜在问题，并在早期阶段进行调整。

14.请列举需求规范说明的定义方式有哪些

需求规格说明是对软件系统需求的详细描述，可以使用不同的定义方式来记录和表达这些需求。以下是几种需求规格说明的定义方式：

1. 自然语言描述： 最直接的方式是使用自然语言，例如英语，对需求进行详细的文字描述。这种方式简单直观，易于理解，但可能存在歧义，需要确保描述准确、清晰。
2. 用例描述： 使用用例来描述系统的功能需求。用例是一种通过场景和交互来说明系统如何满足用户需求的方法。用例通常包括主要参与者、前提条件、触发事件、主要流程和替代流程等元素。
3. 流程图： 使用流程图，如流程图、活动图，展示系统中各个模块之间的交互和信息流动。流程图能够直观地呈现系统的流程和控制逻辑。
4. 状态图： 使用状态图描述系统中对象的状态及其状态之间的转换。状态图有助于理解系统在不同情境下的行为。
5. 数据模型： 使用数据模型，如实体关系图，描述系统中的数据结构和数据之间的关系。这对数据库设计和数据管理非常有帮助。
6. 原型： 创建原型，即系统的简化版本，用于演示和验证特定功能。原型可以是界面原型、交互原型等，有助于用户更好地理解和确认需求。
7. 形式化规约： 使用数学或形式化语言进行规约，如Z语言、表达式语言等。形式化规约更具精确性，减少了歧义，但可能较为抽象和难以理解。
8. 需求模型： 使用需求建模工具，如Rational Rose、Enterprise Architect等，建立可视化的需求模型，包括用例图、类图、时序图等。

15.请阐运需求验证和确认的含义。
需求验证和需求确认是软件工程中两个关键的活动，它们有不同的焦点和目标：

1. 需求验证（Requirement Validation）：
   • 含义： 需求验证是确保开发的系统满足用户和利益相关者需求的过程。在这个过程中，团队核实系统的设计和实现是否正确地满足了最初定义的需求。
   • 重点： 验证关注的是“我们构建的系统是正确的吗？”验证确保系统按照用户需求的期望进行开发，强调的是系统的功能和性能是否达到规定的标准。
2. 需求确认（Requirement Confirmation）：
   • 含义： 需求确认是确保需求文档准确地反映了用户和利益相关者的期望的过程。在这个过程中，团队核实需求文档是否清晰、完整，是否正确地捕捉了所有的用户需求。
   • 重点： 确认关注的是“我们理解的用户需求是正确的吗？”确认确保需求文档是可靠的，准确地反映了用户和利益相关者的期望，强调的是需求文档是否与真实需求一致。

16.需求管理主要包括版本控制、需求变更管理、需求追踪和需求状态追踪等四个主要部分，请说明每个主要部分的作用是什么？

需求管理主要包括版本控制、需求变更管理、需求追踪和需求状态追踪等四个主要部分，每个部分的作用如下：

1. 版本控制：
   • 作用： 管理需求的不同版本，确保对需求的修改和演进进行追踪和记录。版本控制有助于跟踪需求的历史变更，追溯不同阶段的需求文档，以及确保团队在任何时候都能够回溯到特定的需求状态。
   • 重要性： 版本控制对于保持需求的一致性、完整性和可追溯性非常重要。它确保团队能够了解需求是如何发展和变化的，有助于降低需求管理过程中的混淆和错误。
2. 需求变更管理：
   • 作用： 管理需求变更的请求、评估和实施。需求变更管理帮助团队处理由于变化请求引起的需求修改，确保变更是经过充分评估和控制的，以减小变更可能带来的负面影响。
   • 重要性： 需求变更是项目中常见的现象，它们可以来自用户的新需求、问题修复、业务变化等。通过有效的需求变更管理，可以保持项目的稳定性和可控性。
3. 需求追踪：
   • 作用： 确保每个需求都能够被追踪到相应的设计、开发和测试工作。需求追踪有助于确保项目团队了解每个需求的状态，以及需求是否已经得到满足或实现。
   • 重要性： 需求追踪有助于保持团队对需求的清晰认识，确保每个需求都得到了适当的关注和处理。它也有助于验证项目是否按照计划和规格要求进行。
4. 需求状态追踪：
   • 作用： 跟踪每个需求的当前状态，例如“已确认”、“开发中”、“测试中”、“已实施”等。需求状态追踪有助于了解每个需求在整个开发过程中的位置，以及其当前的处理状态。
   • 重要性： 需求状态追踪提供了一个实时的、可视化的需求管理视图。它有助于团队协调工作、识别可能的瓶颈和优化开发流程。

这四个主要部分共同构成了一个完整的需求管理体系，为项目团队提供了工具和方法，以确保需求在整个软件开发生命周期中得到有效的管理和满足。

17.请说明需求状态追踪和需求追踪的区别。

需求状态追踪和需求追踪是需求管理中两个不同但相关的概念：

1. 需求状态追踪：
   • 定义： 需求状态追踪是跟踪每个需求的当前状态，通常通过定义一组可能的状态来表示需求的生命周期阶段，例如“已确认”、“开发中”、“测试中”、“已实施”等。
   • 目的： 主要用于了解每个需求在整个开发过程中的位置，以及其当前的处理状态。状态追踪提供了一个实时的、可视化的需求管理视图，有助于团队协调工作、识别可能的瓶颈和优化开发流程。
2. 需求追踪：
   • 定义： 需求追踪是确保每个需求都能够被追踪到相应的设计、开发和测试工作。它关注的是需求之间的关系，以及需求的来源和实现。追踪确保每个需求都得到了适当的关注和处理。
   • 目的： 主要用于保持团队对需求的清晰认识，以及验证项目是否按照计划和规格要求进行。需求追踪有助于团队了解需求的实现状态，追溯需求的变更历史，以及确认每个需求是否已经得到满足或实现。

区别：

• 焦点不同： 需求状态追踪关注需求的当前处理状态，而需求追踪关注需求之间的关系和实现情况。
• 内容不同： 需求状态追踪通常包括状态的定义和更新，而需求追踪包括需求之间的依赖关系、变更历史等信息。
• 用途不同： 需求状态追踪主要用于项目团队内部协调和可视化需求处理情况，而需求追踪更侧重于确保需求的完整性和追踪需求的实现情况。

18.请从在软件工程、软件项目成败和软件质量保证等方面的地位和作用来说明“需求工程的重要性”

需求工程的重要性在软件工程、软件项目成败以及软件质量保证等方面都是至关重要的。以下是对这些方面的说明：

1. 在软件工程中的地位和作用：
   • 需求工程是软件工程的基石： 需求工程是软件工程过程中的第一步，为整个软件开发生命周期提供了基础。它确定了系统应该具备的功能、性能和约束，为后续的设计、开发、测试和维护工作提供了明确的指导。
   • 确保需求清晰明确： 需求工程帮助识别和澄清用户和利益相关者的期望，确保需求以一种清晰、明确、无歧义的方式被捕捉和记录。这有助于避免后续阶段因为需求理解不同而引发的问题。
2. 在软件项目成败中的作用：
   • 需求错误是项目失败的主要原因之一： 许多软件项目的失败与需求相关的问题有关。需求不明确、不完整或不一致可能导致开发出的系统无法满足用户需求，从而影响项目的成功。需求工程的目标是降低这类风险。
   • 提高项目预测性： 需求工程有助于提高对项目的预测性，通过确保在项目开始时明确定义和理解需求，可以更准确地估算成本、进度和资源需求。
3. 在软件质量保证中的作用：
   • 质量从需求开始： 软件质量的关键在于需求的质量。如果需求不清晰、不完整或不准确，那么即使后续的开发工作再出色，最终的软件产品也可能无法满足用户期望。需求工程在软件质量保证中扮演着确保基础工作质量的角色。
   • 需求跟踪和变更管理： 需求工程通过需求跟踪和变更管理确保在整个开发过程中需求的一致性和完整性。这有助于防止在后续阶段引入不一致的需求变更，从而提高软件的质量和可维护性。

19.通常可以将需求规格说明表示方式分为非形式化、半形式化和形式化三种形式，请从表现形式、可读性、严格性、易解释性、可验证性等方面比较这三种形式。

需求规格说明的表示方式可以分为非形式化、半形式化和形式化三种形式，它们在表现形式、可读性、严格性、易解释性和可验证性等方面有不同的特点：

1. 非形式化表示方式：
   • 表现形式： 自然语言、文字描述。
   • 可读性： 相对较高，因为使用了通用的自然语言，更容易为非技术人员理解。
   • 严格性： 相对较低，容易存在歧义和理解差异。
   • 易解释性： 相对较高，由于使用了常见的语言，利益相关者更容易理解需求。
   • 可验证性： 相对较低，由于表达方式较为灵活，难以确保每个需求都可以被明确定义和验证。
2. 半形式化表示方式：
   • 表现形式： 使用图表、表格、用例等结构化的方式，但依然包含自然语言描述。
   • 可读性： 介于非形式化和形式化之间，图表和表格提高了一定的结构性，但仍包含自然语言描述。
   • 严格性： 相对较高，结构化的表示方式减少了歧义，但自然语言描述可能仍存在一定程度的模糊性。
   • 易解释性： 介于非形式化和形式化之间，结构化的表示方式提高了理解的一致性。
   • 可验证性： 相对较高，通过图表、表格等结构化方式，可以更容易地进行验证和审查。
3. 形式化表示方式：
   • 表现形式： 使用形式化语言、数学符号或形式化描述工具，如Z语言、规约语言等。
   • 可读性： 相对较低，通常需要专业的培训和技术背景，不太适用于非技术人员。
   • 严格性： 相对较高，形式化语言提供了严格的语法和语义，减少了歧义。
   • 易解释性： 相对较低，需要具备一定的形式化方法和数学知识，可能不易理解。
   • 可验证性： 相对较高，由于具有精确的语法和语义，可以进行更系统和精确的验证。

20.“分析已有系统”和“原型系统”是两种重要的需求获取技术，请说明这两种方法分别适用于哪些情形？

"分析已有系统"和"原型系统"是两种不同的需求获取技术，它们在不同的情形下具有各自的适用性：

1. 分析已有系统：
   • 适用情形：
     • 当已经存在一个现有系统，需要对其进行升级、扩展或维护时，分析已有系统是一种常用的需求获取技术。
     • 在进行系统改进、优化或迁移时，通过分析已有系统，可以深入了解当前系统的功能、性能、限制和问题。
   • 优势：
     • 提供了对现有系统的详细了解，包括业务流程、数据结构、系统交互等方面的信息。
     • 可以基于已有系统的经验教训，识别出潜在的改进和优化点。
   • 注意事项：
     • 对于过时、复杂或文档不足的系统，可能需要花费更多的时间和精力来理解和分析。
2. 原型系统：
   • 适用情形：
     • 当用户对系统的外观、界面和交互有特定期望时，原型系统是一种有效的需求获取技术。
     • 在需求不明确或变化频繁的情况下，通过创建原型系统，可以快速演示和验证系统的特定方面，以便及时调整需求。
   • 优势：
     • 提供了可视化的演示，帮助用户更好地理解系统的外观和交互。
     • 可以及时获得用户反馈，减少后续阶段的需求变更风险。
   • 注意事项：
     • 原型系统通常不包含完整的功能和性能，仅用于演示和验证特定方面，可能需要后续的系统开发来实现完整的功能。

21.请列出一个在线订购系统的所有可能的涉众（至少四个）

在线订购系统涉及多个利益相关者，也称为涉众。以下是一个在线订购系统可能涉及的四个主要涉众：

1. 顾客（End Users）：
   • 角色： 最终使用系统进行商品或服务订购的个人或组织。
   • 期望： 期望系统提供直观、易用的界面，支持安全、方便的购物体验，并提供订单跟踪和支付选项。
2. 商家（Merchants）：
   • 角色： 提供商品或服务的个人、公司或组织。
   • 期望： 期望系统提供商家管理界面，支持商品管理、订单处理、库存管理等功能，并能够与支付系统和配送服务集成。
3. 系统管理员（System Administrators）：
   • 角色： 管理在线订购系统的技术人员。
   • 期望： 负责系统的配置、维护、监控和安全性。期望系统提供可视化的管理工具、日志记录和安全性管理功能。
4. 支付服务提供商（Payment Service Providers）：
   • 角色： 处理在线支付交易的第三方服务提供商。
   • 期望： 期望系统集成其支付服务，确保支付流程安全、可靠，并支持不同的支付方式和货币。

重点

1.概念

我听到或者说看到这个概念，我我立马就知道是什么意思，能够去理解它的这样一个含义，这是第一点，就是对于基本概念的理解，最起码它代表什么含义，这个了解清楚。什么是需求，什么是问题，写系统什么是业务需求，什么是用户需求，系统需求，仕途，愿景，范围呀，边界呀，特征。然后这个场景的各种分类情况，每一个场景它代表什么样的一个含义呀？什么是原型，原型有哪些类别，然后在系统建模的时候，有功能视图，数据视图，行为视图。它们分别去来展现系统的哪方面的这个信息，然后比如说这个结构化建模的时候，它有这个数据流图，有实体关系图，状态图，那么它们分别。这个这个图是用来去对于系统的哪方面去进行建模，那么建模的要素有哪些这些你你你都要去掌握就是对于这个一体。你就知道，就是对它的这个基础知识要有掌握，然后再比如说我们在建这个数据流图的时候，我们说是其实它是基于这个业务事件去画出来的，那么业务事件有哪些的类别，比如说。它有外部事件，有临时事件，有状态事件，那什么样的事件叫外部事件，什么样的事件叫临时事件，什么样的事件叫状态事件？那这些你就要去了解清楚，然后。再比如说面向对象建模的时候，要用到类图，用力图，顺序图，活动图那么他们分别对系统的哪一方面去进行这个建模建模的要素有哪些这是基基础知识。

需求文档和需求规范说明有什么区别？

语言的这个二义性有哪些？容易区分为几个。类别，有词法上的二义性，语法上的二义性，名义上的这个二义性。

Z规范说明它里面包含有状态模式、有操作模式。

Tabular表达式，它里面有这样几个表，我们介绍的，要求大家掌握的这几个表

自变量模型，比如说有这四类的变量，分别代表的是什么样的含义；各类关系，它又是分别代表什么样的一个含义，

需求验证和确认，这两个概念有什么样的一个区别，需求配置和需求基建有什么样的一个区别，就是这样，你知道它。代表什么含义，然后又和它相近的概念之间，你你怎么给它区分这样你就达到了一个掌握的程度，这是基本概念。

第二点，需求，涉及到很多的这样一个活动，每一个活动他做要做要完成什么样的一个任务。他的输入和输出是什么，那么在这个活动的过程当中，他面临的这种困难，或者说他要解决的问题是什么，我们用什么样的一个方法技术、工具把这样一些问题去解决了。

需求分析和建模。输入：需求获取那些获取记录给它原始的需求获取记录作为需求分析活动的输入。输出：就是建立了各种需求分析的模型。活动的内容和实施过程：按照那个需求获取记录，你去读这个获取记录，就理解这个需求，不明白，不清楚的地方就给它澄清，澄清完了把这个需求和需求之间的关系按照某种模型去给它展现出来，就建模了，那这个，就是这个活动它实施的过程。那具体活。就是过程当中可能会用到一些技术，那需求分析和建模里面用到的技术是什么呀？是不是一个就是结构化的分析和建模的技术，一个是面向对象的分析和建模的技术，那你还要接着再了解。什么结构化的分析和建模，它的思想是什么？过程是什么，它建的模型有哪些，或者是建模的工具有哪些，然后面向对象的它的思想是什么，那么它的这个建模过程是。怎样的，他用建出来是什么样的一些模型，怎么建模就是就是这样，你就捋一捋这个相关的这个知识点，那么因为我们说包含很多的活动。

与或树与或图，这个目标模型它。比如说这IC框架k of框架，它俩有什么区别呀，然后你在问题分析的时候用到鱼骨图，哈雷托图，那它俩有什么样的一个区别呀，什么时候用鱼骨图，什么时候用哈雷托图，。但是这种大致的这种层面你应该是知道的，嗯，然后再比如说你要表示系统的边界，你用什么方法去表示，是不是我们上下文图，系统用例图，那上下文图和系统用例图。它又有什么样的一个区别呀，然后比如说表示场景，我能分析出活动图，用力图来表示场景，然后剩下的这些同学就就都不说了，再比如说。我们这个质量属性需求当中，就包括这个质量属性需求，什么可靠性，可用性，易用性和维护性，安全性，可扩展性等等，这些需求哪些。是可量化的然后这常见的量化的这个指标有哪些这些你是不是大致要了解呀，然后再有就是这个Z规范说明这个语言，还有这个。这个表达式它们的各自是什么样的一个特点，这个C规范说明它是相当是用一个每一个一个模式去刻画这个系统的规格说明，然后它里面这个模式包括状态模式和操作模式。然后那状态模式和操作模式有什么样的一个区别，有什么样的作用，怎么来写这个状态模式，怎么样来写这个操作模式，这你其实都应该至少在这个层面，当前这个级别要有一定的了解。

第三个层次，就是说在我们学完基础知识，基本概念和常用技术的基础之上，以消化理解的基础之上，能够去解决一些实际的问题

然后我们可能还后第三个层次是要应用，那给了你一个实际的问题，你可能要求你能够去写出这个非规范说明的，嗯，然后再比如说这个台标表达式。是一种用表格的这种方式去定义一个函数，或者是关系的然后，它比如说常见的比较简单的有这个正向表，反向表，角色表，向量表，那你需要知道是每一种表它的这个。表的结构是什么样的，然后怎么来写这个表，或者写出来这个表怎么去读，或者是你给的一个函数或者是关系，怎么样用这几种表去给它表达出来，定义出来，。到这样一种程度，

四变量模型，它涉及到哪四种变量，然后哪四种关系它都在比，就是每一项它都代表什么样的一个含义，这个最基本的要求。

了解，然后再有这个伟哥的优先级矩阵，他在评定优先级的时候，用到哪些因素去评定，然后这个怎么样去进行计算，还有这个成本价值这种方法对这个评定。优先级它的那个计算的这种过程嗯，就是考试，比如说如果是考试的话，它会给定你事先有一个成本矩阵，有一个价值矩阵，然后接下来，分别先对这两个矩阵去进行一定的计算。得到的每一个需求它的成本，每一个需求它的价值，然后接下来是画一个坐标系呀，看它落在哪一块区域上，去评定它的这个优先级，嗯，那刚才这个像。是简答题的这样一个层次，那么到能力第三个层次，就是对于实际的这个问题，你能够对它去进行这样一个解答，那比如说我给你一一小段的这个需求的这样一个描述。那么你能够，就是比如说对它来进行一个简单的结构化的建模，或者是一个简单的面向对象的这个建模，或者是说比如说你能够去抽取出或者说定义出这个系统它的这个。我们说上下文它是有四个课面，什么主体课面，然后这个是使用课面IP系统课面开发课面，那你给了你一个系统的描述，你让你去能够。定义出来他的这比如说这几个相关的课面，或者是让你去给他定一些功能性的需求，一些质量属性的需求等等，然后就是就是应用层面了，达到这样一个级别。再有就是，嗯。比如说给你一小段的这个需求描述。你能够，给他定义出一些你想象，就是你思考，他可能会涉及到的一些相关的这种场景，比如说可能是发生一些例外的场景，可替换的这种场景，异常的这种场景等等。是是这样的，然后再比如说一些问题，给你一些实际问题，比如说说要进行这个相关的这个需求获取工作，那么比如说给你一段的描述说。对于这个系统，请你给出一种比较合适的这种需求获取的这种方案，就是因为需求获取方法它有很多种，那么针对不同的情况，你可以去选择不同的这个需求获取方法，。就是就是我们应用题大概就是这种层面，一些实际的问题，让你给出一定的解决方案，是这样一个层次，嗯，这个大概就是这个样子。还有。嗯再比如说各种什么需求验证的这种方法呀，解决这个二一性的一种方法等等。

2.各个活动的输入和输出是什么？活动的内容和实施过程是什么？活动实施中用到了哪些技术？

（1）需求定义

• 输入： 项目背景、业务目标、项目范围文档。
• 输出： 项目的业务需求定义。
• 内容和实施过程： 对项目的业务目标和范围进行详细定义，明确项目的核心业务需求，确定项目的整体方向。
• 使用的技术： 业务分析、领域建模。

（2）需求获取:

• 输入： 用户需求、问题陈述、利益相关方反馈。
• 输出： 需求文档，包含用户需求和问题描述。
• 内容和实施过程： 采用面谈、问卷调查、观察等方法，与利益相关方沟通，识别和提取用户需求，形成文档化描述。
• 使用的技术： 需求采集技术、用户调查技术。

（3）需求分析和建模:

• 输入： 需求文档、用户需求、问题描述。
• 输出： 详细的逻辑模型。
• 内容和实施过程： 分析和综合采集到的信息，建立系统的详细逻辑模型，包括数据流图、用例图等。
• 使用的技术： 系统分析技术、建模技术（如UML）。

（4）需求规格说明:

• 输入： 逻辑模型、需求文档。
• 输出： 软件需求规格说明书。
• 内容和实施过程： 编写详细的软件需求规格说明书，准确描述已确定的需求，包括功能性和非功能性需求。
• 使用的技术： 文档编写技术、UML 表示法。

（5）需求验证:

• 输入： 软件需求规格说明书。
• 输出： 验证通过的需求规格说明书。
• 内容和实施过程： 对软件需求规格进行评审，以确保其正确性、一致性、完备性、准确性和清晰性。
• 使用的技术： 需求审查技术、模型验证技术。

（6）需求管理:

• 输入： 软件需求规格说明书，需求变更请求。
• 输出： 维护的需求基线，需求变更记录。
• 内容和实施过程： 定义需求基线，跟踪需求状态及其变更情况，对需求变更进行管理。
• 使用的技术： 需求跟踪工具、配置管理工具。

3.各种图

1.绘制与或树和与或图

2.i* 和 KAOS目标模型（元素、关系、表达主题）

3.鱼骨图的用途和绘制方法

4.帕累托图的用途和绘制方法

5.系统边界的表示方法（上下文图、系统用例图）

6.用顺序图、活动图或用例图表示场景

7.用数据流图定义系统功能视图

http://t.csdnimg.cn/aVKd7

8.用用例图定义系统功能视图

9.用实体-关系图定义系统数据视图

10.用类图定义系统数据视图

11.用状态转换图定义系统行为视图

4.质量属性需求的量化建模(评价指标)

5.全局设计约束的建模(部署图)

6.Z规范说明

7.用Tabular表达式定义关系或函数(正向表,反向表,决策表和向量表

8.四变量模型(四种变量,四种关系)

9.Wiegers的优先级矩阵

10.用Cost-Value图对需求归类

四、应用题

需求工程应包含的活动
结构化需求分析的思想和建模工具、过程
面向对象需求分析的思想和建模工具，过程
需求获取的目的、过程、方法
需求分析和建模的目的、过程、方法
需求规范说明的目的、过程、方法
需求验证和确认的目的、过程、方法
需求管理的目的、内容

从给定的需求陈述中抽取出功能需求，质量属性，性能属求，约束
熟知各个质量属性的可衡量的量化指标
从给定的问题陈述中抽取出上下文环境
了解常用的目标模型
识别系统的目标并精化目标
掌握分析问题的手段和并能够定义解决方案的边界
熟悉每种需求获取方法的特点，针对要抽取的不网类型的需求，能够确定合适的获取方法

掌握各类型场景的含义，根据给定的需求描述，能够给出需求的场景定义或者根据给出的场是定义，能够识别出场景类型。

根据给定的需求描述，对系统的功能、数据和行为建模
给定需求的Z规格描述
根据给定的函数或关系,定义Tabular表达式(正向,反向,决策,向量)表
二义性需求的来源及解决途径
熟知各种需求验证手段和技术
绘制Weiger优先矩阵确定需求优先级
应用Cost-Value方法确定需求优先级

四、应用题

1.汽车导航

汽车导航系统的需求如下：

R1.系统应当确定汽车的当前位置和前进方向(基于 GPS数据)、车轮转角和偏离度。
R2.系统应当允许通过输入地址来指定行程的目的地。
R3.系统应当允许从所存储的目的地列表中选择一个目的地。
R4.系统应当计算从汽车当前位置到目的地的最快路径。
R5.如果驾驶员偏离了所计算的路线，那么系统应当重新计算路径。
R6.在行程中，系统应当通过听觉和视觉手段提供驾使指向。
试绘出该汽车导航系统的系统用例图、上下文图、0层数据流图、E-R图，要求给出所有可能的实体，实体的属性、关键字、关系、关系基数。

2.Cost-Value图

3.自动机

4.Tabular表达式

5.Weigers

6.音响商店

7.选课系统

针对你所在学校的选课系统，给出它的详细和完备的面向对象分析模型描述，该模型应该包括：
(1) 选课系统的类图；
(2) 针对该选课系统，学生的用例图；
(3) 针对该选课系统，选课业务的顺序图。

http://t.csdnimg.cn/BE30D

8.E-R图

9.需求类型