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