《软件需求分析与规范》软件需求分析复习题
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2. 观察和文档审查的方法 应用于用户无法完成主动的信息告知的情况下 某些事件只有和它们发生时的具体环境联系起来，才能得到理解
优点: 理解复杂的协同事件 获取工作中的异常处理 获取与用户认知不一致的实际知识 了解用户的认知 获取默认（tacit）知识
缺点: 获得的是零散的细节知识,需要归纳整理
“假象”
糊、信息遗漏、不正确等缺陷 n例外 排斥性需求（Exclusive Requirements） 这种需求要求特定的行为绝 对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃 全局性非功能性需求（Global Non-Functional Requirements） 例如 可靠性、可用性等，对这些需求的测试往往都是大数据集的处理
需求管理的活动包括：维护需求基线、实现需求跟踪、控制变更。
四、
（1）针对某大学图书馆的图书管理系统，例举该系统可能的功能需 求、性能需求、质量属性、外部接口、设计约束，每样各举两个； 功能需求 q 设计不同用户的操作权限和登陆方法 q 借阅者维护借阅者个人部分信息 q 根据借阅情况对数据库进行操作并生成报表 性能需求 q 用户登陆能在0.5秒内完成 q 页面跳转能在2秒内完成 q 80%的查询能在5秒内完成 质量属性 q 操作方式上应该能够满足鼠标和键盘任意切换的需要 q 能够进行简单的多语言版本改造 q 支持主流浏览器：IE7,8,FireFox2.0,Google浏览器 q 系统管理员负责系统维护 外部接口q
4.基于用例的方法
用例描述了在不同条件下系统对某一用户的请求所作出的响应。根据用 户的请求和请求时的系统条件，系统将执行不同的行为序列，每一个行 为序列被称为一个场景。
用例是静态的结构化文本描述。 q用例的内容可以是对当前世界的描述，也可以是对将来确定的解系统 的内部行为描述，还可以是对一种期待的解决方案的描述。 q用例可能会被用于描述系统内部的交互，也可能被用于描述系统和环 境的交互，还可能会被用于描述行为的环境和背景。 q用例是类型层次的事件描述，主要用来描述功能需求。可以包含其他 类型的需求 q用例的内容既包含有正常流程，又包含有异常流程。
工厂包括厂名，地址和电话号码（可能有多个）；
产品包括品名、价格和规格；
部门包括部门Hale Waihona Puke Baidu和部门名称；
职工包括职工号、姓名和职位。
（3）电梯控制系统的用户需求描述如下：
一个控制系统控制多个电梯。每个电梯被置于一个相应甬道之中， 在卷扬电机的作用下在甬道内做上下运动。甬道内安装有多个传感 器，通常每个电梯停靠点一个，用来感应电梯的实时位置。电梯内部 和建筑的每个电梯停靠层都设置有指示器，用来告知用户的电梯实时 位置和运动状况。电梯内和建筑的每个电梯停靠层都设有按钮，用户 可以通过这些按钮提出服务申请并进出电梯。控制系统调度用户的申 请，让电梯以最有效的方式满足用户的服务要求
3. 原型法
原型是一个系统，它内化了（capture）一个更迟系统（later system）的本质特征。原型系统通常被构造为不完整的系统，以在将来 进行改进、补充或者替代。
原型方法的风险 涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而 提出快速交付产品的不当要求 用户可能会被原型所表现出来的非功能特性遮蔽了眼睛，从而忽略了他 们更应该重视的功能特性 在澄清需求不确定性的同时也可能会掩盖一些用户的假设，这些假设将 会无从发现 原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大 的成本
维护与学生档案管理系统的接口 q 维护与校园一卡通系统的接口 设计约束 q 系统应基于J2EE平台开发
（2）根据下面描述构建实体关系图（E_R图）。
工厂生产多种产品，不同工厂可能生产同一产品；
一个工厂下属有多个部门，一个部门有多位职工，但职工只能在一 个部门工作；
一个部门仅有一位员工是经理，这个员工不能再做其他部门的经 理；
（a）画出该系统的系统用例图；
（b）当某位乘客在楼宇底层按动向上按钮，按动按钮事件被发给电梯 控制系统。然后该乘客进入电梯间，按下第6层按钮。按钮按钮事件被 发给电梯控制系统，控制电机向上升起并等待到达事件，到达第6层 后，电梯门打开。
请画出该场景的顺序图。
《软件需求分析与规范》复习题
1、 列举四种需求获取的技术，说明每种技术的特点及适用的情境。 1. 面谈法 面对面的会见被认为是最具丰富内容的交流方法,实践当中应用最为广 泛的需求获取方法之一,可以获得的信息内容包括事实和问题、被会见 者的观点、被会见者的感受、组织和个人的目标。
面谈的优点有： 面谈的开展条件较为简单，经济成本较低； 能获得包括事实、问题、被会见者观点、被会见者态度和被会见者信仰 等各种信息类型在内的广泛内容； 通过面谈，需求工程师可以和涉众（尤其是用户）建立相互之间的友好 关系； 通过参与面谈，被会见者会产生一种主动为项目做出贡献的感觉，提高 涉众的项目参与热情。
用例可以是比较抽象的，用于描述整个业务过程；也可以是比较具体 的，用于描述某个任务的完成过程；还可以是非常具体的，描述某个交 互行为的详细处理步骤。在需求工程的前期，会产生第一种和第二种用 例描述，但最终都需要细化为最后一种形式的用例描述。 q用例可以用于各种目的的应用，包括描述、探索和解释 （explanatory）。需求获取和需求验证是它在需求工程中的主要应用 阶段，它也可以用于需求的建模、交流和协商。
q场景的各种生命周期特征、应用和处理过程都适用于用例。
2、 列举四种需求验证的技术，说明每种技术的特点。 1. 评审
由作者之外的其他人来检查产品问题的方法 n是主要的静态分析手段 n原则上，每一条需求都应该进行评审
2. 原型与模拟 涉及到复杂的动态行为时 成本较高
3. 开发测试用例 如果无法为某条需求定义完备的测试用例，那么它可能就存在着模
面谈的缺点和局限性包括： 面谈比较耗时，时间成本较高； 在被会见者地理分散的情况下往往难以实现面谈； 面谈参与者的记忆和交流能力对结果影响较大，尤其是面谈的成功较高 的依赖于需求工程师的人际交流能力； 交谈当中常见的概念结构不同、模糊化表述、默认知识、潜在知识和态 度偏见等各种问题在面谈中都不可避免，进而影响面谈的效果，导致产 生不充分的、不相关的或者错误的数据； 在会见者不了解被会见者认知结构的情况下，面谈不可能取得令人满意 的效果。
4. 用户手册编制 验证功能需求 对软件系统功能和实现的描述 验证项目范围 对系统没有实现的功能的描述 验证异常流程需求 问题和故障的解决 验证环境与约束需求 系统的安装和启动
（5.利用跟踪关系 6.自动化分析）
3、 阐述需求管理活动的意义并列举需求管理的几个活动。 需求管理活动的意义： 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解； 增进了项目涉众之间的交流； 减少了工作量的浪费，提高了生产力； 准确反映项目的状态，帮助进行更好的项目决策； 改变项目文化，使得需求的作用得到重视和有效发挥。
优点: 理解复杂的协同事件 获取工作中的异常处理 获取与用户认知不一致的实际知识 了解用户的认知 获取默认（tacit）知识
缺点: 获得的是零散的细节知识,需要归纳整理
“假象”
糊、信息遗漏、不正确等缺陷 n例外 排斥性需求（Exclusive Requirements） 这种需求要求特定的行为绝 对不会发生，例如需求可能会要求系统故障不能导致数据库的崩溃 全局性非功能性需求（Global Non-Functional Requirements） 例如 可靠性、可用性等，对这些需求的测试往往都是大数据集的处理
需求管理的活动包括：维护需求基线、实现需求跟踪、控制变更。
四、
（1）针对某大学图书馆的图书管理系统，例举该系统可能的功能需 求、性能需求、质量属性、外部接口、设计约束，每样各举两个； 功能需求 q 设计不同用户的操作权限和登陆方法 q 借阅者维护借阅者个人部分信息 q 根据借阅情况对数据库进行操作并生成报表 性能需求 q 用户登陆能在0.5秒内完成 q 页面跳转能在2秒内完成 q 80%的查询能在5秒内完成 质量属性 q 操作方式上应该能够满足鼠标和键盘任意切换的需要 q 能够进行简单的多语言版本改造 q 支持主流浏览器：IE7,8,FireFox2.0,Google浏览器 q 系统管理员负责系统维护 外部接口q
4.基于用例的方法
用例描述了在不同条件下系统对某一用户的请求所作出的响应。根据用 户的请求和请求时的系统条件，系统将执行不同的行为序列，每一个行 为序列被称为一个场景。
用例是静态的结构化文本描述。 q用例的内容可以是对当前世界的描述，也可以是对将来确定的解系统 的内部行为描述，还可以是对一种期待的解决方案的描述。 q用例可能会被用于描述系统内部的交互，也可能被用于描述系统和环 境的交互，还可能会被用于描述行为的环境和背景。 q用例是类型层次的事件描述，主要用来描述功能需求。可以包含其他 类型的需求 q用例的内容既包含有正常流程，又包含有异常流程。
工厂包括厂名，地址和电话号码（可能有多个）；
产品包括品名、价格和规格；
部门包括部门Hale Waihona Puke Baidu和部门名称；
职工包括职工号、姓名和职位。
（3）电梯控制系统的用户需求描述如下：
一个控制系统控制多个电梯。每个电梯被置于一个相应甬道之中， 在卷扬电机的作用下在甬道内做上下运动。甬道内安装有多个传感 器，通常每个电梯停靠点一个，用来感应电梯的实时位置。电梯内部 和建筑的每个电梯停靠层都设置有指示器，用来告知用户的电梯实时 位置和运动状况。电梯内和建筑的每个电梯停靠层都设有按钮，用户 可以通过这些按钮提出服务申请并进出电梯。控制系统调度用户的申 请，让电梯以最有效的方式满足用户的服务要求
3. 原型法
原型是一个系统，它内化了（capture）一个更迟系统（later system）的本质特征。原型系统通常被构造为不完整的系统，以在将来 进行改进、补充或者替代。
原型方法的风险 涉众看到了一个正在运行的原型，得出产品几乎已经完成的结论，从而 提出快速交付产品的不当要求 用户可能会被原型所表现出来的非功能特性遮蔽了眼睛，从而忽略了他 们更应该重视的功能特性 在澄清需求不确定性的同时也可能会掩盖一些用户的假设，这些假设将 会无从发现 原型开发工作投入太多的工作，使得开发团队消耗了过多的时间和过大 的成本
维护与学生档案管理系统的接口 q 维护与校园一卡通系统的接口 设计约束 q 系统应基于J2EE平台开发
（2）根据下面描述构建实体关系图（E_R图）。
工厂生产多种产品，不同工厂可能生产同一产品；
一个工厂下属有多个部门，一个部门有多位职工，但职工只能在一 个部门工作；
一个部门仅有一位员工是经理，这个员工不能再做其他部门的经 理；
（a）画出该系统的系统用例图；
（b）当某位乘客在楼宇底层按动向上按钮，按动按钮事件被发给电梯 控制系统。然后该乘客进入电梯间，按下第6层按钮。按钮按钮事件被 发给电梯控制系统，控制电机向上升起并等待到达事件，到达第6层 后，电梯门打开。
请画出该场景的顺序图。
《软件需求分析与规范》复习题
1、 列举四种需求获取的技术，说明每种技术的特点及适用的情境。 1. 面谈法 面对面的会见被认为是最具丰富内容的交流方法,实践当中应用最为广 泛的需求获取方法之一,可以获得的信息内容包括事实和问题、被会见 者的观点、被会见者的感受、组织和个人的目标。
面谈的优点有： 面谈的开展条件较为简单，经济成本较低； 能获得包括事实、问题、被会见者观点、被会见者态度和被会见者信仰 等各种信息类型在内的广泛内容； 通过面谈，需求工程师可以和涉众（尤其是用户）建立相互之间的友好 关系； 通过参与面谈，被会见者会产生一种主动为项目做出贡献的感觉，提高 涉众的项目参与热情。
用例可以是比较抽象的，用于描述整个业务过程；也可以是比较具体 的，用于描述某个任务的完成过程；还可以是非常具体的，描述某个交 互行为的详细处理步骤。在需求工程的前期，会产生第一种和第二种用 例描述，但最终都需要细化为最后一种形式的用例描述。 q用例可以用于各种目的的应用，包括描述、探索和解释 （explanatory）。需求获取和需求验证是它在需求工程中的主要应用 阶段，它也可以用于需求的建模、交流和协商。
q场景的各种生命周期特征、应用和处理过程都适用于用例。
2、 列举四种需求验证的技术，说明每种技术的特点。 1. 评审
由作者之外的其他人来检查产品问题的方法 n是主要的静态分析手段 n原则上，每一条需求都应该进行评审
2. 原型与模拟 涉及到复杂的动态行为时 成本较高
3. 开发测试用例 如果无法为某条需求定义完备的测试用例，那么它可能就存在着模
面谈的缺点和局限性包括： 面谈比较耗时，时间成本较高； 在被会见者地理分散的情况下往往难以实现面谈； 面谈参与者的记忆和交流能力对结果影响较大，尤其是面谈的成功较高 的依赖于需求工程师的人际交流能力； 交谈当中常见的概念结构不同、模糊化表述、默认知识、潜在知识和态 度偏见等各种问题在面谈中都不可避免，进而影响面谈的效果，导致产 生不充分的、不相关的或者错误的数据； 在会见者不了解被会见者认知结构的情况下，面谈不可能取得令人满意 的效果。
4. 用户手册编制 验证功能需求 对软件系统功能和实现的描述 验证项目范围 对系统没有实现的功能的描述 验证异常流程需求 问题和故障的解决 验证环境与约束需求 系统的安装和启动
（5.利用跟踪关系 6.自动化分析）
3、 阐述需求管理活动的意义并列举需求管理的几个活动。 需求管理活动的意义： 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解； 增进了项目涉众之间的交流； 减少了工作量的浪费，提高了生产力； 准确反映项目的状态，帮助进行更好的项目决策； 改变项目文化，使得需求的作用得到重视和有效发挥。