第7章面向问题域的需求分析方法
- 格式:ppt
- 大小:1.15 MB
- 文档页数:41
《软件需求分析》单选填空判断答案全解《软件需求分析》习题集《软件需求分析》课程组编2012年4⽉⽬录⼀、单项选择题 (2)⼆、填空题 (5)三、判断题 (9)《软件需求分析》习题集⼀、单项选择题1、软件⽣产中产⽣需求问题的最⼤原因在于对应⽤软件的()理解不透彻或应⽤不坚决。
(A)复杂性(B)⽬的性(C)模拟性(D)正确性2、需求分析的⽬的是保证需求的()。
(A)⽬的性和⼀致性(B)完整性和⼀致性(C)正确性和⽬的性(D)完整性和⽬的性3、系统需求开发的结果最终会写⼊()。
(A)可⾏性研究报告(C)⽤户需求说明4、现实世界中的((B)前景和范围⽂档(D)系统需求规格说明)构成了问题解决的基本范围,称为该问题的问题域。
(A)属性和状态(B)实体和状态(C)实体和操作(D)状态和操作5、功能需求通常分为三个层次,即业务需求、⽤户需求和()。
(A)硬件需求(B)软件需求(C)质量属性(D)系统需求6、⽐较容易发现的涉众称为初始涉众,⼜称为(),通常包括客户、管理者和相关的投资者。
(A)关键涉众(B)涉众基线(C)普通涉众(D)⼀般涉众7、如果在最终的物件(Final Artifact)产⽣之前,⼀个中间物件(Mediate Artifact)被⽤来在⼀定⼴度和深度范围内表现这个最终物件,那么这个中间物件就被认为是最终物件在该⼴度和深度上的()。
(A)模拟(B)构造(C)原型(D)模型8、按照使⽤⽅式进⾏分类,原型可分为:演⽰原型、()、试验原型和引⽰系统原型。
(A)⾮操作原型(B)系列⾸发原型(C)选定特征原型(D)严格意义上的原型9、按照功能特征进⾏分类,原型可分为:()、⾮操作原型、系列⾸发原型和选定特征原型。
(A)拼凑原型(B)样板原型(C)纸上向导原型(D)严格意义上的原型10、按照开发⽅法进⾏分类,原型可分为:演化式原型和抛弃式原型,其中抛弃式原型⼜被细分为()。
(A)演⽰原型和试验原型(C)探索式原型和实验式原型(B)系列⾸发原型和选定特征原型(D)样板原型和纸上向导原型11、原型的需求内容可以从三个纬度上分析:即()。
软件需求分析中的问题域模型一、引言软件需求分析是软件开发中非常重要的一步。
在这个阶段,开发团队需要全面了解客户的需求,准确地对需求进行分析和把握,最终为客户提供满意的软件产品。
其中,问题域模型是软件需求分析的重要组成部分,是整个需求分析的基础。
二、什么是问题域模型问题域模型是描述客户或业务领域中的概念、关系和行为的模型。
可以理解成是对客户或业务领域的一种抽象和概括,它描述了软件将要解决的问题领域中所存在的各种实体和它们之间的关系。
问题域模型是一种图形化的工具,通常采用UML和ER图来描述,它可以表现客户或业务领域中的各种概念,并将它们组织在一起。
这些概念包括人员、物品、组织、活动、事务等等,通过将它们之间的联系、属性、行为进行描述,可以帮助开发团队更好地理解业务需求。
三、问题域模型在软件需求分析中的作用1.问题域模型可以帮助开发团队更好地理解客户需求在需求分析中,问题域模型是开发团队了解客户需求的第一步,通过对客户的业务领域进行深入的调研和分析,开发团队可以深入了解客户的业务模式、用户、流程等,并逐步形成问题域模型。
问题域模型通过图形化和抽象化的方式,将复杂的客户业务领域用简单的语言和图形进行了描述,使得开发团队能够很快地了解客户对软件产品的需求,为软件的开发提供了指导性的依据。
2.问题域模型有利于开发团队进行团队协同工作在软件开发过程中,问题域模型是开发团队进行共享的一个标准化、规范化的模型。
团队成员可以根据问题域模型共同讨论相关问题,共同分析解决问题的方法,及时排查出现的问题,并在问题域模型的基础上进行协作开发。
3.问题域模型有助于代码的开发和维护对于一个完整的软件系统,它包含了很多的类、对象、方法等。
如果没有一个清晰的问题域模型来指导代码的开发和维护,将会导致代码的混乱和不可维护。
问题域模型可以明确地描述软件系统中各个对象的属性和关系,为代码编写提供了指导。
四、如何建立问题域模型建立问题域模型的最基本的方法是通过业务领域知识的获取和建模。
第7章面向对象分析•7.1.1 面向对象分析过程面向对象的分析主要以用例模型为基础。
开发人员在收集到的原始需求的基础上,通过构建用例模型从而得到系统的需求。
进而再通过对用例模型的完善,使得需求得到改善。
所谓用例是指系统中的一个功能单元,可以描述为参与者与系统之间的一次交互。
用例常被用来收集用户的需求。
①首先要找到系统的操作者,即用例的参与者。
参与者是在系统之外,透过系统边界与系统进行有意义交互的任何事物。
②可以把参与者执行的每一个系统功能都看作一个用例。
可以说,用例描述了系统的功能,涉及系统为了实现一个功能目标而关联的参与者、对象和行为。
③确定了系统的所有用例之后,就可以开始识别目标系统中的对象和类了。
把具有相似属性和操作的对象定义为一个类。
边界类示意图控制类示意图目标系统的类可以划分为边界类、控制类和实体类。
Ø边界类代表了系统及其操参与者的边界,描述参与者与系统之间的交互。
它更加关注系统的职责,而不是实现职责的具体细节。
通常,界面控制类、系统和设备接口类都属于边界类。
Ø控制类代表了系统的逻辑控制,描述一个用例所具有的事件流的控制行为,实现对用例行为的封装。
通常,可以为每个用例定义一个控制类。
Ø实体类描述了系统中必须存储的信息及相关的行为,通常对应于现实世界中的事物。
确定了系统的类和对象之后,就可以分析类之间的关系了。
对象或类之间的关系有依赖、关联、聚合、组合、泛化和实现。
①依赖关系是“非结构化”的和短暂的关系,表明某个对象会影响另外一个对象的行为或服务。
②关联关系是“结构化”的关系,描述对象之间的连接。
③聚合关系和组合关系是特殊的关联关系,它们强调整体和部分之间的从属性,组合是聚合的一种形式,组合关系对应的整体和部分具有很强的归属关系和一致的生命期。
比如,计算机和显示器就属于聚合关系。
④泛化关系与类间的继承类似。
⑤实现关系是针对类与接口的关系。
明确了对象、类和类之间的层次关系之后,需要进一步识别出对象之间的动态交互行为,即系统响应外部事件或操作的工作过程。
填空:1.在导致需求问题的原因中,一个最为重要的原因是:未能很好的掌握应用型软件的模拟特性以及由此产生的一系列的影响和要求。
2.面向专业用户的纯工具型软件的首要成功标准是:要具有功能的复杂性和使用的高效性。
3.需求开发过程中产生的主要文档有三种:项目前景和范围文档,用户需求文档,需求规格说明文档。
4.系统用例图和上下文图通常被用来定义系统的边界。
5.在需求建模时,常用的技术包括:数据流图,实体联系图,状态转换图,类图等半形式化建模技术。
6.业务需求,高层解决方案及系统特性都应该被记录下来,定义为项目前景与范围文档。
7.每一个明确,一致的问题都意味着涉众存在一些相应的期望目标,即业务需求。
8.业务需求中需要特别注意的特征是可行性和可验证性。
9.在会谈中使用的问题基本上可以分为两种:开放式和封闭式问题10.面谈的类别:结构化,半结构化和非结构化面谈11.原型的需求内容可以从三个纬度上分析:外观,角色,实现12.民族志一个主要的应用目的就是研究和解决复杂的协同问题13.分类框架将场景方法从场景的形式(又分为描述和外观两个方面),目的,内容和生命周期四个方面进行了分类和描述14.工程利用场景的目的有三种:描述,探索,解释15.抽象和分解是建模最为常用的两种手段16.抽象通过强调本质的特征,减少了问题的复杂性;分解的手段体现了分而治之的思想17.分析模型是半形式化的18.建模语言有三个要素:语法,语义,语用19.按照Zachman的矩阵框架,分析技术就是用来对第二行(企业模型)的各列进行建模和描述的技术20.面向对象分析方法以对象为基础,结构化分析方法以功能和数据为基础21.结构化,信息工程和面向对象三中方法学下的需求分析技术都是面向解系统的22.使用面向问题的技术称为前期需求阶段的分析,使用面向解系统的技术称为后期需求阶段的分析23.数据流图建模时使用的基本模型元素有四种:外部实体,过程,数据流和数据存储24.DFD定义了三个层次的DFD图:上下文图,0层图和N层图25.实体联系图用实体,属性和关系三个基本构建单位来描述数据模型26.除了静态的事物和抽象的概念之外,行为和事件也是常见的实体类型27.在关系的命名上通常使用动词28.用例模型的基本元素:用例,参与者,关系,系统边界29.UML的行为模型有三种:交互图,状态图,活动图30.在目标模型中使用的其他模型元素有行为者,场景,操作,任务,资源,UML元素等//31.需求跟踪是以软件需求规格说明文档为基线,在向前和向后两个方向上,描述需求以及跟踪需求变化的能力名词解释:1.需求工程:是软件工程的一个分支,它关注与软件系统所应予实现的现实世界目标,软件系统的功能和软件系统应当遵守的约束,同时它也关注以上因素的准确的软件行为规范说明之间的联系,关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
第七章面向对象学习方法学面向对象方法学的出发点和基本原则,是尽可能按照人类的习惯思维方式,使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程,也就是使描述问题域空间与实现解法的解空间在结构上尽可能一致.与传统的结构化方法相比,使用面向对象方法开发的软件,其稳定性,可修改性和可重用性都比较好.本章内容主要包括:传统方法学的缺点,面向对象的基本概念,面向对象模型.7.1 基础知识7.1.1 传统方法学的缺点结构化几其他方法学的本质,是在具体的软件开发之前,通过需求分析预先定义软件需求.然后一个一个阶段地开发用户所需要的软件,实现预先定义的软件需要.过去的经验需要告诉我们,结构化及其他方法学并不能完全消除软件危机.结构化及其他方法学仍然有许多不足之处.1.问题的表现1)生产效率低在生命周期方法学中,特别重视软件开发的阶段性.为了提高了软件开发的效率,减少重大返工次数,强调必须早每个阶段结束之前进行评估.从而开发过程中实行严格的质量管理,确实提高了许多软件的开发的成功率.但是,时间表明,开发高利率仍然很有用.2)不能满足用户需要实践表明,在开发需要模糊或需求动态变化的系统时,软件系统的结果往往不能满足用户需求的变化.主要表现在两个方面:一种是开发人员不能完全获得彻底理解用户的需要,以至开发的软件系统与用户预期的系统不一致;另一种表现是,所开发的系统不能适应用户需求变化,系统的稳定性和可扩充性不能满足需要.3)软件服用就是将已有的软件成分用于构造新的软见系统.软件复用是节约人力,提高软件效率的重要途径.结构分析.设计,几乎每一次开发一个系统时都需要针对这个具体的系统做大量的重复劳动..思维成果的可复用性差.4)软件很难维护实践经验告诉我们,即使是用生命周期方法学开发出来的软件,维护起来仍然相当困难,软件维护成本很高.2.问题的原因1)结构化技术本身的问题结构分析和设计技术的基本思想是从目标系统整体功能的单个处理着手,自顶向下不断的把复杂的处理分解为子处理,一层一层的分解下去,直到剩下若干个容易实现的子处理为止。
一、单选题(每小题2分,共 20 分)1、数据字典是软件需求分析阶段的最重要的工具之一,其最基本的功能是( C )。
A.数据库设计B.数据通讯C.数据定义D.数据维护2、需求验证的任务是( A )。
A.要求各方人员从不同的技术角度对需求规格说明文档做出综合性评价。
B.分析用户要求,将软件功能和性能描述为具体的规格说明书。
C.确保需求规格说明具有良好的特性。
D.发现和修复需求规格说明书存在的问题,并避免在软件系统设计和实现时出现返工。
3、下面哪一项不是软件设计规格说明中应包括的内容( D )。
A.接口描述B.性能需求C.功能需求D.商业约束4、陈述“只有电梯停在某一楼层时,电梯才能改变方向”属于( B )。
A.问题域的描述B.功能需求C.性能需求D.商业约束5、关注于问题域描述和需求的文档是(D )。
A.测试计划书B.规格说明C.用户手册D.需求文档6、对象汽车和客车之间的关系属于(B )。
A.一般-特殊关系B.共享聚集C.复合聚集D.合作链接7、数据流图中,下列哪一种数据流的流向是不可能发生的( B )。
A.从加工流向加工B.从数据存储流向外部实体C.从加工流向外部实体D.从外部实体流向加工8、下列哪种建模技术属于行为建模( C )。
A.数据流图B.E-R图C.状态图D.类图9、需求获取的技术主要有(D )。
A.阅读背景资料B.检查文档C.面谈D.以上都对10、有限状态机的表示方法有(B)。
A.有向图和数据流图B.有向图和表C.时序图和表D.状态图和表二、多选题(每小题2分,共10分)1、性能需求主要包括(ABCD )。
A.速度性能B.容量性能C.可靠性D.可用性E.开发时间2、规格说明书的主要内容有(ABCDE )。
A.引言B.综合描述C.外部接口需求D.系统特性E.非功能需求3、面向对象的需求分析需要建立的模型主要有(ACD )。
A.对象模型B.行为模型C.动态模型D.功能模型E.表示模型4、正式评审中,评审人员按分工可分为(ABDE )。
南开大学本科生毕业论文(设计)题目:____需求分析的方法与建模__学号:____0010127____________姓名:____方春强___________年级:____2000 级___________学院:____软件学院___________系别:____软件工程___________专业:____软件工程___________完成日期:____2004-5-24__________指导教师:____林晓旻___________需求分析的方法与建模软件学院软件工程系软件工程专业方春强学号:0010127指导教师:林晓旻讲师摘要:需求分析作为软件工程的开始,具有相当的难度去把握它。
为了更好的了解软件需求,人们发展了许多方法和建模技术。
借助这次中远船员信息管理系统需求分析实践机会,尽量的在作分析的过程中运用了解的方法、掌握的建模技术,不仅能够有效的分析软件需求,还能加深知识。
关键字:分析,领域,方法学,建模技术,需求AbstractThe requirement analysis took the software engineering the start, has the suitable difficulty to grasp it. In order to understanding software requirement better, people have developed many methods and the modeling technology. With the aid of this CSIS requirement analysis practice opportunity, using the understood method and modeling technology in the analyzing process as far as possible, not only can make the software requirement analysis effective, but also can deepen our knowledge.Key Words:Analysis, domain, methodology, modeling technique, requirement目录第一章绪论 (1)什么是软件需求 (1)需求的过程 (1) (3)第二章方法论 (5)结构化分析(SA) (6)面向对象分析(OOA) (6)面向问题域分析(PDOA) (7)方法的对比 (8)第三章建模技术 (10)外部模型 (10)内部模型 (12)选择技术 (13)第四章需求分析实践 (15)获取需求 (15)需求初始化阶段 (17)详细需求建模阶段 (21)编写需求文档 (25)第五章技巧与心得 (28)总结与展望 (28)一些技巧 (28)致谢 (30)参考文献 (31)第一章绪论什么是软件需求目前,所有国家都在使用复杂的计算机系统。
软件工程简答题答案第五版软件工程简答题第一章绪论1.什么是软件危机?软件危机有什么表现?软件危机产生的原因是什么?答:所谓软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
主要是指如何开发软件,怎样满足对软件日益增长的需求,如何维护数量不断膨胀的先有软件。
表现:(1)对于软件开发的成本和进度的估计很不准确。
(2)开发的软件产品不能完全满足用户要求,用户对已完成的软件系统不满意的现象常常发生。
(3)开发的软件可靠性差。
(4)软件通常没有适当的文档资料。
(5)软件的可维护性差。
(6)软件开发生产率提高的速度,远远跟不上计算机应用普及深入的趋势。
原因:软件开发中遇到的问题因找不到解决的办法,使问题积累起来,形成了尖锐的矛盾,导致了软件危机。
2.简述软件的发展过程。
答:软件生产的发展划分为三个年代:(1)程序设计时代:这一时期,软件的生产主要是个体手工劳动的生产方式。
(2)程序系统时代:由于计算机的应用领域不断扩大,软件的需求也不断增长,软件由于处理的问题域扩大而使程序变得复杂,设计者不得不由个体手工劳动组成小集团合作,形成作坊式生产方式小集团合作生产的程序系统时代。
(3)软件工程时代:软件工程时代的生产方式是采用工程的概念、原理、技术和方法,使用数据库、开发工具、开发环境、网络、分布式、面向对象技术来开发软件。
3.什么叫软件工程?软件工程是如何克服软件危机的?答:软件工程是将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究。
为了克服软件危机,人们从其他产业的工程化生产得到启示,采用工程的概念、原理、技术和方法来开发和维护软件。
4.软件工程的目标是什么?软件工程有哪些原则?答:软件工程的目标是:在给定成本、进度的前提下,开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求的软件产品。
原则如下:抽象、模块化、信息隐藏、局部化、完整性、一致性和可验证性。
学习软件需求分析的方法和技巧软件需求分析是软件开发过程中至关重要的一环,它涉及到对用户需求的深入理解和准确捕捉。
本文将介绍一些学习软件需求分析的方法和技巧,帮助读者更好地掌握这一重要的软件开发技能。
一、需求获取需求获取是软件需求分析的第一步,它主要包括了解用户需求、获取用户意图、定义需求范围等工作。
以下是一些常用的需求获取方法。
1. 面谈法面谈法是最常用的需求获取方法之一,通过与用户进行面对面的交谈,了解他们的需求、期望和具体问题。
在面谈过程中,需求分析师可以通过提问和倾听来准确理解用户需求。
2. 观察法观察法是通过观察用户当前的工作环境,了解他们的行为和关注点,从而推断出他们的需求。
观察法常用于现场调查和用户研究,在现实情境中帮助需求分析师更好地理解用户需求。
3. 文档分析法文档分析法是通过分析已有的文档资料,获取用户需求的方法。
这些文档可以是用户手册、业务流程图、数据库设计等,通过仔细研读这些文档,需求分析师可以捕捉到用户需求中的关键信息。
二、需求分析需求分析是对需求进行深入理解、抽象和整理的过程,目的是确保需求准确、完整、可行。
以下是几种常用的需求分析方法和技巧。
1. 用例分析法用例分析法是一种结构化的需求分析方法,它将系统功能划分为一个个独立的用例,描述了用户与系统进行交互的场景。
通过用例分析,可以帮助需求分析师更好地理解用户的功能需求和交互流程。
2. 数据流图数据流图是一种图形化的表示方法,用于描述数据在系统中的流动过程。
通过绘制数据流图,需求分析师可以清晰地了解系统中的数据交互和处理过程。
数据流图可以帮助揭示系统中的潜在问题和改进空间。
3. 需求建模需求建模是一种将需求抽象化和形式化的方法,使用统一建模语言(UML)等工具,将需求以图形化的方式表示出来。
需求建模可以使需求更加清晰、易于理解和交流。
三、需求验证需求验证是确保需求准确性和可行性的过程,它主要通过需求审查和验证活动来完成。
《软件⼯程案例教程》李军国主编习题答案第1章习题答案⼀、判断题⼆、填空题三、简答题1.软件的特点:①软件具有抽象性。
②软件与硬件的⽣产⽅式不同。
③软件与硬件的维护⽅式不同。
④软件具有复杂的逻辑性。
⑤软件的成本较⾼。
⑥软件的使⽤和社会因素有关。
2.软件危机产⽣的原因:①⽤户需求不明确。
②缺乏正确的理论指导。
③软件开发规模越来越⼤。
④软件开发复杂度越来越⾼。
3.软件危机的主要表现:①软件开发进度难以预测。
②软件开发成本难以控制。
③⽤户对产品功能难以满⾜。
④软件产品质量⽆法保证。
⑤软件产品难以维护。
⑥软件缺少适当的⽂档资料。
4.软件⼯程学的基本原则有哪些:①抽象。
②信息隐蔽。
③模块化。
④局部化。
⑤确定性。
⑥⼀致性。
⑦完备性。
⑧可验证性。
5 什么是软件的⽣命周期?答案:软件与任何⼀个事物⼀样,有它的孕育、诞⽣、成长、成熟、衰亡的⽣存过程。
这就是软件的⽣存周期。
6 软件⼯程过程有哪⼏个基本过程活动?试说明之。
答案:软件⼯程过程的基本过程活动有4步:①软件规格说明(需求定义)。
规定软件的功能及其运⾏的限制;②软件设计与开发(设计开发)。
产⽣满⾜规格说明的软件;③软件确认(测试)。
确认软件能够完成客户提出的要求;④软件演进(维护)。
为满⾜客户的变更要求,软件必须在使⽤的过程中演进。
四、综合题1.详细说明软件⽣命周期分哪⼏个阶段?答案:软件⽣命周期主要分为6个阶段:软件项⽬计划、软件需求分析和定义、软件设计、程序编码、软件测试,以及运⾏维护。
(1)软件项⽬计划:在这⼀步要确定软件⼯作范围,进⾏软件风险分析,预计软件开发所需要的资源,建⽴成本与进度的估算。
根据有关成本与进度的限制分析项⽬的可⾏性。
(2)软件需求分析和定义:在这⼀步详细定义分配给软件的系统元素。
可以⽤以下两种⽅式中的⼀种对需求进⾏分析和定义。
⼀种是正式的信息域分析,可⽤于建⽴信息流和信息结构的模型,然后逐渐扩充这些模型成为软件的规格说明。
另⼀种是软件原型化⽅法,即建⽴软件原型,并由⽤户进⾏评价,从⽽确定软件需求。
需求分析方法探究需求分析是软件开发过程中至关重要的一步,它有助于确定用户需求,确保软件开发过程的成功。
本文将探究一些常用的需求分析方法。
1. 用户访谈(User Interviews)用户访谈是一种直接与用户交流的方法,通过与用户面对面的访谈,获取他们的意见、需求和期望。
这种方法能够提供有关用户期望的详细信息,并帮助开发团队更好地理解用户需求。
2. 观察研究(Observation)观察研究是通过观察用户在实际环境中的行为和操作,来获取有关他们需求的信息。
通过观察用户在他们日常生活中使用软件的方式,可以了解他们的需求和痛点,从而提出更好的解决方案。
3. 引导式讨论(Facilitated Workshops)引导式讨论是通过组织一系列工作坊,邀请利益相关者一起讨论和定义需求。
这种方法通过团队合作和协商来收集需求,可以有效地整合各方的意见,形成共识。
4. 原型开发(Prototyping)原型开发是通过创建一个初步的软件原型来验证和确认需求。
这个原型可以是低保真的草图或模型,也可以是高保真的交互式界面。
通过与用户交互和测试,可以及早发现和解决需求中的问题。
5. 文档分析(Document Analysis)文档分析是通过审查现有的相关文档来获取需求信息。
这些文档可以是用户手册、业务规范、需求规格说明书等。
通过仔细分析这些文档,可以了解现有的需求和业务流程,为软件开发提供指导。
需要注意的是,以上方法的使用应根据具体项目和团队情况灵活选择。
不同的方法可以相互结合,以获取更全面和准确的需求信息。
在需求分析过程中,与用户和利益相关者的沟通至关重要,只有充分了解他们的需求才能设计出满足他们期望的软件。
总结起来,通过用户访谈、观察研究、引导式讨论、原型开发和文档分析等需求分析方法,我们可以更好地理解用户需求,为软件开发提供有效的指导和支持。
参考文献:- Sommerville, I. (2013). Software engineering. Pearson Education Limited.- Karlsson, E., & Ryan, K. (2013). A practical guide to software requirements engineering. CRC Press.。