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

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
第一章
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) 可验证: 经过分析、 检查、 模拟或者测试等方法能够判断需求是否被满足。
示例: 实现各部门的公文流转无纸化、 文档一体化、 业务管理的规范化、 自动化和网络化; 统一办公流程、 规范公文格式, 加强信息交流和共享, 提高工作效率; 不可验证的需求往往是因为描述模糊或者过于抽象, 因此在进行需求的描述时要让需求具体化、 小心形容词和副词的使用、 避免程度词的使用。
第三章
1.需求工程过程的工作基础(即输入)存在哪些? 她的工作成果(即输出)有哪些?
答: 需求过程的工作基础是获取用户面临的业务问题, 用户期望系统表现出来的各种行为, 即需求获取工作成果:产生一个能够在用户环境下解决用户业务问题的系统方案, 并将其文档化为明确的规格说明。
2.描述需求工程的各个活动, 说明她们各自的工作基础, 工作目标和工作成果
1.需求获取:
工作基础: 1.收集背景资料2.定义项当前景和范围3.选择信息的来源
4.选择获取方法, 执 行获取5.记录获取结果
工作目标:获取用户需求, 了解用户在完成任务的时候遇到的问题与期望 工作成果:业务需求, 项目的前景和范围, 用户需求以及问题域的特征
2.需求分析:
工作基础: 1背景分析 2.确定系统边界3.需求建模
4.需求细化 5.确定优先权 6.需求协商
工作目标:1.经过建模整合各种信息, 是人们更好地理解问题
2.定义一个需求集合, 能够为问题界定一个游戏的解决方案
工作成果: 产生一个需求的基线集, 它指定了系统或当前版本的系统开发需完成的任务
3.需求规格说明:
工作基础1.定制文档模板 2.编写文档
工作目标:为了系统涉众之间交流需求信息
工作成果:需求规格文档说明
4.需求验证
工作基础1.执行验证 2问题修改 工作目标: 为了尽量不给设计实现测试后续开发活动带来不必要的影响。需求规格说明文档定义必须正确准确地反映用户的意图
工作成果:验证之后, 问题得以修正
需求管理:
工作基础: 1.建立和维护需求基线集2.建立需求跟踪信息 3进行变更控制 工作目标:保证需求作用的持续稳定和有效发挥
工作成果:需求管理会进变更控制和实现合理的变更请求拒绝不合理的变更请求, 控制变更的成本和影响范围
4.需求工程师需求具备的技能 专业技能, 分析技能, 交流技能, 观察技能, 建模技能, 写作技能, 创新技能, 协调技能
第五章
1.为什么要定义项目的前景和范围?
答、 业务需求、 高层解决方案和系统特性都应该被记录下来, 定义为项目的前景与范围文档, 前景描述了产品的作用和最终的功能, 它将所有的涉众都统一到一个方向上范围指出了当前项目是要解决产品长远规划的那一部分, 它为项目规定了需求的界限
案例题:
1. 你被任命为替换学生财务资助项目的项目经理。你想开发一个工作陈述来定义范围并降低范围蔓延的风险。财务资助部门的主管坚持要你15个月、 600 000美元的预算内替换她现有的系统就能够了。她说这就是你需要知道的全部, 不需要浪费时间开发一个工作陈述了。省略工作陈述的风险是什么? 你将如何说服主管?
解答: 省略工作陈述的风险是不能明确项目的前景和范围。如果省略了工作陈述的话, 我们就不能和用户进行很好的沟通与交流, 这样, 项目的问题也就不能明确, 开发人员无法与涉众对问题达成共识; 无法明确问题, 也就无法发现正确的业务需求, 无法定义良好的解决方案及系统特性, 继而无法明确项目的前景和范围, 这样就会造成项目的不稳定甚至失败!
第六章
1.什么是涉众? 涉众分析? 软件系统中常见的涉众?
涉众是与要建设的业务系统相关的一切人和事.
涉众分析就是为软件系统寻找并理解关键涉众的过程
常见的涉众:管理着: 用户、 客户、 开发人员、 管理者、 领域专家、
政府力量和市场力量等
领域专家: 在问题域中具有丰富知识的专家
*关注软件中的知识
政府力量: 法律法规、 长远规划、 政策意向
*起约束和指导作用
市场力量: 组织中的市场部门人员, 关注用户的想法
*关注用户想法
用户: 最终使用和操作产品的人
*关注软件功能
客户: 为软件系统开发付费的人
*关注经济的成本、 收益
开发者: 负责实现软件系统的人
*关注技术上的成本和利益
第七章
2.列出面谈的5个步骤
面谈准备的主要工作包括:
1、 阅读背景资料
2、 确定面谈的主题和目标
3、 选择被会见者
4、 准备会见被会见者
5、 确定问题和类型
第8章
1.原型的定义
原型是一个系统, 她内化了一个更迟系统的本质特征。
2.说明原型在需求获取中的作用和试用情景
因为原型是在最终系统产生之前的一个局部真实表现, 因此原型方法能够让人们在系统的开发过程中, 就能对一些具体问题进行基于事物有效沟通, 从而帮助人们今早解决软件开发过程中存在的各种不确定性。
场景:
产品以前从未存在过, 而且难以可视化, 这些产品属于创新产品, 她们的基本需求是潜在的, 有很大的不确定性
产品的用户对相关类别的产品没有经验, 而且对将要采用的技术也没有经验。此时用户无法明确工作的具体细节, 产品的细节需求存在着不确定性 用户进行自己的工作已经有一段时间了, 但在完成工作的方式上依然存在障碍。 用户清晰说明她们的需求方面存在困难。在澄清和理解之前, 这些需求存在着不确定性
需求的可行性值的怀疑, 即具体需求的可满足性存在着不确定性
三、 案例题
”我有一个绝妙的主意! ”Bea Kwicke宣布, 她是系统团队的一位新来的需求工程师, ”让我们跳过所有的SDLC垃圾, 直接为一切设计原型。我们的项目会进展的更快, 还能够节省时间和金钱, 而且所有的用户会感到我们似乎很在意她们, 而不是连续几个月不与她们交谈。
a)列出你( 作为与Bea同一个团队的成员) 用来劝阻她不要试图放弃SDLC, 而直接为所有项目设计原型的原因。
b)Bea对你所说的话很失望。为了鼓励她, 用一段话向她说明, 你认为适用于原型化方法的情 ( 1
) 主要原因: 原型仅仅是开发当中使用的一种手段, 它利用得当能够加速开发的进 程, 但不能代替软件开发中的所有工作。
( 2) 情形见下表, 特别是其中红色的部分
第九章
1.为什么需要观方法? 观察方法的适用情景是什么?
答: 很多时候用户无法完成主动的信息告知, 或者说用户和需求工程师之间的语言交流无法产生有效的结果, 这时就有必要采用观察的方法。
采样观察: 根据明确的目的选取特定的时间段或者特定的事件进行观察。 民族志: 观察者深入到用户中, 花费较长的时间( 一般为几个月) 来观察用户的活动。
话语分析: 它经过观察和分析用户交谈中的交互方式或者特定的话语形式的内部结构来发现和获取相关信息。
协议分析: 对用户任务的观察。它要求观察对象一边执行任务, 一边大声地解释她们在执行任务时产生的各种想法。
任务分析: 专门针对人机交互行为的观察。它引入了相关的模型方法来观察、 记录和分析用户与软件系统的交互行为
案例题
1. Ceci Awill说: ”我想我能记得她所做过的大部分事情。”Ceci准备与OK Ｃ
orral公司战略规划副总裁Biff Weblldon进行面谈。OK Ｃorral是一家拥有130间牛排连锁店的公司。”我的意思是说, 我有好的记性。我认为听她说什么比看她做什么更重要。”
作为需求工程团队的一员,Ceci Awll向你诉说了她要写下在面谈中对Biff的办公司和Biff的活动进行观察的愿望。
(1) 用一段话来说服Ceci, 在面谈时仅仅倾听是不够的, 观察和记录所观察的内容同样是很重要的。
(2) Ceci似乎接受了你认为观察时很重要的观点, 可是不知道该观察什么。列出需要观察的项目和行为, 在每一项行为的旁边用一句话指名Ceci经过观察应该得到的信息。
答: ( 1) 面谈并不能确保用户能够将所有的信息都告知需求工程师, 诸如一些语言无法确切描述的事务, 而观察能够了解用户真正做什么, 还能够获取到其它方法不能得到的用户及其工作环境的信息, 还能够对从其它方法获取的信息进行确认, 因此我们应该重视观察方法的应用。
观察客户所处的环境( 得出何种需求才能更适合客户) 。( 2)
观察客户行为、 习惯特征( 得出更适合客户使用的软件需求) 。‚
第十一章
2.什么是系统模型, 她与需求分析和系统设计有什么关系?
系统模型是指以某种确定的形式( 如文字、 符号、 图表、 实物、 数学公式等) , 对系统某一方面本质属性的描述。
需求分析是挖掘和整理知识的过程, 它在已掌握知识的基础上进行。初步捕获到的需求信息往往处于不同层次, 也有一些主观甚至不正确的信息。而经过必要的需求分析工作之后, 需求会更加系统、 更加有条理、 更加全面。
那么系统分析呢? 如果说, 需求分析致力于搞清楚软件系统要”做什么”的话, 那么系统分析已经涉及”怎么做”的问题了。
需求捕获、 需求分析以及系统分析之间的关系我们必须理解透彻, 否则就会
影响工作的有效性进行。
同样, 在实践中, 需求分析和系统分析也常常被混淆。需求分析致力与搞清软件系统要”做什么”, 而系统分析更关注”怎么做”的问题, 比如大多数分析方法( 如OOA) 应该术语系统分析的范畴。
第十二章
1.什么是系统思想?过程模型如何反应系统思想? 系统是指由相互制约、 相互作用的一些部分组成的具有某种功能的有机整体。因此系统思想能够理解为, 用整体、 全局的、 联系的观点看问题、 办事情, 而不能用片面的、 孤立的观点。
软件过程是为了获得高质量软件所需要完成的一系列任务的框架, 它规定了完成各项任务的工作步骤。
第十五章
1.什么事需求规格说明? 为什么要建立需求规格说明?
答: 需求规格说明活动就是将需求及其软件解决方案进行定义和文档化, 并传递给开发人员的需求工程活动。
建立需求规格说明的必要性是显而易见的: 一方面, 清晰、 明确、 结构化的文档能够将系统的需求信息和解决方案更好地传递到所有的开发人员。另一方面, 文档能够拓展人们的知识记忆能力。除了必要性外, 需求规格说明文档能够成为合同协议的重要部分, 能够成为项目开发活动的一个重要依据, 能够尽早地发现和减少项目的返工, 降低项目的工作量, 需求规格女说明文档能够成为有效的智力资产。
2.需求规格说明有哪些常见类型? 她们的主要内容分别是什么?
答: 需求规格说明文档常见有项当前景和范围文档、 用户需求文档、 系统需求规格说明文档、 软件需求规格说明文档、 接口需求规格说明文档、 硬件需求规格说明文档和人机交互文档。
项目的前景和范围文档的主要内容是对业务需求的定义, 用户需求文档是对用户需求的定义, 系统需求规格说明文档是对系统需求、 解决方案的定义, 软件需求规格说明文档是对整个系统功能分配给软件部分的详细描述, 硬件需求规格说明文档是对整个系统功能当中分配给硬件部分的详细描述, 接口需求规格说明文档是对整个系统中需要软、 硬件协同实现部分的详细描述, 人机交互文档是对整个系统功能中需要进行人机交互部分的详细描述。