软件需求工程2018期末题

一、填空题

1.1 ___软件需求__是一门分析并记录软件需求的学科,它把系统需求分解成一些主要的子系统和任务,把这些子系统或任务分配给软件,并通过一系列重复的分析,设计,比较研究,原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数.

1.2 __软件原型__是所提出的新产品的部分实现或可能的实现

1.3 除了__已知的设计和实现上___的限制(约束),软件需求规格说明 _不应该_包括设计,构造,测试或项目管理的细节
1.4 IEEE软件工程标准词汇表(1997年)中定义需求为:

• (1) 用户为解决某个问题或达到某种目标而达到而具备的__条件或能力__
• (2)系统或系统部件要满足合同,标准,规范或其它正式规定文档而必须要满足的条件或必须具备的能力
• (3)一种反映上面__(1)(2)__所描述的条件或能力的文档说明

1.5 __需求基线__是团队成员已经承偌将在某一特定产品版本中实现的功能性和非功能性需求的一组集合.

二、单元题

2.1 下列哪个不是审查成员扮演的角色: ( D )

• A 作者
• B 调节者或主持人
• C 读者和记录员
• D 开发者

2.2 下列哪一项不属于软件原型类型: ( C )

• A 水平原型和垂直原型
• B 书面原型和电子原型
• C 程序代码和用例模型
• D 抛弃型原型和进化型原型

2.3下列哪个不是需求管理的活动? ( C )

• A 变更控制
• B 版本控制
• C 需求获取
• D 需求跟踪

2.4 不属于需求开发的活动是: ( A )

• A 版本管理
• B 需求获取
• C 需求分析
• D 需求验证或确认

2.5 如果不能把某设计元素,代码段或测试回溯到一个需求, 而该孤立的元素又确实是一个正当的功能,则表明: ( B )

• A 存在一个画色添足的程序
• B 需求规格说明漏掉了一项需求
• C 文档书写不符合模板
• D 项目计划不周全

三、多项选择题

3.1 以下哪些属于需求工程活动的独立阶段: (ACDE)

• A 需求获取
• B 需求分析
• C 形成需求规格说明
• D 需求验证
• E 需求管理

3.2 整理需求规格说明书必须具备的特性包括: (ACE)

• A 一致性
• B 优先级
• C 可修改性
• D 无二义性
• E 可跟踪性

3.3 以下哪些属于需求图形分析模型: (ABCD)

• A 数据流图
• B 实体关系图
• C 状态转换图
• D 用例图

3.4 CCB的主要作用: (BCE)

• A 获取其他需求
• B 制定决策
• C 交流情况
• D 设计系统部件
• E 重新协商约定
• F 编写测试用例及文档

3.5 以下需求跟踪联系链信息源正确的是: (AC)

• A 系统需求->软件需求->系统工程师
• B 设计元素->代码->用户
• C 功能性需求->测试用例->测试工程师
• D 用例->软件体系结构元素->测试工程师
• E 业务规则->软件需求->需求分析员

3.6 以下哪些项属于软件需求的组成部分: (ABC)

• A 业务需求
• B 用户需求
• C 功能需求
• D 系统需求
• E 需求验证

四、简答题

4.1 为什么在软件开发项目中维护阶段发现错误的修复成本是需求阶段发现错误修复成本的100倍到200倍（3-5）？详细说明这些成本的主要构成

答:

• ① 因为维护是建立在需求,设计,编码等的基础之上的, 如果在维护阶段发现错误,那么要修复,或许就要从编码,设计,需求等阶段开始修复, 随之伴随而来的,可能就是要重新进行规格说明,重新设计,重新编码,这就成倍增加了修复的成本.如图所示:
  
  该图是许多公司项目生命周期各阶段修复成本的度量和计算,由图可得,如果把编码阶段发现和修复一个错误所需要的努力用"1"个成本单元表示的话,那么,需求阶段的错误修复成本是它的5~10倍,而维护阶段发现和修复一个错误的成本超过20倍. 因此,软件开发项目中维护阶段发现错误的修复成本是需求阶段发现错误的修复成本的 100~200倍.
• ②这些成本由以下方面构成:
  • 重新规格说明
  • 重新设计
  • 重新编码
  • 重新测试
  • 版本升级: 用一个修正后的版本替代有缺陷的版本
  • 纠正活动: 消除由于不正确的新系统错误造成的一切危害,这可能涉及到偿还不满用户的经济损失,以及重新运行系统所付出的代价等:
  • 报废: 包括以最好的意图完成的代码,设计,和测试用例,当发现它们依据不正确的需求时不得不会全部丢弃
  • 收回有缺陷的软件版本以及相关的用户手册: 有时软件可能会已经嵌入到数字手表,微波炉,或汽车等产品中,这时所回收的内容也包括有形的产品和嵌入到该系统的软件
  • 保修成本
  • 产品赔偿: 客户要求对有缺陷软件造成的损失进行赔偿
  • 公司派代表到客户那里重新安装软件所必须支付的服务成本
  • 建档成本

4.2 什么是软件需求?图示并论述软件需求的层次并描述其相互关系.

答:
(1) IEEE软件工程标准词汇表中定义需求为:

• ①用户解决问题或达到目标所需的条件或权能(capability)
• ②系统或系统部件要满足合同,标准,规范或其他正式规定文档所需具有的条件或权能
• ③一种反映上面①,②所描述的条件或权能的文档说明

或者:
软件需求是指用户对目标软件新系统在功能,行为,性能,设计约束等方面的期望. 通过对问题及其环境的理解分析, 为问题涉及的信息,功能及系统行为建立模型, 将用户需求精确化,完全化, 最终形成需求规格说明, 这一系列的活动即构成软件开发生命周期的需求分析阶段.

(二) 软件需求的三个不同层次之间的关系可用下图表示

4.3 简述软件需求的几种典型来源

①与潜在用户进行交谈和讨论
②描述现有产品或竞争产品的文档
③系统需求规格说明现有系统的问题报告和改进要求
④市场调查和用户问卷调查
⑤观察用户如何工作
⑥用户工作的情景分析
⑦事件和响应并做适当的解释

4.4 优秀的需求及需求规格说明应具有哪些主要特性?图示并论述需求审查的过程,并说明需求规格说明书进入和退出审查的标准

答:
(1) 主要特征: 完整性,正确性,可行性,必要性,划分优先级,无二义性,可验证性,一致性,可修改性,可跟踪性
(2)需求评审要经历如下过程:

• ①规划,作者和调节者协同对审查进行规划,已决定谁该参加审查,审查员在召开审查会之前应受到什么材料并且需要召考几次审查会.

• ②总体会议, 总体会议可以为审查员提供了解会议的信息,包括他们要审查的材料背景,作者所作的假设和作者的特定审查目标. 如果所有的审查员对审查的项目都很熟悉,那么可以省略本次总体会议

• ③准备, 在正式审查的准备阶段,每个审查员以典型缺陷清单为指导,检查产品可能出现的错误,并提出问题

• ④审查会议, 在审查会进行过程中,读者通过软件需求规格说明指导审查小组,一次解释一个需求. 当审查员提出可能的错误或其他问题时,记录员就记录这些内容,其形式可以成为需求工作者的工作项列表.会议的目的是尽可能多的发现需求规格说明中的重大缺陷.另外审查会不应该超过两个小时,如需更多时间,就另外安排一次

• ⑤重写, 几乎每一个质量控制活动都可能发现一些需求缺陷,因此,作者必须在审查会之后,安排一段时间用于重写 文档,解决需求中的二义性,消除模糊性,并且成为成功开发一个项目打下坚实的基础

• ⑥重审, 这是审查工作的最后一步,调节者或指派人单独重审由作者重写的需求规格需求说明,重审确保了所有提出的问题都能得到解决,并且正确修改需求的错误,重审结束了审查的全过程并且可以使调节者做出判断,是否已经满足审查的退出标准
  
  (3) 需求规格说明书进入审查的标准

• ①文档符合标准模板

• ②文档已经做过拼写检查和语法检查

• ③作者已经检查了文档在版面安排上所存在的错误

• ④已经获得了审查员所需要的先前或参考文档,例如系统需求规格说明

• ⑤在文档中打印了行序号以方便在审查中对特定位置的查阅

• ⑥所有未解决的问题都被标记为TBD(未待定)

• ⑦包括文档中使用到的术语词汇表

(4) 需求规格说明书退出审查的标准:

• ①已经明确阐述了审查员提出的所有问题
• ②已经正确修改了文档
• ③修订过的文档已经进行了拼写检查和语法检查
• ④所有TBD的问题已经全部解决,或者已经记录下每个待定问题的解决过程,目标日期和提出问题的人
• ⑤文档已经登入计入项目的配置管理系统
• ⑥检查是否已将审查过的资料送到有关收集处

4.5 论述变更管理中的主要活动有哪些,给出需求变更控制过程描述

答:
(1) 需求管理包括在工程进展中维持需求约定集成性和精确性的所有活动如下:

• 变更控制: 建议变更,分析影响,决定变更,更新需求文档 变更计划 测量需求的稳定性
• 版本控制: 定义版本标识方法 确定需求文档版本,确定单个需求文档版本
• 需求跟踪: 定义对其它需求的连接链定义对其它系统元素的连接链
• 需求状态跟踪: 定义可能的需求状态, 记录每一个需求状态,记录所有需求的状态分布情况

(2) 需求变更控制过程描述如下:

• 1 概述

  • 1.1 目的
  • 1.2 范围
  • 1.3 定义

• 2 角色和职责

• 3 变更请求状态

• 4 开始条件

• 5 任务

  • 5.1 评估请求
  • 5.2 做出决策
  • 5.3 执行变更
  • 通知受变更影响的各方

• 6 验证

  • 6.1 验证变更
  • 6.2 安装产品

• 7 结束条件

• 8 变更控制状态报告

附录:每个请求所需存储的数据项

4.6 什么是软件原型?使用软件原型的目的有哪些?说明软件原型的种类和使用原型技术应遵守的主要原则.

答:
(1) 软件原型是一种技术, 可以利用这种技术减少客户对产品不满意的风险.一个软件原型是所提出的新产品的部分实现,通过使用原型可以使开发小组正确理解需求,发现和解决在产品开发的早期阶段不确定的问题以及需求中的二义性和不完整性问题,最终明确如何最好地实现这些需求并最终明确并完善需求\探索设计选择方案,发展为最终的产品,同时用户,经理和其他非技术风险承担者发现在确定和开发产品时,原型可以使他们的想象更具体化
(2) 使用原型有三个主要目的:

• 明确并完善需求: 原型作为一种需求工具,它是对部分系统的初步实现.用户对原型的评价可以指出需求中存在的问题,在开发真正产品之前,可以最低的费用用来解决这些问题
• 探索设计选择方案: 源性作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的易用性,并且可以评价可能的技术方案
• 发展为最终的产品原型: 作为一种构造工具,是产品最初子集的完整功能实现,通过一系列小规模的开发循环,你可以完成整个产品的开发

(3) 软件原型的种类

• 水平原型和垂直原型: 可以让用户体验或者验证需求实现的具体行为以及部分确定性的功能
• 抛弃原型和进化型原型: 针对不确定性的问题通过原型进行探讨和研究最终剔除掉需求的需求的不确定性
• 电子原型和书面原型

(4) 为了帮助开发者在需求开发过程中建立有效的原型,请遵循如下原则:

• 项目计划中应包括原型风险
• 计划开发多个原型
• 尽快并且廉价低建立抛弃原型
• 在抛弃原型中不应该包含代码注释,输入数据有效性检查,保护性编码技术,或者错误处理的代码
• 对于已经理解的需求不要建立原型
• 不能随意地增加功能
• 不要从水平原型的性能推测最终产品的性能
• 在原型屏幕显示和报表中使用合理的模拟数据
• 不要期望原型可以替代需求文档

4.7 本课程主要涉及的图形化分析方法有哪些?绘制系统数据流图应遵循哪些原则?

答:
(1) 图形化分析方法有:用例图 数据流图 实体联系图 状态转换图 对话图 类图
(2) 绘制系统数据流图应遵循的原则有:

• 把数据存储在0层数据流图或更低子图层,不要放在关联图上
• 过程是通过数据存储进行通讯,而不是从一个过程直接流到另一个过程
• 使用简明的动作命名过程: 动词+对象
• 对过程的编号要唯一且具有层次性
• 不要使用某些圆圈只有输入或只有输出

4.8 选定一不少于四种用户类的简单项目，论述该项目的视图陈述，确定并分析项目的用户类及特征，给出系统用例模型，并绘制系统关联图。

答：新闻发布系统
(1) 项目陈述如下：
“新闻发布系统”可使任何人方便的对新闻内容进行浏览，任何人可以通过注册成为会员，会员可以享有对新闻和评论进行评论的权限，同时会员也可以对自己的个人信息进行修改，管理员登录系统后，可以在后台发布并管理新闻，后台的系统管理员可以管理新闻、评论和会员信息。系统可以对新闻进行有效的管理，包括新闻的各种内容、属性还有评论和会员信息等，通过不同用户所拥有的管理权限，方便对新闻等信息进行删除更改，同时用户通过登录功能可以帮助用户随时了解新闻状态，保持新闻的时效性和正确性，同时扩大新闻的阅读量和传播率，避免新闻发布可能产生的管理混乱，严格用户职责，做到责任追溯，评论追溯等科学化管理。

(2) 用户类及特征分析（略）

(3) 用例模型（参考）：

(4) 系统关联图(参考):