需求分析与设计课后答案样本

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第一章

1.需求分析与系统设计之间的界限是什么? 何时从分析阶段进入设计阶段? 需求分析关注系统”做什么”, 系统设计关注”如何做”。

当分析阶段完成后才能进入到设计阶段

2.需求处理要注意哪些非技术因素? 为什么?

要注意的非技术因素: 组织机构文化、社会背景、商业目标、利益协商等。因为利用建模与分析技术构建的解决方案一定要和具体的应用环境相关, 不存在不依赖具体应用环境的解决方案,

因此, 在利用建模分析技术进行要求处理是不能忽视具体应用环

境的相关因素

3.需求分析与需求工程之间的关系

那就是需求工程含义更广, 包括需求获取、需求分析、需求定义

第二章

1.解释名词:问题域, 解系统和共享现象, 并结合她们的含义

说明软件系统如何与现实世界形成互动的

问题域: 现实的状况与人们期望的状况产生差异就产生问题。

解系统:软件系统经过影响问题域, 能够帮助人们解决问题称

为解系统经过共存现象仅仅是问题域和姐系统的一个部分。而不是她们的全部。

软件系统仅仅是现实世界的一种抽象。因此问题除了共享现象

之外。还有很多在进行模型抽象时忽略的其它现实因素。

2.解释下列名词, 需求, 规格说明, 问题域特性和约束, 并结

合她们的含义说明需求工程的主要任务是什么?

需求是用户对问题域中的实体状态或事件的期望描述

规格说明:规格说明是解系统为满足用户需求而提供的解决方案, 规定了解系统的行为特征。

问题域的特性: 在和解系统相互影响的同时, 问题域是自治的, 它有自己的运行规律, 而且这些规律不会因解系统的引入而发生

改变, 这种自治的规律性称为问题域特性, 当这些特性非常明确

时称之为约束。

需求工程的主要任务: 1.需求工程必须说明软件系统将应用的环境及目标, 说明用来达成这些目标的软件功能, 还要说明在设计和实现这些功能时上下文环境对软件完成任务所用的方式、方法所施加的限制和约束。2需求工程必须将目标、功能和约束反映到软件系统中, 映射为可行的软件行为, 并对软件行为进行准确的规格说明。3需求工程还要妥善处理目标、功能和约束随着时间的演化情况。

4.需求有哪些常见的类别? 功能需求和非功能需求有什么差异?

严格意义上的软件需求的分类:

功能需求( Functional Requirement) : 和系统主要工作相关的需求, 即在不考虑物理约束的情况下, 用户希望系统所能够执行的

活动, 这些活动能够帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。

( Performance Requirement) : 系统整体或系统组成

, 例如CPU使用率、内存使用率等。

( Quality Attribute) : 系统完成工作的质量, 即系

, 例如可靠性程度、

对外接口( External Interface) : 系统和环境中其它系统之间需要建立的接口, 包括硬件接口、软件接口、数据库接口等等。

约束 : 进行系统构造时需要遵守的约束, 例如编程语言、硬件设施等。

广泛意义上的需求分类:

系统级需求( System) : 针对系统工程的需求, 包括与硬件相关的需求被称之为硬件需求( Hardware) 、与软件相关的需求被称之为软件需求( Software) 、与人力资源相关的需求以及软件、硬件、人力之间协同的需求被称之为其它需求。

功能需求和非功能需求的差异: 除功能需求之外的其它四种类别需求又被统称为非功能需求。在非功能需求当中, 质量属性对系统成败的影响极大, 因此在某些情况下, 非功能需求又被用来特指质量属性。而且一般一个软件系统的绝大部分需求都是功能需求, 在比例上功能需求有可能占所有需求的90%以上。

5.描述业务需求、用户需求和系统( 级) 需求的区别与联系。

业务需求: 业务需求是抽象层次最高的需求, 是系统建立的战略出发点, 表现为高层次的目标, 它描述了组织为什么要开发系统。

用户需求: 执行实际工作的用户对系统所能

完成的具体任务的期望, 描述了系统能够助

用户做些什么。

系统需求: 用户对系统行为的期望, 一系列

的系统行为联系在一起能够帮助用户完成任

务, 满足业务需求; 系统需求能够直接映射

为系统行为, 定义了系统中需要实现的功能,

描述了开发人员需要实现什么。

业务需求、用户需求和系统( 级) 需求的区别与联系如右图所示: 用户需求---->系统需求的过程:

首先需要分析问题领域及其特性, 从中发现问题域和计算机系统的共享知识, 建立系统的知识模型; 然后将用户需求部署到系统模型当中, 即定义系列的系统行为, 让它们联合起来实现用户需求, 每一个系统行为即为一个系统需求。该过程就是需求工程当中最为重要的需求分析活动, 又称建模与分析活动。

6.优秀的需求哪些特性? 试为每一个特性都举出一个不符合的示例。

优秀的需求特性:

1)完备性: 不需要做更多的扩展就能够充分的说明用户所需要的

系统功能。每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息。

R6( 不完整) : 系统应该允许被扩展

R7( 完整、较R8精确) :系统的调度算法应该允许被扩展2)正确性: 真实的反映用户的意图; 必须请需求的提出者予以确

认。

3) 可行性: 在检查的过程中, 由开发人员进行检查可能需要进行一定的分析和研究, 而不是单纯的凭借经验和直觉。对于难以判断的需求, 必要的时候要经过开发原型来加以验证。

示例: 保证系统核心功能能够7×24小时连续运行。

4) 必要性: 满足用户的业务需求所必须的。

5) 无歧义: 每一项需求都应该有而且只能有一种解释。

定义一个能够共同理解的词汇表( Glossary)

6) 可验证: 经过分析、检查、模拟或者测试等方法能够判断需求是否被满足。

示例: 实现各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化; 统一办公流程、规范公文格式, 加强信息交流和共享, 提高工作效率; 不可验证的需求往往是因为描述模糊或者过于抽象, 因此在进行需求的描述时要让需求具体化、小心形容词和副词的使用、避免程度词的使用。

第三章

相关文档
最新文档